Answer
Prototype or MVP — which to build first, and what the price difference is
A prototype exists to show an idea and does not have to work; an MVP is a product a real user uses. Confusing the two is the most common source of budget arguments.
The short answer: if your question is "is this understandable and interesting" — a prototype. If it is "will people actually use this" — an MVP. Two completely different things, bought at completely different prices, and nearly every budget argument we have seen started with one side pricing the first while the other expected the second.
What is the difference in practice?
A prototype can be screens wired together with no server behind them. The data is invented, errors are unhandled, and clicking in the wrong place does nothing. That is entirely sufficient to show an investor how it looks or to test with a user whether the path makes sense.
An MVP has to persist data, identify a user, cope with failure and be measurable. The gap between them is not in the design but in everything underneath it, which is why it is measured in multiples rather than percentages.
| Prototype | MVP | |
|---|---|---|
| Answers | Is this understandable and interesting | Will people use it |
| Data | Invented | Real and persisted |
| Failure states | Not required | Required |
| Measurement | None | Mandatory |
| Typical timeline | Days to weeks | Six to twelve weeks |
So which comes first?
In most cases the prototype, and for the economic reason precisely: it exposes misunderstandings cheaply. A screen that is obvious to the founder and opaque to a user is a discovery worth a lot when it costs three days, and much less when it costs three months.
The exception is when your question is already about behaviour rather than comprehension — whether people return, or whether they pay. A prototype cannot answer that in any form, so there it is better skipped in favour of going straight to a narrow version that works.
And what about a landing page?
There is a third option that precedes both and is almost always forgotten: one page describing the offer and asking for a reply. It does not test whether the product is good, but it tests whether the promise is interesting enough that somebody leaves their details, and it costs days rather than weeks.
What it cannot answer is whether people will actually use the thing, because signing up is not using. So it is a preliminary stage rather than a substitute: it filters out promises nobody finds interesting, and leaves the prototype and the first version to answer the questions only real use can.
Is a prototype wasted money?
Only if you build it like a product. A prototype should be cheap enough that throwing it away does not hurt, which is also why building it in production code is a mistake — the moment code exists people start wanting to preserve it, and decisions start following what was already built rather than what is right.
What does carry over from prototype to MVP is the decisions: the user path, the hierarchy, what turned out to be unnecessary. That is the expensive part, and it is preserved. We set out how to cut scope in how to define an MVP that doesn't blow up, and how to find the users who will test both in the first ten users.
As for price: what determines it is not which of the two you chose but how many states the system has to handle. The variables are set out in how much app development costs.
In short
- A prototype answers "is this understandable"; an MVP answers "will they use it".
- The gap is not in the design but in everything beneath it.
- A prototype should be cheap enough that throwing it away does not hurt.
From our own work
Nearly every budget argument we have watched between a founder and a supplier began with one side pricing a prototype while the other expected a working product — one written question about failure states and measurement prevents it almost every time.
Recurring questions
Can you show a prototype to an investor?
Yes, and it is a common and entirely legitimate use — provided you do not present it as a working product. An experienced investor spots the difference immediately, and trying to blur it damages trust more than it helps. What convinces at an early stage is usually not the product but what you learned from the users you spoke to.
How much does a prototype cost versus an MVP?
We will not print numbers that will soon be wrong, but the ratio is consistent: a prototype is an order of magnitude cheaper, because everything beneath the interface is not built. What makes an MVP expensive is authentication, persistence, failure states and measurement — not the screen count, which is exactly the part the prototype does include.
Can a prototype become an MVP?
The decisions can carry over; the code usually should not. A prototype is built fast and deliberately without failure handling or real data, and completing that afterwards typically costs more than rewriting on the basis of what you learned. Plan it up front as something you throw away.
Sources
- Why you only need to test with 5 users — Nielsen Norman Group (2026-08-10)
Keep reading
Article
The first ten users — how to get them before there is a product
Ten real users before launch are worth more than a thousand sign-ups after it, because they change what gets built. The way to get them is conversations rather than marketing, and it can start before a line of code exists.
8 min read ·
Answer
How long does it really take to build an MVP
A realistic range is six to twelve weeks for a narrow first version a real user actually uses. What decides where you land in that range is decision clarity, not development speed.
5 min read ·
Article
How to define an MVP that doesn't blow up halfway
Most scopes do not grow because of new requests; they grow because of deferred decisions. The one tool we have seen work is stating version one as a single question the product has to answer.
8 min read ·