The three terms get used interchangeably, and that costs money. A founder who asks for an MVP when they need a prototype pays for working software to answer a question a clickable mock-up could have answered in a fortnight.
Proof of concept: can it be done?
A proof of concept (PoC) tests technical feasibility. It is usually small, internal and disposable: a script that proves two systems can talk to each other, a model that shows the data supports the prediction you need, a test that a third-party API returns what its documentation promises.
- Who sees it: the team, maybe an investor. Rarely a customer.
- What it looks like: often nothing — there may be no interface at all.
- What happens to it: usually thrown away once the question is answered.
You need one when the idea depends on something that might not be possible: an integration nobody has done, an AI capability you are assuming, data you are not sure you can get.
Prototype: will people get it?
A prototype tests the experience. It shows what the product will look like and how someone would move through it, without the engineering underneath. It ranges from paper sketches to a polished, clickable design that is hard to tell apart from a real app.
- Who sees it: potential users, stakeholders, investors.
- What it looks like: the real screens, wired together but not working.
- What happens to it: it becomes the specification for the build.
This is the cheapest point at which to change your mind. Changing a wireframe costs minutes; changing built software costs days. That is why our own process puts a prototype sign-off before any production code is written — see the four stages.
MVP: will people use it?
A minimum viable product is real, working software, released to real users, doing the one thing that needs proving. It is the first version that can produce evidence a prototype cannot: that people come back, that they pay, that the numbers work.
- Who sees it: real customers.
- What it looks like: a narrow product, finished to a standard people will trust.
- What happens to it: it becomes version one, so it has to be built to survive version two.
"Minimum" is about scope, not quality. An MVP with one feature done properly teaches you more than one with ten features done badly, because users judge what is there, not what is planned.
The three side by side
| Proof of concept | Prototype | MVP | |
|---|---|---|---|
| Question it answers | Can it be built? | Will people get it? | Will people use it? |
| Working code | Some | No | Yes |
| Real users | No | For testing | Yes |
| Kept afterwards | Rarely | As the spec | Becomes v1 |
| Relative cost | Low | Low | Highest of the three |
Which do you need first?
Start from your riskiest assumption and build the cheapest thing that tests it:
- If you are not sure it is technically possible, start with a proof of concept.
- If you are sure it can be built but not that people will understand or want it, start with a prototype and put it in front of the people you want as customers.
- If people have seen the prototype and the remaining question is whether they will use and pay for it, build the MVP.
Many products need two of the three and a few need all three. Skipping straight to an MVP is the expensive way to find out you needed a prototype. If you are weighing up the budget for that step, our guide to what an MVP costs in the UK has the 2026 market figures.