Founders often use "MVP", "prototype" and "proof of concept" as if they were three sizes of the same thing. They are not. Each one exists to answer a different question, and each one is built differently because of it. Pick the wrong one and you either spend months building something that cannot answer your question, or you answer a question nobody was asking.
The simplest way to keep them apart is to name the question first and let the question choose the tool.
Three questions, three tools
Every new product carries three kinds of risk:
- Technical risk. Can this be built at all, with the data, integrations and performance it needs?
- Usability risk. Will people understand what the product is and how to use it?
- Market risk. Will people actually use it, come back, and pay?
A proof of concept deals with the first. A prototype deals with the second. An MVP deals with the third. Everything else follows from that: who sees the work, how polished it needs to be, how much effort it takes and what you do with it afterwards.
Proof of concept: can it be done
A proof of concept is a small technical experiment. It exists to show that one specific, uncertain thing works. Can a model extract the fields you need from scanned invoices with acceptable accuracy? Can the legacy system's API return the data fast enough for a live dashboard? Can two hardware devices talk over the protocol the vendor claims to support?
A good proof of concept has these traits:
- It targets one question, stated in writing before work starts, with a pass mark agreed in advance.
- It ignores everything that is not that question. No sign-in, no styling, no error handling beyond what the test needs.
- Its audience is the team, and sometimes a technical adviser or an investor's due diligence.
- It is thrown away, or at most mined for a few useful pieces of code.
In effort, a proof of concept is usually the cheapest of the three: one or two engineers for days or a few weeks. The main cost is discipline. The temptation is to keep adding features once the core idea works, and at that point the experiment has quietly become an unplanned product with none of the structure a product needs.
If nothing about your product is technically uncertain (a booking tool, a marketplace, a CRM for a niche) you can skip this step entirely.
Prototype: will people understand it
A prototype is a model of the product that people can look at and click through. It tests whether the idea makes sense to the people it is for: whether they understand the offer, find their way through the main flow and recognise their own problem in it.
Prototypes range widely in fidelity:
- Paper sketches or wireframes, to agree the structure and the order of screens.
- Clickable design mock-ups, to test the flow with real users in short sessions.
- A coded front end with fake data, when the interaction itself is the question (a complex editor, a drag-and-drop planner).
Most of the value comes from watching five or six target users try to complete a task with it. Where they hesitate, misread a label or give up, the design changes, and it changes cheaply, because nothing behind the screens exists yet.
A prototype is also a strong tool for alignment. Co-founders, investors and the future engineering team all see the same thing, which removes a lot of the ambiguity that a written specification leaves behind.
What a prototype cannot tell you is whether people will use the product in their real lives. People are polite in testing sessions. Clicking through a mock-up costs them nothing. That gap is what the MVP is for.
MVP: will people use it, and pay
A minimum viable product is the smallest real product that real users can use for a real job. It stores real data, runs in production and can take money if the model calls for it. Its purpose is to test the assumption most likely to sink the business, usually about demand or willingness to pay, with behaviour rather than opinion.
The words that matter are "smallest" and "real":
- Smallest means the product does one core job and little else. Every feature that does not help test the key assumption waits.
- Real means users rely on it. It needs working sign-in, a sensible data model, basic security, error tracking and a way to measure what people do. Cutting these does not make an MVP leaner, it makes its results unreliable.
An MVP is the most expensive of the three because it is production software: typically a small team over a few months rather than weeks. It is also the only one of the three whose code is meant to survive, at least in part. That is why the architecture decisions made here (the data model, the tenancy model, the hosting setup) deserve more care than anything in a prototype.
An MVP does not have to be an app. For some ideas the smallest real product is a landing page with a waiting list, a manual service run behind a simple form, or a no-code tool. If that answers the question, it is the right MVP.