These three get used as synonyms in most kick-off meetings, usually with the assumption that they describe the same thing at different budgets. They do not. Each one answers a different question, and the expensive mistake is not choosing badly — it is choosing without noticing there was a choice.

The short version:

  • A proof of concept asks can this be made to work at all?
  • A prototype asks is this the right thing to make, and does it read clearly?
  • An MVP asks does anyone actually want this, enough to give something up for it?

Feasibility, then design, then demand. You rarely need all three, and the order in which you need them depends entirely on where your real risk sits.

Proof of concept: can this work?

A proof of concept is an internal technical answer. It exists to remove doubt about whether something is achievable — a model that has to hit a certain accuracy, a hardware integration, a data pipeline that has to run inside a latency budget, a regulatory constraint that might make the whole idea illegal.

What it looks like: usually ugly, often a script or a notebook. No interface worth the name. Frequently thrown away entirely once the question is answered.

Who sees it: the founding team, a technical co-founder, sometimes an investor who has asked a pointed question.

How long it takes: days to a couple of weeks. If it is running longer, it has usually stopped being a proof of concept and become a first build.

What it produces: a go or no-go on feasibility, and a much better estimate of what the real thing will cost.

When you need one: only when the technical risk is genuinely the thing that could kill you. This is rarer than founders think. Most startups are not blocked by whether the software can be written. They are blocked by whether anyone cares. Building a proof of concept for a CRUD application with a payment integration is proving something nobody doubted.

There is one honourable exception: sometimes you build a proof of concept not because you doubt feasibility but because an investor or an enterprise buyer does. That is a sales artefact wearing an engineering costume, and it is fine — just be clear with yourself about which one you are funding.

Prototype: is this the right design?

A prototype simulates the experience without building the machinery underneath. Clickable screens, realistic content, a flow that a person can walk through and react to.

What it looks like: interactive screens, increasingly indistinguishable from a real product to the person using it. The difference is that nothing behind the interface is real.

Who sees it: target users, stakeholders, sometimes buyers.

How long it takes: days to three weeks, depending on how much of the journey you cover.

What it produces: design decisions you no longer have to argue about, and a list of places where people got confused.

When you need one: when the risk is comprehension or workflow rather than demand. Complex B2B tools, anything replacing an entrenched process, anything where the value only becomes obvious once you see the thing in motion.

Prototypes are dramatically underused, mostly because they feel like a detour. They are not. A prototype is the cheapest place in the entire product lifecycle to be wrong. Changing a flow in a design file costs an afternoon. Changing the same flow after it is built, tested, documented and shipped costs a sprint and a difficult conversation.

The other reason to build one: five users will find roughly 85% of the usability problems in a design, according to Jakob Nielsen's long-standing research at Nielsen Norman Group — and his recommendation is not one large study but three small ones, fixing problems in between. That cycle is only affordable before code exists.

Worth saying plainly: a prototype can also produce real commercial evidence. Todd Jackson's account of early-stage validation includes Cocoon securing its first customers on the strength of Figma prototypes alone. If someone signs something on the basis of a prototype, that is demand evidence, not design evidence, and it counts.

MVP: does anyone want it?

An MVP puts a real thing in front of real people who give up something real to use it. Money, time, data, or the inconvenience of switching away from what they use today.

What it looks like: narrow but complete. One journey that works end to end, properly.

Who sees it: early adopters and paying customers — not friends, not advisors, not people who are being polite.

How long it takes: weeks to a few months. If it is tracking past four months, something has gone wrong with scope rather than with engineering.

What it produces: behaviour. Sign-ups that convert, usage that repeats or does not, cancellations with reasons attached.

When you need one: when the open question is demand, and you have already satisfied yourself that the thing can be built and that people can understand it.

The trap here is treating the MVP as the default first move. It is usually the third.

How to choose in one pass

Work through these in order and stop at the first yes.

  1. Is there a real chance this cannot be built, or cannot be built legally or economically? Proof of concept.
  2. Is there a real chance people will not understand it, or that the workflow is wrong? Prototype.
  3. Is the only genuine unknown whether anyone wants it badly enough to act? MVP.
  4. Is the honest answer "we don't know what our riskiest assumption is"? None of the three. Go and talk to twenty potential customers first. Everything downstream is cheaper once that is done.

That fourth branch catches more teams than the first three combined. Eisenmann's false start pattern describes exactly this: building fully functional offerings before researching whether the need exists. The tell is a team that can describe its solution in detail and its customer only in demographics.

The sequencing most early teams actually need

For the majority of software businesses we see, the honest order is:

Conversations → prototype → MVP, with a proof of concept inserted only if there is a specific technical unknown that can end the company.

Conversations establish that the problem is real and sharply felt. The prototype turns your solution from a description into something people can react to, which is when you discover that your mental model and theirs differ. The MVP then tests whether that reaction converts into behaviour when something is at stake.

Skipping the middle step is the common error. It feels efficient — why design screens when we could be building the real thing? — and it reliably costs more than it saves, because the design decisions get made anyway, just later, in code, under deadline pressure, by whoever is closest to the keyboard.

A note on what these are worth to other people

Investors, in our experience, read these three artefacts differently than founders expect. A proof of concept mainly answers a question they did not have. A polished prototype demonstrates taste and clarity of thinking, which matters more than it should. But the thing that moves a conversation is evidence of demand — a waiting list with real names on it, letters of intent, ten paying customers, a retention curve that does not collapse.

Which is another way of saying: choose the artefact that answers your riskiest question, and let the fundraising benefit be a side effect rather than the goal. Artefacts built to impress tend to answer nothing.

If you are trying to work out which of the three your next quarter should produce, the deciding question is not budget. It is which sentence you cannot currently finish with confidence: we know it can be built, we know people understand it, or we know people want it.

We work through exactly that sequence with founding teams inside product and UI/UX design, and the first deliverable is usually a decision rather than a screen. If the answer turns out to be "we need to see it before we can judge it," that is a prototype — and it is the cheapest useful thing most teams are not building.

Common questions

What is the main difference between a prototype and an MVP?

A prototype simulates the experience to test whether the design is right; nothing behind the interface is real and nothing is at stake for the user. An MVP is a working product placed in front of real users who give up something real — money, time or data — to test whether demand exists.

Do I need a proof of concept before an MVP?

Only if there is a genuine technical unknown that could end the company: a model that must hit an accuracy threshold, a hardware integration, a regulatory constraint. Most software startups are not blocked by feasibility. Building a proof of concept for a standard web application proves something nobody doubted.

Can a prototype be used to sell?

Yes, and it frequently is. Early customers have signed letters of intent and design partner agreements on the strength of prototypes alone. When someone commits on the basis of screens, that is demand evidence rather than design evidence, and it counts as validation.

Which comes first: prototype or MVP?

Prototype, in almost every case. Design decisions get made either way — the only question is whether they are made cheaply in a design file or expensively in code under deadline pressure. Skipping the prototype feels efficient and reliably costs more than it saves.

How much should a proof of concept cost?

Far less than either of the other two, because it exists to answer one narrow question and is usually discarded afterwards. If a proof of concept is running for more than two or three weeks, it has generally stopped being an experiment and become a first build under a different name.

Sources and further reading