Frequently asked questions

A person reads it - not an autoresponder. We come back with either a few clarifying questions or a proposed call, depending on how much detail you sent.

The first conversation is about understanding the problem, not selling you a package. If we're not the right fit, we'll say so and point you somewhere better.

No. Most people arrive with a problem and a rough shape of a solution, and that's enough to start.

If you do have a specification, send it. If you don't, the first phase of work is usually turning what's in your head into something concrete enough to estimate.

Yes, and we'd rather sign one before you send anything sensitive than after. Ask and we'll get it done.

Please don't put confidential material into the enquiry form ahead of that.

Both, and the work looks different for each. An early-stage product needs to reach real users quickly so you can find out whether the idea holds. An established business usually needs something to integrate with systems that already exist and can't break.

What doesn't change is how we scope and communicate.

We quote per project, after we understand what's being built. Anyone who gives you a number before that is guessing.

The things that actually move the figure: how many distinct user roles there are, how much of it integrates with systems you already run, whether it needs mobile as well as web, and how much design work is starting from nothing. Scoping produces a number you can plan around.

Fixed price where the scope is genuinely fixed - a marketing site, a defined integration, a well-specified module. You get a number and a date.

For product work where requirements will change as you learn from users, fixed price tends to punish both sides: we pad the estimate, and you can't change your mind without a variation order. There we work in sprints against an agreed rate, with scope reviewed as we go.

It depends on scope, and we won't pretend otherwise. What we will do is give you a timeline with the assumptions written down, so when something slips you can see exactly which assumption broke.

The single biggest factor is usually not our speed - it's how quickly decisions and feedback come back from your side.

It usually does, and that's fine. What matters is that a change is visible rather than absorbed silently.

When you ask for something new, we tell you what it costs in time or money before we build it, and you decide. Nothing gets quietly dropped to make room for it.

One person who can make decisions, and reasonably quick answers to blocking questions. Access to whatever systems we need to integrate with, arranged early rather than the week we need it.

Most delays come from waiting on access or a decision, not from the engineering.

You get a working environment you can open at any time and see the current state - not screenshots in a status email.

On top of that: a written update at an agreed interval covering what shipped, what's next and anything that's become a risk. Risks go in the update as soon as we spot them, not once they've become problems.

The people you meet during scoping are the people who build it. We don't run a model where a senior engineer wins the work and juniors deliver it unsupervised.

You'll know who's on your project and be able to talk to them directly.

Yes. That ranges from taking one self-contained piece and delivering it against your standards, to embedding with your team and working in your repository, your review process and your ticketing system.

If you have coding conventions and an architecture, we follow them rather than importing ours.

Often, yes. It starts with an assessment: we read the codebase and give you an honest account of its state, what's salvageable, and what it would cost to continue versus rebuild.

Sometimes the answer is that continuing is cheaper, sometimes it isn't. You get the assessment either way, and you're free to act on it without us.

The stack follows the problem. For content-driven sites we lean on static generation because it's fast, cheap to host and hard to break. For applications we work primarily in TypeScript across the stack, with SQL databases where the data is relational.

What we won't do is pick something novel because it's interesting. You'll be living with this codebase after we hand it over, and hiring for it matters more than our enthusiasm.

Yes. On final payment, the intellectual property in what we build for you is yours - source, assets, infrastructure configuration, the lot. The specifics are in the agreement we sign.

We don't hold code hostage, and we don't build in dependencies on us that you can't remove.

Both, and the choice is a real decision rather than a default. Cross-platform gets you two platforms from one codebase and is the right call for most business applications.

Native earns its extra cost when the app leans hard on platform capabilities or has to perform well on low-end hardware. We'll tell you which case you're in before you commit.

Models wired into workflows that produce a measurable result - document processing, search over your own content, classification, forecasting from data you already hold.

What we'll push back on is adding a chat interface to something that doesn't need one. If the honest answer is that a feature doesn't need a model, we'll say that.

Input validated at every boundary, authorisation enforced on the server for every protected operation, secrets kept in a secret manager rather than in code, and dependencies kept current.

For projects handling health, financial or other regulated data, security requirements are part of scope from the start rather than a review at the end - retrofitting them is far more expensive.

Both are build requirements here, not a polish phase that gets cut when the timeline tightens.

That means semantic HTML, full keyboard operation, visible focus, sufficient contrast in every theme, and shipping as little client-side JavaScript as the interaction actually needs. It matters most for the users you'll never hear from - the ones on a slow connection or an older device who leave rather than complain.

You get the running system plus everything needed to operate it: repository access, deployment and environment documentation, and a walkthrough with whoever will maintain it.

We stay close for an agreed period afterwards to deal with anything that surfaces once real users arrive, because some things only appear under real traffic.

Yes, as a separate arrangement - covering dependency and security updates, monitoring, fixes and a defined amount of change work each month.

It's optional. Some clients take it indefinitely, some for a few months while their own team gets comfortable, some not at all.

That's a normal outcome, not a failure. We build so it's possible: conventional patterns, documented decisions, no proprietary layer only we understand.

When you're ready, we'll hand over and brief your team properly. A handover that goes badly costs us more in reputation than the retainer was worth.

We're in Rajshahi, Bangladesh, and we work with clients across Europe, North America, the Middle East and Asia.

In practice the overlap is workable with Europe and the Middle East, and narrower with North America. We handle it by agreeing fixed hours for live conversation and running everything else in writing, so progress doesn't stall waiting for a shared window.

All project work - calls, documentation, code and written updates - is in English. We also work in Bengali with clients who prefer it.

Against milestones tied to delivered work rather than elapsed time, so you're paying for things you can see. Terms are set out in the agreement before anything starts.

We invoice internationally and can work in your currency.