Prototype vs MVP: What to Build First and Why It Matters

Two firms quote you for the same idea. One says five weeks, the other says five months, and both describe the deliverable in roughly the same words. Usually nobody is being dishonest. One is quoting a prototype and the other is quoting an MVP, and those are different objects built for different reasons. Deciding which one you actually need, before you sign anything, is one of the cheapest high-leverage decisions in the whole project.

This guide sticks to that decision. For the money side of the second one, see what an MVP really costs.

The One Distinction That Resolves Most of the Confusion

A prototype exists to answer a question. An MVP exists to serve a real user, and to produce evidence from actual usage.

Fidelity, timeline and price all follow from that. A prototype is an instrument you point at an uncertainty: screens with fake data, a hard-coded demo, a rough script proving one integration is possible. It only has to be good enough to give you a trustworthy answer, and then its job is done. An MVP is a product - small, but genuinely in the hands of people who are not you, doing real work with real consequences. Real accounts, real data that persists, real failure modes, a real support burden.

Confusing the two is expensive in both directions. Teams spend MVP money to answer a prototype question, buying production plumbing before anyone has confirmed the idea is worth plumbing. Or they ship a prototype to real customers because it 'already works', and damage a reputation they spend a year rebuilding.

The Words Everyone Uses Loosely

There is no standards body for these terms, so everyone uses them differently. Here is the practical version, in rough order of cost:

• Wireframe - a grey-box layout of a screen. Answers 'what goes where'. Hours, not days.
• Mockup - a static, visually designed screen. Answers 'what will it look like'. No behaviour.
• Clickable prototype - linked screens you can move through, with fake data behind them. Answers 'does this flow make sense to a human'.
• Proof of concept - a narrow technical experiment, often ugly and command-line only. Answers 'can this be built at all, with this data, at this speed, against this API'.
• Pilot - a real product, deliberately limited to one team or one customer, with an end date and success criteria. Answers 'does this survive the messy real world before we roll it out'.
• MVP - the smallest version a real user can genuinely use to get real value. Answers 'will people adopt this, keep using it, and pay for it'.

Each One Targets a Different Risk

Being precise about the words matters because each artefact retires a different kind of risk. Pick the wrong one and you spend real money learning something you already knew.

• Technical risk - 'can this be built?' Handled by a proof of concept. Common with an unproven integration, a hard performance target, an undocumented legacy system, or an AI component whose accuracy on your data is unknown.
• Design and usability risk - 'is this the right thing, and will anyone understand it?' Handled by a prototype. Common when the workflow is novel, or the same feature means five different things to five stakeholders.
• Market risk - 'will people use this and pay for it?' Handled by an MVP. Prototyping never settles it, because opinions gathered in a demo are not behaviour observed in a product.

Prototype vs MVP: The Practical Comparison

The Throwaway Rule

A prototype should be cheap enough to throw away, and you should expect to throw it away. That expectation is not waste, it is the point. The moment you start protecting a prototype, you stop using it as an instrument and start treating it as an asset.

The most expensive mistake in this area is a prototype that quietly becomes production because it 'already works'. It works because it was allowed to skip everything: no auth model, no validation, no migrations, no tests, no error handling, no thought about who can see whose data. Those shortcuts do not announce themselves at launch. They surface six months later as a security review you cannot pass and a rewrite you have to fund while keeping the old thing alive.

So decide out loud, before the prototype is built, whether the code is allowed to survive, and write it into the brief. A team that knows the code is disposable builds the right prototype fast. A team that suspects it might be kept will over-engineer it, and you will pay MVP prices for prototype answers.

When a Prototype Is the Right First Step

• The user experience is genuinely unproven - a new workflow, an unusual data model, or an interface people have not seen before.
• Stakeholders cannot align on paper. Three people read the same specification and picture three different products; a clickable prototype ends that argument in an afternoon.
• There is a technically risky integration, a hard latency requirement, or a dependency on someone else's API that may not behave as documented. Here you want a proof of concept, not a pretty prototype.
• You are raising money and need to show rather than tell. Investors respond to something they can click far better than to a slide.

