How much does it cost to build a SaaS product? An honest answer

You have almost certainly found pages answering this with a number. Something like "$50,000 to $150,000 for an MVP", often in a table by complexity tier.

Those numbers are not lies exactly. They are averages of projects that have nothing in common, presented with a precision nobody has earned. Their real function is to be memorable enough that you contact the firm that published them.

The honest answer is that the same feature list can differ by an order of magnitude, and the drivers of that difference are knowable. So rather than give you a number, this explains what to look at — which is more useful, because it lets you produce your own estimate and evaluate the ones you receive.

Why "build a SaaS" is not one thing

Take a single line item: payments.

• One plan, one currency, card only, no proration: a few days.
• Three plans with monthly and annual billing, upgrades and downgrades mid-cycle, proration, dunning, invoices, and VAT handling across the EU: several weeks, and it will need revisiting.
• The above plus usage-based metering: now your billing depends on a metering pipeline that must be accurate, replayable and reconcilable, because it is financially material. This is not a feature, it is a subsystem.

Same checkbox. Between two days and two months. Multiply that spread across fifteen checkboxes and you can see why a single figure is meaningless.

The five things that actually move the number

1. Your data model, especially tenancy

Whether customers share infrastructure with logical separation, or are isolated, is a decision that shapes everything after it. It affects querying, migrations, backups, compliance, and what "delete this customer" means.

Made deliberately in week one, it is nearly free. Discovered in month nine, it is a migration under load with customers watching. This is the single largest hidden variable in SaaS estimates.

2. Who your first customer is

One enterprise customer pulls SSO, audit logging, a security questionnaire and often a penetration test into your first release. One self-serve customer pulls in onboarding, trials, plan limits and self-service billing instead.

The same feature list produces two different products, with different phase one scopes and different costs. Founders often cannot answer this question early, and it is worth noticing that the estimate is unstable until they can.

3. Integration surface

Each third-party system brings authentication, rate limits, sandbox environments, downtime and breaking changes. One integration is a feature. Six is an ongoing category of work with its own maintenance burden.

Integrations also fail in ways your code did not cause, which means error handling, retries and support tooling — costs that never appear on the feature list.

4. How unusual the domain logic is

Standard CRUD over well-understood entities is fast. Pricing engines, scheduling with constraints, allocation, matching, or anything with real-world physical dependencies are slow — not because of the code volume, but because the requirements only become clear while building.

A good signal: if two people in your company disagree about how a rule works, that rule will cost several times what you think.

5. Whether you want to be able to change your mind

Optionality has a price. Architecture that keeps future paths open costs more now and less later. Architecture optimised for one known path is faster to build and harder to turn.

Both are legitimate choices. The failure is making this choice by accident and discovering which one you picked when you try to pivot.

A better way to budget

Rather than asking for a total, do this.

Define phase one as the smallest thing a real customer would pay for. Not the smallest thing that demonstrates the idea — the smallest thing someone hands over money for. These are different, and the gap between them is where most first-round budgets are lost.

Get that phase priced against a defined scope. A defined scope can be estimated with reasonable confidence. An open-ended product cannot, and any firm quoting a fixed price for one has either padded it substantially or has not read it.

Budget for the second phase before you start the first. Products are not finished at launch; they are barely started. A common failure is spending the entire budget reaching a launch, then having nothing left to act on what launch teaches you.

Assume 15–25% of build cost per year for ownership. Hosting, dependency updates, security patching, support and small changes. This applies from the day you have your first customer, not from some later maturity point.

What we do instead of publishing a price

We publish a complexity estimator. You select what your product needs, and it gives a complexity score, a recommended delivery approach, and a phase breakdown — plus warnings about combinations that cost more together than separately.

It deliberately does not output a price, for the reason set out above. Its real value is watching the number move: if removing native mobile drops your complexity by a fifth, you have learned something concrete about what mobile is costing you before committing to it.

Then we price a defined phase, once we understand the scope. That is a slower answer than a number on a page. It is also the only kind of number worth planning against.