What a web app actually costs to build

Every few weeks someone sends us a proposal from another studio and asks why our number is different. Usually it is not a small gap. I have seen the same brief priced at four thousand dollars and at fifty thousand, and both quotes were written in good faith.

That gap is not a market failure. It is what happens when a buyer asks “how much for an app” and two teams answer two different questions. This is the post I keep meaning to send instead of explaining it on a call.

Nobody is quoting the same thing

When you describe a product in a paragraph, you have described maybe fifteen per cent of it. The rest gets filled in by whoever is reading, and what they fill in depends on what they think you meant.

Take “a booking system for a clinic.” One team reads that as a form, a calendar, and an email. Another reads it as multi-practitioner availability, rescheduling rules, no-show handling, SMS reminders on a local gateway, patient records that a regulator might one day ask about, and an admin view for reception staff who are not going to be trained.

Both built the thing you asked for. One of them built the thing you meant.

The cheap quote is not usually a scam and the expensive one is not usually padding. The cheap quote is a smaller reading of the same sentence. Your job when comparing them is to work out which reading each team made — and that is a question about scope, not about price.

Price tracks surface, not features

The instinct is to count features and assume cost rises with the list. It does not. Cost rises with surface — the number of distinct states the software has to be correct in.

A feature list of twelve items where every user sees the same thing is a small build. A feature list of four items where an admin, a staff member, a customer and a guest each see a different version of each one is a much larger build, because you now have sixteen combinations to design, build and test rather than twelve.

Four things expand surface faster than anything else, and they are the four questions I ask before quoting anything.

How many kinds of user are there? Every role multiplies the interface. Two roles is not twice the work of one, but it is close, because permissions have to be decided everywhere rather than nowhere. This is the single largest lever on the number, and it is the one clients most often add casually in a sentence — “oh, and the manager should be able to see everything.”

How much of it is other people’s software? Payments, SMS, accounting, shipping, a CRM the sales team refuses to leave. Each integration is a negotiation with a system you do not control, usually with sandbox credentials, a rate limit, an undocumented edge case and an owner who changes the API in eight months. In Bangladesh, add local payment gateways to that list; the documentation is thinner and the testing loop is slower. Integration work is routinely the most under-estimated line in a proposal.

What does the data have to remember? A form that emails a submission remembers nothing. A product that reports on last quarter has to have been storing the right things, correctly, since last quarter. Reporting is not a screen you add at the end — it is a set of decisions made at the beginning, and retrofitting it is close to a rewrite.

Who keeps it running? Software that one person uses on a laptop and software that four hundred people depend on at nine in the morning are different products, even with identical screens. The second one needs error handling, monitoring, backups, and a way to deploy a fix without taking it down. That is real engineering time and it appears on no feature list.

Where the money goes

Roughly, on a typical custom build that we run:

Design is a smaller share than people expect. Interface design, prototyping and the design system usually land around a quarter of a project. It is front loaded, it feels like a lot while it is happening, and it is not where budgets disappear.

Engineering is the bulk. Most of that is not the screens — it is the parts of the system nobody demos: authentication, permissions, data validation, error states, the admin tooling that lets you fix a bad record at eleven at night. On a mature build, the visible interface is maybe a third of the code.

Testing, deployment and the first weeks after launch take more than most first-time buyers plan for. Something always breaks in contact with real users. Budgeting nothing for that does not remove the cost, it just moves it into an argument later.

And then there is the part that is genuinely optional and gets sold hardest: discovery workshops, brand strategy decks, research readouts. Some of it earns its place on a large product. On a first version it is often the line I would cut first — not because it is worthless, but because the same questions get answered faster and more truthfully by shipping something small to ten real users.

The expensive decisions that look like savings

Fixing the price before fixing the scope. A fixed price on a vague brief is not a protection, it is a bet, and the team writing it prices the bet by padding or by planning to argue about change requests later. Both are worse for you than paying for a short paid scoping phase and then fixing the price on something specific.

Choosing the lowest quote without asking what was excluded. If one number is a third of the others, the honest question is not “why are you cheap” but “what did you assume?” Ask for the assumptions in writing. A team that cannot list them has not thought about the project yet.

Building for the company you plan to be. Multi-tenancy, multi-language, a white-label mode and a public API, all before the first hundred users. Every one of those is a real capability and every one roughly doubles a decision you now have to make everywhere. Build for the next twelve months, not the next five years. You will know much more in twelve months.

Treating maintenance as optional. Dependencies age, gateways deprecate endpoints, browsers change. A product with nobody maintaining it does not stay still, it degrades. Budget something ongoing, even if it is small.

Paying for a rebuild in eighteen months. The cheapest possible first build is frequently the most expensive two-year decision, because the second team has to understand it before they can extend it, and understanding undocumented code is slower than writing it. This is the single most common way we get introduced to a project: not as the first studio, as the second.

What I would actually cut

If a budget is tight — and most good projects have a tight budget — these are the reductions that do not come back to bite.

Cut user roles before you cut features. One role that does everything, until you genuinely have two kinds of person using it.

Cut the admin interface and use the database tool directly for the first few months. It is unglamorous, it works, and it costs nothing.

Cut reporting to a weekly export. If someone will read it in a spreadsheet anyway, build the export, not the dashboard.

Cut the second platform. Ship web first and see whether anyone asks for the app.

Do not cut error handling, do not cut the deployment pipeline, and do not cut the design system down to individual screens. Those three are what make the next round of work cheap instead of expensive.

Getting a number you can compare

If you want two quotes you can actually put side by side, give both teams the same four answers: who uses it and in how many roles, which external systems it has to talk to, what it needs to report on, and how many people depend on it on a bad day. Then ask each of them to write down what they assumed.

The quality of a proposal is visible in its assumptions long before it is visible in its price. A team that has read your problem properly will come back with questions that make you slightly uncomfortable — the ones about who maintains it, what happens when a payment half-fails, what the receptionist does when the internet drops. That discomfort is the sign you want.

We scope before we price, and we would rather tell you a project is smaller than you thought than win it by agreeing with a number. If you have something you are trying to budget for, send us the shape of it — even a rough one — and we will tell you what it would actually take.

For what goes into that first message, my colleague Labib wrote the guide to briefing a studio, which is the other half of this post.