There is no figure in this article. We do not hold verified pricing data we could publish, and a range assembled from impressions of what other studios charge would be a guess wearing the clothes of research. What is worth explaining is why the guesses vary so wildly in the first place — because that variance is not noise, it is information about your own project.
Two founders describe what sounds like the same product and come back with quotes a factor of five apart. Usually neither quote is dishonest. They are answering different questions, and the founders did not know there were different questions to answer.
The four decisions that move the number by multiples
Who the tenants are. A tool used by one company is a straightforward application. A tool used by many companies, where each must never see another's data, is a different system: every table, every query, every permission check and every background job has to carry that boundary, and getting it wrong once is a catastrophe rather than a bug. If you say "multi-tenant" casually in a first call, you have just moved the estimate more than any feature on your list will.
Who is allowed to do what. Two roles, admin and user, is an afternoon. Roles that vary per organisation, with permissions an administrator can configure themselves, is a subsystem with its own interface, its own testing surface and its own support burden. Most founders describe the second while budgeting for the first.
Whether money moves through it. Taking a card once is a solved problem. Subscriptions are not: you inherit upgrades, downgrades, proration, failed payments, dunning, refunds, tax in multiple jurisdictions, and a set of edge cases that only appear in month four when someone downgrades mid-cycle after a partial refund. Billing is reliably the most underestimated component in any SaaS budget, and the person who eventually finds every edge case is your customer.
What it has to talk to. An integration against a mature, well-documented API is predictable work. An integration against an internal system with no sandbox, or a vendor whose documentation describes a version they no longer run, is open-ended — and it is open-ended in a way nobody can size until they have tried it. We test against the sandbox before quoting for exactly this reason, and where there is no sandbox we say the number is provisional rather than pretending otherwise.
The costs that are not in the build quote at all
A build quote covers building. A SaaS product costs money every month it exists, and the first budget usually omits all of this.
Infrastructure scales with usage, which is the point, but it also scales with carelessness — an unindexed query nobody notices at a hundred users is a bill at ten thousand. Third-party services stack up quickly: email delivery, error monitoring, analytics, the payment processor's percentage. Support is a real cost even when it is the founder doing it, because it is hours not spent selling. And then there is the work of keeping the thing current: dependency updates, security patches, the framework version that goes end-of-life.
The rule of thumb worth internalising is that launch is the beginning of the spending, not the end of it. Founders who budget the build to the last pound and nothing beyond it are the ones who stall three months after launch with a product that works and no money to improve it.
Why "just build the MVP" is not the saving it sounds like
It can be an enormous saving. It is only a saving if the word is used precisely, and it very often is not.
An MVP is the smallest thing that tests whether anyone wants this — normally one workflow, done properly, for one kind of user. What founders frequently mean by the word is version one of the real product: accounts, billing, an admin panel, settings, notifications, a dashboard. That is not a minimum anything. Costing it as an MVP is how you end up with a demo you cannot sell and a budget you cannot extend.
The useful discipline is to name the single assumption that would sink the business if it were wrong, then build only what tests it. That is genuinely cheap. Everything else can wait for evidence, and most of it turns out to want to be different once the evidence arrives.
How to read a quote you have been given
Ask what happens when the estimate is wrong, because it will be. A fixed price with no change process means the risk has been priced into the number and you are paying for it whether or not it materialises. Time and materials with no cap means the risk is entirely yours. A fixed scope with a written change process is the honest middle, and the thing to examine is the process rather than the number.
Ask what is excluded. Store submission, third-party licences, data migration, content, training and the first month of post-launch fixes are the usual omissions, and any of them can be a meaningful line.
Ask who owns the code, the repository and the infrastructure accounts. If the answer is anything other than "you do", the low number you were quoted is not the number, because the cost of leaving is part of the price.
If you want a second pair of eyes on a quote you have already received, send it over and we will mark it up — including the parts where we think it is fair. We publish how we scope this work for anyone who would rather read it than ask.
