Three words get used interchangeably in the same meeting, and the confusion costs real money. Someone asks for an MVP when what they need is a proof of concept. Someone builds a polished prototype and is surprised it cannot go live. The words describe genuinely different things that answer genuinely different questions, and the first step in building the right thing is knowing which question you are actually asking.
Proof of concept: does this even work
A proof of concept exists to answer one narrow, technical question: is this risky thing possible at all? Can this model be accurate enough to be useful? Can we process this volume in the time we have? Can these two systems talk to each other the way the integration promises? It is not concerned with how the software looks, whether it is pleasant to use, or whether the code is fit to keep. It is a spike aimed straight at the single biggest doubt.
The defining trait of a proof of concept is that it is throwaway by design. You build the least possible thing that settles the question, you get your yes or no, and then you delete it. Trying to keep proof-of-concept code and grow it into a product is one of the most reliable ways to inherit a mess, because it was never built to survive — it was built to answer a question fast. When the risky part is technical and unproven, this is what you build first, and nothing else matters until you have the answer.
Prototype: how would it look and feel
A prototype answers a completely different question: how should this work for the person using it? It is about the experience — the flow, the layout, the feel of moving through a task. A prototype can be clickable screens with no real logic behind them, or a thin shell that looks convincing in a demo. Its whole purpose is to make something concrete enough that you and your users can react to it, argue about it, and change it before it is expensive to change.
Crucially, a prototype is not production software and is not trying to be. The data behind it is fake, the edge cases are ignored, and the code — if there is real code at all — is not built to last. That is not a shortcut; it is the correct trade. You are buying feedback on the design cheaply, while it is still cheap to be wrong. The mistake is to demo a convincing prototype to a stakeholder who then assumes it is nearly done. It looks finished. It is nowhere near finished. It has simply answered the design question, which was its only job.
MVP: the smallest real product
An MVP — a minimum viable product — is the one of the three that is genuinely real. It is the smallest version of the product that delivers actual value to actual users and can go live. Real data, real edge cases, real security, real reliability. The minimum in the name refers to scope, not to quality: you build the fewest features that make it genuinely useful, but those features have to work properly, because real people are going to depend on them.
This is where the most damage is done, because minimum gets misread as rough. An MVP is not a proof of concept with a nicer screen, and it is not a prototype you decided to ship. It is a product — smaller than the eventual product, but built to the same standard within its narrow scope. It answers the question that matters most to a business: will people use and value this when it is real? That question can only be answered by something real, which is exactly why an MVP costs more than the other two and takes longer to build.
Match the artefact to your actual question
The whole point of the distinction is this: each one answers a different question, and building the wrong one wastes the money and, worse, gives you a confident answer to a question you were not asking. So start by naming your real question honestly.
If your biggest doubt is technical — can this be done at all — you want a proof of concept, and building an MVP first is madness, because you might spend months on a polished product around a core that turns out to be impossible. If your biggest doubt is about the experience — will people understand this, will the flow make sense — you want a prototype, and jumping to a fully built MVP means paying full price to learn something a week of clickable screens would have told you. And if the technology is proven and the design is broadly understood, and your real question is whether the market wants it, then you want an MVP, because only a real product answers that — a prototype will get you polite enthusiasm that evaporates the moment money or effort is required.
Naming the question out loud also protects you from a subtler trap: having several real questions and pretending you can answer them all at once. A project often carries a technical risk and a design risk and a market risk together, and the instinct is to build one big thing that settles everything. It never does. It settles nothing cleanly and costs more than settling any one of them would have. The disciplined move is to rank your uncertainties and take them in order — the riskiest first, the cheapest artefact that answers it, then the next. Each answer shrinks the problem and sharpens what you build after it.
The classic mismatch, in both directions
The most common and expensive error is asking for an MVP when you needed a proof of concept. It happens because MVP is the fashionable word and it sounds like the responsible, lean choice. But if the core technical risk is unproven, wrapping it in a real product first means you build all the surrounding scaffolding — the accounts, the payments, the polish — before you know whether the thing at the centre can work at all. When the centre fails, all of that was waste.
The reverse happens too. A team commissions a throwaway proof of concept, gets a promising result, and then — under time pressure — tries to ship the throwaway. The code was never meant to carry real users; it has no error handling, no security worth the name, no tests. It runs in the demo and falls over in the world. Both mistakes come from the same root: not being clear, out loud, about which question was being answered before the work started.
Both errors also share a quieter cause: someone optimised for how the request sounded rather than for what it would answer. Asking for an MVP sounds committed and serious; asking for a proof of concept sounds tentative, and shipping one sounds fast. So people reach for the word that flatters the moment and inherit the wrong artefact along with it. The cure is unglamorous but reliable — before anyone estimates or builds, write down in one plain sentence what question this work is meant to settle, then check that the thing being asked for is actually capable of settling it.
Throwaway versus foundation
There is one line worth drawing under all three, because it decides how you should treat the code. A proof of concept and most prototypes are throwaway — their value is entirely in the answer they produce, and the code itself should be discarded without a second thought. An MVP is a foundation — it is the first real floor of the building, and everything after it grows on top, so it has to be built like something that will be built upon.
Confusing these two categories is where projects rot. Treat a throwaway as a foundation and you build a product on scaffolding that was never load-bearing. Treat a foundation as a throwaway and you cut corners on the very thing everything else will rest on. Decide, before you write a line, which category the work belongs to — and then hold to it, especially when the schedule tempts you to promote a throwaway into a foundation it was never built to be.
Start with the biggest unknown
If you take one rule from all of this, take this one: build first whatever kills the most uncertainty. Every project has a biggest unknown — a technical risk, a design question, a market doubt — and the right first thing to build is whatever answers that unknown fastest and cheapest. Not the easiest thing, not the most exciting thing, and not the thing that photographs well in an update. The thing that, if the answer is no, you would most want to have found out before spending the rest of the budget.
There is a reason this rule is hard to follow, and it is worth naming. The biggest unknown is usually the scariest one, which is exactly why teams avoid building toward it first — they start with the parts they already know how to do, because those parts feel like progress and produce something to show. But work on the easy parts does not reduce the risk that can kill the project; it just delays the moment you confront it, and it spends budget you will wish you still had when the hard answer finally arrives. Momentum on the wrong thing is not progress. It is expensive procrastination with good production values.
Name your biggest unknown, pick the artefact that answers it — proof of concept for a technical risk, prototype for a design risk, MVP for a market risk — and resist the pull to build more than that first step requires. Certainty is the thing you are actually buying at this stage. Buy it in the cheapest order, and let each answer tell you what to build next.