What a SaaS MVP actually costs — and what drives the number

Nobody can price “a SaaS MVP” from the phrase alone, any more than a builder can price “a house”. But the variables are knowable, and most of them are decisions you make rather than facts you discover. Understanding them is the difference between comparing offers and guessing.

The five things that actually move the price

1. How many core workflows there are

This is the dominant factor, and it is almost always underestimated. A workflow is a complete job a user comes to do: “publish a listing”, “run payroll”, “review a submission”. One workflow, built properly, is a real product. Three workflows is roughly three times the work — not because the screens multiply, but because the states between them do.

Founders routinely describe five workflows and call it an MVP. That is not an MVP, it is version two.

2. Who the users are to each other

A single-user tool is the cheapest structure there is. The moment users belong to organisations, invite colleagues, hold different roles and share records, you have added a permissions model that touches every query and every screen. This one decision can double a build, and it is invisible in a wireframe.

3. What the money does

A one-off payment or a single flat subscription is a well-trodden path. Usage-based billing, seat counts that change mid-cycle, trials converting to paid, proration, dunning for failed renewals, VAT handling across EU countries, or paying out to third parties — each of these is its own body of edge cases.

4. What it has to talk to

An app that owns all its data is self-contained. Every external system it must synchronise with brings authentication, rate limits, partial failure, and someone else's release schedule. Integrations are usually priced too cheaply because the demo is quick and the reliability work is not.

5. What happens if it is wrong

A tool for tracking your own reading list and a tool that calculates someone's payroll can look identical on screen. They are not the same product to build, because the cost of a defect is not the same. Regulated data, money movement and anything a customer would sue over all pull the same lever: more verification, more review, more cost.

Where the money actually goes

A common misconception is that a build is mostly typing. On a well-run focused project the split looks closer to this:

These are working proportions, not a formula — they shift with the project. The point is that the last 15% is where “it works on my machine” becomes “other people can use it”, and it is the first thing cut when a quote is competing on price alone.

Why quotes differ so wildly

When you get a $5,000 quote and a $50,000 quote for the same brief, the usual explanations are:

• Different scope read. One read “MVP” as one workflow, the other read your full description.
• Different definition of done. One is quoting a working demo, the other a launched product with access rules, payment edge cases and documentation.
• Different aftercare. Some quotes include a stabilisation period and fixes; others end at delivery.
• Different ownership. Some builds live on the agency's accounts, which is cheaper up front and expensive to leave.
• Different risk pricing. A fixed price absorbs uncertainty, and someone has to pay for that absorption.

Our own numbers, for reference

So this is not abstract — these are our starting prices for business customers, with the final quote set after the scope is agreed:

A starting price is the floor for a defined scope, not an average. More workflows, an organisation-and-roles model or non-trivial billing move a project above it, and we say so in the quote rather than after.

How to get a number you can trust

1. Write down the one job your first users hire the product for. If you cannot pick one, you are not ready to quote yet.
2. Describe the user model in a sentence: individuals, or organisations with roles?
3. Describe the money in a sentence: who pays, how often, what happens when they stop.
4. List the systems it must talk to, and mark which are required at launch rather than eventually.
5. Ask every studio to quote against that same page, and to state what they are excluding.

That page takes an hour and is the highest-leverage hour in the whole project. It also turns five incomparable quotes into five comparable ones.

If you want a second read on scope before you commit to anything, that is what a Project Check is for — a written diagnosis and a prioritised plan, independent of whether you then build with us. If the first workflow is already clear, see what our Lovable SaaS MVP build includes.