MVP development cost: what it depends on, and when a prototype is enough
An MVP is priced like a small product and judged like an experiment, which is why so many cost more than they should. What it costs depends on the question it has to answer and on what must survive if the answer is yes.
The short version
- An MVP is an experiment, not a small product. Eric Ries, who popularised the term, wrote that it is not about creating minimal products but about learning the most with the least effort.
- So its cost starts with the question it has to answer. Without one written down, scope grows, because there is no test for what to leave out.
- If the question is whether people understand and want the idea, a clickable prototype answers it for far less than an MVP. Build the MVP when you need behaviour, not opinions.
- The hidden cost is the rebuild. Decide which parts are temporary on purpose and which must survive, such as the data model, tenancy and billing for a SaaS MVP.
- Two MVP quotes are comparable only when both vendors were given the same question, users, platforms and test of success.
Summarise with AI
ChatGPT
Claude
PerplexityWhat an MVP has to prove decides what it costs
MVP development cost depends on the question the MVP has to answer, the users who will test it and how they are reached, the platforms and integrations it needs, and which parts must survive if the answer is yes. If the question is only whether people want the idea, a clickable prototype answers it for far less than an MVP.
The term minimum viable product is now used for almost any first version of software, which is part of why it is so hard to price. Eric Ries, whose writing made the term common, defined it in 2009 as the version of a new product that lets a team collect the most validated learning about customers with the least effort. In the same post he warned that an MVP, despite the name, is not about creating minimal products.
That changes the cost question. A small product is priced by its features. An experiment is priced by what it has to prove, to whom, and how confidently. Two MVPs with the same feature list can cost very different amounts because one has to show that people will pay and the other only that they will sign up.
One disclosure before the rest. We build MVPs for established companies launching new products and for funded scale-ups, and we do not publish prices, for the reasons below. The definitions quoted here come from their authors, not from us.
Prototype, MVP or full product
The cheapest MVP is often the one you do not need to build. Three different tools get called an MVP, and each answers a different question at a very different cost.
| Dimension | Clickable prototype | MVP | Full product |
|---|---|---|---|
| Answers | Do people understand the idea and want it? | Will people use it, and pay or switch for it? | Can it serve the whole market well? |
| Who uses it | Test participants, for a session | Real users, doing real work | Every customer |
| Built with | Design tools, no production code | Production code, a narrow scope | Production code, the full scope |
| Cost is driven by | The number of flows to show | The question, the users and what must survive | The full scope and its integrations |
| The real risk | Mistaking interest for demand | Throwing the code away when it works | Building what nobody tested |
The difference between an MVP and a prototype is the difference between opinions and behaviour. A prototype shows what people say they would do. An MVP shows what they actually do when the product is real, the data is theirs and using it costs them time or money. If you still need the first answer, get it from a designed prototype before you pay for the second.
What decides MVP development cost
Once you know an MVP is the right tool, its cost moves with a handful of scope decisions. The number of screens is rarely the largest of them.
| Driver | What to state in your brief | Why it moves the number |
|---|---|---|
| The question | The one decision the MVP informs, and the result that means go | Without it there is no test for what to leave out, so scope grows |
| Users | Who will use it, how many, and how they will be reached | Ten invited users and a public launch are different products |
| Platforms | Web, mobile, or both | Each platform adds build and testing |
| Integrations | The systems it must exchange data with | Each one is a small project, and the most often underpriced |
| What must survive | The parts that carry on if the answer is yes | Built-to-last parts cost more now and far less later |
| Data and security | Whose data it holds and what rules apply to it | Real customer data brings real obligations, even in a first version |
| Measurement | How you will see what users do | An MVP nobody can measure answers nothing |
The first line matters most. An MVP scope that states its question is short, because everything that does not help answer it can wait. The scope our MVP page sets out starts there for that reason.
Throwaway or foundation: the cost nobody quotes
The most expensive MVP is the one that works. Customers want more, the team wants to move fast, and the code turns out to have been built to be thrown away. The rebuild arrives exactly when the product has momentum.
Fred Brooks gave one chapter of The Mythical Man-Month the title Plan to Throw One Away, arguing that the first system built is usually not the one that should be kept. The useful reading for an MVP is not that everything should be thrown away. It is that the decision should be made on purpose, part by part, before the build.
- Build to last: the data model, how users and accounts work, and for a SaaS MVP the tenancy and billing model. Replacing these later means migrating every user.
- Keep temporary on purpose: admin screens, manual steps behind the scenes, reports, and anything you are not yet sure customers want.
- Write the split down, so that if the answer is yes, everyone knows which parts get rebuilt and which carry on.
Questions that set an MVP quote
Answer these before you ask for quotes, and give every vendor the same answers. Quotes that assumed different answers are pricing different experiments.
What decision will the MVP inform?
Fund the full product, change it, or stop, and who makes that call.
What result means go?
A number with a date, agreed by the people who fund the next stage.
Who will use it, and how will they be reached?
Invited users, a pilot customer or a public launch.
Which platforms and integrations are needed?
The fewest that still give a real answer.
Which parts must survive if it works?
And which are temporary on purpose.
What data will it hold?
And which rules apply to it from the first user.
Who owns the code and accounts?
You should, from the first day, whatever the answer turns out to be.
Is your MVP ready to be quoted?
Tick what your brief states today. Each unticked line is a place where vendors will assume differently.
Ways to reduce MVP cost that hold up
- Narrow the question, not the quality. One question answered well is cheaper than three answered badly.
- Answer opinion questions with a prototype first, and spend on code only for questions about behaviour.
- Do things by hand behind the scenes until you know they are worth automating.
- Choose fewer users you can reach directly over a public launch you will need to support.
The saving that rarely holds is the cheapest quote that left out what must survive. If the MVP works, that part is paid for again.
When you should not build an MVP
- Nobody agrees what it has to prove. The result will be argued about instead of acted on.
- Demand is already proven. If customers are already paying for a manual version, build the product.
- A prototype would answer the question. Spend on code only when you need behaviour.
Questions about MVP development cost
How much does MVP development cost?
It depends on the question the MVP has to answer, the users and how they are reached, the platforms and integrations, the data it holds, and which parts must survive if it works. Those move the quote far more than the number of screens. Settle them first and quotes become comparable.
What is the difference between an MVP and a prototype?
A prototype is a designed, clickable model with no production code, used to learn whether people understand and want an idea. An MVP is working software used by real people, used to learn whether they will actually use it and pay or switch for it. A prototype tests opinions; an MVP tests behaviour.
Can the MVP code be used for the full product?
Some of it should be. Decide before the build which parts are built to last, such as the data model, accounts and for SaaS the tenancy and billing model, and which are temporary on purpose. Then the full product grows from the MVP instead of replacing it.
How long does it take to build an MVP?
It depends on the same decisions as the cost, above all the question it must answer. A narrow question gives a short build. We plan MVPs in short stages with real users from early on, rather than one long build to a launch.
Should an MVP have a fixed price?
It can, when the question, users, platforms and test of success are written down, because then the scope is too. A fixed price on a vague MVP brief moves the risk into change requests.
Method and sources
The definitions below we read at source in October 2026. The keyword volumes behind the topic come from a Semrush pull for the US on 5 October 2026. The cost drivers, the questions and the advice on what to build to last are our judgement from scoping and building first versions, written as judgement rather than as data. We publish no prices, ranges or durations.
- Minimum Viable Product: a guideEric Ries, Startup Lessons Learned, 3 August 2009. The definition of the MVP as the version that collects the maximum validated learning with the least effort, and the warning that it is not about creating minimal products
- The Mythical Man-Month: Essays on Software EngineeringBrooks, Addison-Wesley, 1975. Chapter 11, Plan to Throw One Away
