Prototype vs MVP: which one do you need?

People use "prototype" and "MVP" as if they mean the same thing. They do not, and mixing them up usually costs a founder several weeks and a chunk of budget.

What a prototype actually proves

A prototype is a mock-up. It might be a clickable Figma file or a thin build with fake data behind it. It looks like the product, but nothing underneath actually works. A prototype answers one question: can we build this, and does it make sense once it is in front of someone?

That is a legitimate thing to want to know before you spend real money. Prototypes are cheap, fast to change, and great for pitching investors, briefing a development team, or testing a flow with a handful of users in a room.

What an MVP actually proves

An MVP is a real, working product with the smallest useful set of features. It answers a harder question: will real people use this, and will they come back? You cannot answer that with a mock-up, because the behaviour you are trying to observe — someone signing up, paying, returning next week — only shows up when the thing genuinely works.

The practical difference

• Risk being tested. A prototype tests design and concept risk. An MVP tests market and behavioural risk.
• Data. A prototype can fake its data. An MVP needs a real backend, even a simple one.
• Cost. Prototypes usually run to a few thousand pounds and a couple of weeks. An MVP is a bigger commitment — see our guide to MVP costs in the UK for real numbers.
• What you learn. A prototype tells you what to build. An MVP tells you whether anyone wants it.

So which one do you need?

If you are still unsure whether the idea itself makes sense — whether the flow is confusing, whether the value proposition lands — start with a prototype. It is the cheapest way to find a fundamental flaw before it is expensive to fix.

If the concept is validated (you have talked to users, you have a clear hypothesis about why they will pay or return) and what is left to learn is genuine behaviour, go straight to an MVP. Building a polished prototype first, in that case, is usually wasted motion.

Some teams need both, in sequence: a prototype to pressure-test the idea with stakeholders or early users, then an MVP once the direction holds up. That is exactly what our BUILD.ONE sprint is built for — a week to get a real, testable core feature in front of users before you commit to the full build.