Nobody can price a SaaS build from a paragraph, and anyone who offers to should worry you. But the variables that move the number are entirely knowable—and understanding them is what lets you brief properly, compare proposals and avoid the expensive surprises.
9 min read Walker Thomason
This is the first question almost everyone asks, and the honest answer is unsatisfying: it depends on scope, and scope is a decision you have not made yet. That sounds like evasion. It is not. The same three-word brief—"a booking platform"—covers a product one person builds in a few months and a product that takes a team two years, and the difference is entirely in decisions nobody has taken when the question gets asked.
What you can do is understand the variables. If you know what moves the number, you can brief a team properly, read a proposal critically, and make deliberate choices about where your money goes instead of discovering them in month four.
Some agencies do publish packages, and it is worth understanding what that means. A fixed price on a website has to be quoted against the worst plausible interpretation of a vague brief, or it has to be so tightly defined that anything you actually need falls outside it. Either you pay a risk premium, or you spend the project arguing about what was included.
The teams who will not quote before scoping are not being difficult. They are telling you that they intend to find out what you need first. That is the behaviour you want, even though it is less convenient than a number on a page.
A useful test when comparing teams: ask what they would need to know to give you a confident number. A good answer is a list of questions about your users, your commercial model and your integrations. A bad answer is a number.
In our experience, almost all of the variance in a SaaS quote comes from these, roughly in order of impact.
Not features—journeys. A product where one type of user does one main job has a fraction of the surface area of one where three types of user each do something different. Every additional journey brings its own screens, its own states, its own edge cases and its own testing. This is the single biggest lever you control, and it is the reason a well-scoped first release can cost a small fraction of a "complete" product.
"Users can log in" is cheap. "Account owners can invite managers, who can see everything except billing, and staff, who can only see their own records, and external partners, who get a restricted read-only view" is a different product. Permissions multiply through every screen you build, and they are hard to add convincingly later because every existing screen has to be revisited.
Almost every SaaS product serves many customers from one platform, and the tenancy model—how data is isolated, how configuration differs per account, what happens when one customer is ten times the size of the rest—shapes everything built on top of it. Settled at the start it is simply part of the architecture. Retrofitted later it is one of the most expensive corrections in SaaS.
Billing is where cost hides. A single monthly price per account is straightforward. Per-seat pricing with mid-cycle changes, usage-based billing, annual contracts alongside monthly ones, free trials, discounts, multiple currencies, tax handling, failed payments, refunds, dunning and invoicing—each is a real piece of work, and most briefs mention none of them. Decide your pricing model early, because it is a build decision as much as a commercial one.
Integrations are the most reliable source of underestimation, because the effort lives in the other system's documentation, rate limits, authentication model and reliability rather than in yours. A payment provider with a good SDK is one thing. An accounting system with a legacy API, or a customer's on-premise database, is another entirely. Two integrations can cost more than the rest of the first release.
"And a dashboard" is a deceptively large sentence. Reporting that stays fast as records accumulate needs deliberate data design, and reporting people actually use needs a view on what decisions they are making. It is also one of the easiest things to defer: customers will tell you which numbers they want once they are using the product, and they are rarely the ones on the original list.
If the workflows are well understood and documented, design is mostly interface work. If the process only exists in three people's heads and they disagree, discovery is the project for a while. Neither is wrong, but they cost differently—and skipping discovery on the second kind of project does not save money, it defers the cost into the build where it is more expensive.
Beyond scope, a handful of things are routinely missing from budgets and briefs:
A SaaS product is a live service, and the build is not the whole number. Budget for:
We would rather a client spent less on the first release and kept budget for the six months after it, than spent everything reaching a launch with nothing left to act on what they learn. With Resova—the platform we built, ran and eventually sold—almost everything that made it valuable was built after launch, in response to what the first venues actually did with it.
Each works, in different situations.
Fixed price suits well-defined work where the scope genuinely will not move. It transfers risk to the supplier, who prices that risk in, and it makes changing your mind a commercial event rather than a conversation—which is fine if you are certain and painful if you are not.
Day rate or sprint-based suits products, because products change as you learn. It requires more trust and more involvement from you, and it gives you the ability to reprioritise every couple of weeks without renegotiating.
Retainer suits the phase after launch, when the work is a steady stream of improvements rather than a defined project.
The most common expensive mistake is fixed-pricing a product nobody understands yet. Discovery, scoped and paid for on its own, then a fixed price or estimate against what it produced, is usually the sensible sequence.
It happens constantly, and the cheap one is not always wrong. Things worth checking:
Cut scope, not quality. A first release with one journey done properly costs a fraction of one covering three, reaches customers sooner and teaches you more per pound spent. Every feature you build before launch is built on an assumption; every feature you build after it is built on evidence.
What should not be cut is the small set of decisions that are expensive to reverse—tenancy, the permission model, how billing maps to pricing, and basic security. Those are structural rather than features, and skipping them is how a cheap first release becomes a rebuild. We have written more about where that line sits in SaaS MVP development.
For us: it depends, and we will tell you within a week of talking properly. We do not publish price bands because the honest ones would be so wide as to be useless, and the narrow ones would be marketing. What we do instead is a short discovery conversation, then a range against a defined scope, with the assumptions written down so you can see what would change it.
If you are gathering budget numbers for a business case, that conversation is worth having with two or three teams before you commit to anything—including ours. You will learn more from the questions they ask than from the numbers they give you.
We scope before we quote, which means a short discovery conversation and then a range against a defined scope. It costs you an hour and you will leave knowing more about your own project either way.