MVP
MVP vs Prototype vs Proof of Concept: What's the Difference?
By Tom Bore · 3 August 2026 · 6 min read
Proof of concept, prototype and MVP get used as if they mean the same thing. They don't, and building the wrong one costs you a month. Each answers a different question.
A proof of concept tests whether the hard part can work. A prototype tests whether people can use it. An MVP tests whether people want it. Pick the one that matches the question you're stuck on.
| Tool | Question it answers | What you build |
|---|---|---|
| Proof of concept | Can the hard part work at all? | The smallest test of the risky bit, often a bare script |
| Prototype | Can people understand and use it? | A clickable mock of the experience, no real back end |
| MVP | Do people want it? | The smallest real product you can put live and learn from |
Proof of concept: does it work?
Reach for a proof of concept when your idea rests on something unproven, like a model that has to hit a certain accuracy or a third-party system you don't control. You build the least you can to get a yes or no, then throw it away. It tests feasibility and nothing else. We covered the practical versions in proof of concept ideas.
Prototype: can people use it?
A prototype makes the experience real enough to react to, without the engineering underneath. A clickable design, a fake dataset, buttons that lead somewhere. You put it in front of people to see where they hesitate and what they misread. It tests the design, not the demand and not the tech.
MVP: do people want it?
An MVP is the first version that lives in the real world, where people sign up, use it and, ideally, pay. It tests demand with evidence rather than opinion. It's also the one teams get wrong most often, by quietly scoping the finished product and calling it an MVP. For a sense of how long a tight one takes, see how long it takes to build an MVP.
Run them in order, and skip what you don't need
The three stack from cheapest to most involved: proof of concept, then prototype, then MVP. You rarely need all three. Use the sequence as a filter:
- If the technology is the risk, start with a proof of concept. No point designing something you can't build.
- If the experience is the risk, prototype it before anyone writes production code.
- If the only real question is whether people want it, skip ahead and build the MVP.
How we choose at Honk Labs
We start from the single riskiest assumption and pick the cheapest tool that tests it. Sometimes that's a two-day proof of concept. Sometimes it's a prototype we can put in front of five people. Often it's a lean MVP live in weeks. The label matters less than being honest about which question you're answering and refusing to build more than that question needs. If you're not sure which stage you're at, tell us about the idea and we'll help you place it.