MVP, prototype or proof of concept — which do you actually need?

These three get used interchangeably in the same sentence as a budget, which is how a founder ends up paying MVP money for a prototype, or trying to validate a market with a proof of concept nobody outside the building can use.

The distinction is not size. It is which question you are paying to answer.

The one-line version

Proof of concept: is this technically possible?

A PoC exists to retire technical risk, and nothing else. It is throwaway code that proves one hard thing works — that you can extract structured data from these documents at acceptable accuracy, that this legacy API can sustain the throughput, that the matching algorithm returns sensible results.

It has no design, no auth and no error handling. Showing one to a customer is a category error: it will look broken, because it is.

Prototype: does this make sense to a human?

A prototype is the opposite trade. It looks real and does nothing. Clickable screens, plausible fake data, no backend. Its job is to answer design and comprehension questions: does the flow make sense, do people find the thing that matters, does the pitch land.

Prototypes are cheap because nothing behind them is real, and they are excellent for investor conversations and user interviews. They are useless for anything that depends on real behaviour over time — retention, actual usage, willingness to pay.

MVP: will anyone use it for real?

An MVP is production software. Fewer features than the eventual product, but the features it has are real: real data, real accounts, real payments if payments are part of the hypothesis. It goes to actual users and it has to keep working when they use it.

The "minimum" is doing a lot of work in that acronym. Minimum means the smallest thing that can honestly test the hypothesis — not the smallest thing you can ship, and not a cut-down version of everything you eventually want.

This is the one people underestimate. An MVP still needs authentication, error handling, a deploy pipeline and somewhere to see what broke. Those are not features you can cut; they are the difference between software and a demo.

How to pick

1. Write down the single riskiest assumption in your idea.
2. If it is "we're not sure this is buildable" → proof of concept.
3. If it is "we're not sure people will understand it" → prototype.
4. If it is "we're not sure anyone wants it" → MVP. Nothing else answers that question, because nothing else survives contact with real users.

Most founders who ask for an MVP need an MVP. But a meaningful minority describe an MVP and then list the questions a prototype would answer for a fifth of the money — and it is worth ten minutes to find out which you are before spending the difference.

The expensive middle ground

The pattern that wastes the most money is the "MVP" that is really a prototype with a database bolted on: real enough to cost real money, not robust enough to put in front of customers. It usually happens when the scope was set by listing features instead of naming the hypothesis.

If you cannot finish the sentence "we will know this worked if…", the scope is not ready, whatever you call the thing.

Frequently asked questions