When a Prototype Is a Waste of Money

• The design is already well understood - a booking flow, a dashboard or a checkout that follows patterns your users know. Prototyping it teaches you nothing new.
• You are deliberately copying a proven pattern. Familiar is a feature; testing whether people understand a standard login screen is not a good use of five weeks.
• The real question is demand, not design. If you know what to build and only doubt whether anyone wants it, a prototype produces opinions when you need usage.
• You have already prototyped it once. A second round of screens is often procrastination wearing a project plan.

When to Skip Straight to an MVP

Go straight to an MVP when design risk is low and market risk is high: you can describe the core screens confidently, the technology is boring and well understood, and the only real unknown is whether people will adopt it.

Two other cases justify skipping. If the product is internal and the users sit in your own building, a week of watching people do the job manually beats any clickable demo. And if the MVP would take about as long as a serious prototype, build the MVP - do not spend three weeks proving something you could have built in five.

'Minimum' Describes the Scope, Not the Quality

This is the most damaging misreading in the whole vocabulary. 'Minimum' means fewer features, one user type, one workflow, one platform. It has never meant lower engineering standards. The moment a real person trusts your product with their data or their work, a floor of quality becomes non-negotiable. An MVP still needs:

• Real authentication and a real permissions model, even if there are only two roles.
• Real data persistence, with migrations, so you can change the schema later without losing what users created.
• Error states a human can act on, and a sane response when a third-party service is down.
• Basic security and privacy hygiene - encrypted transport, sensible secret handling, and a defensible answer on where personal data lives and who can reach it. If your users are in the EU or UK, that answer has to hold up.
• Logging and monitoring good enough that you learn something broke before your customer emails you.
• Something you can support - a way to reset a password, fix a bad record, and ship a patch on a Tuesday.

How to Decide, In Five Steps

1. Write down your riskiest assumption in one sentence. Not the whole idea - the one belief that, if wrong, makes everything after it pointless.
2. Classify it: technical, design, or market. That single word tells you which artefact you need - proof of concept, prototype, or MVP.
3. Pick the cheapest artefact that tests it honestly. Cheapest that works, not cheapest available; a prototype that cannot settle the question is not a saving.
4. Define in advance what result would change your mind. 'If four of six test users cannot complete the booking without help, we redesign the flow.' Written before you start, or it becomes a debate afterwards.
5. Set a time box and a decision date, then decide: keep, kill, or iterate. An artefact with no end date stops being an experiment and becomes a project.

What This Changes About Your Vendor Brief

Once you know which artefact you want, the conversation with a custom software development partner changes shape, and so does the estimate.

For a prototype, ask for a short fixed time box and say plainly that the code is disposable. The right questions are about the research: how many test users, what will be observed, what gets written down. A good partner will push back on scope, because a bloated prototype is a failed prototype.

For an MVP, ask what is being left out and why, then ask about the things that make it safe for real users: the auth model, the data model, error handling, deployment and rollback, and what happens when something breaks at 2am in your timezone. Estimates should be itemised by feature with the non-negotiable foundations on their own lines, not buried. If an MVP quote has no line for security, testing or deployment, it is a prototype quote with an MVP label on it. Ask who does the work too - a stable dedicated team matters far more on an MVP, where decisions compound, than on a prototype you intend to discard. If you are weighing this against building in-house, the trade-offs are in our guide to software development outsourcing.

Conclusion

A prototype answers a question and is meant to be thrown away. An MVP serves real users and is meant to be built on. Nearly every expensive mistake in early product work comes from blurring that line - paying MVP prices for prototype answers, or handing a prototype to paying customers and calling it a launch.

Name your riskiest assumption, pick the cheapest artefact that honestly tests it, set a deadline, and decide. If you want a second opinion on which one your idea needs before you commit a budget, talk to us.