In short
A prototype is a disposable or limited representation used to test comprehension, flow, desirability, or technical direction before full implementation. An MVP is the smallest real product that delivers the intended outcome and creates behavioural or commercial evidence. Build the cheapest artefact capable of answering the current uncertainty.
The evidence is different
| Prototype | MVP |
|---|---|
| Tests comprehension, flow, desirability, or feasibility | Tests real use, delivery, retention, or payment |
| Can use simulated data and interactions | Produces the core outcome through a real system or service |
| Usually disposable or incomplete | Operated and supported for real users |
| Days or weeks | Weeks or months |
| Lower cost and risk | Higher cost and stronger behavioural evidence |
A prototype can show whether people understand a workflow. It cannot prove they will adopt it repeatedly or pay when the outcome is real.
Build a prototype when
- the team disagrees about the flow;
- users cannot understand the concept from words;
- interface risk is high;
- several directions need comparison;
- a technical spike can test feasibility;
- building the complete system would be an expensive way to discover a basic mistake.
Prototype fidelity should match the question. Paper sketches can test sequence; an interactive prototype can test navigation; code may be required to test performance or integration feasibility.
Build an MVP when
- the value proposition is understandable but adoption is uncertain;
- payment or commitment must be tested;
- real data changes the experience;
- operations and fulfilment are part of the hypothesis;
- repeat behaviour matters;
- the team needs evidence from actual use rather than stated preference.
An MVP can use manual work behind the scenes, but the user's promised outcome must be real.
The common sequence
- Clarify the riskiest assumption.
- Test language or demand with low-cost evidence.
- Prototype the uncertain journey or technology.
- Correct the model before implementation.
- Build one complete MVP workflow.
- Release to a bounded audience.
- Decide from observed evidence.
Not every product needs every artefact. Skip the one that cannot reduce current uncertainty.
Common mistakes
Treating a polished prototype as a product
Animations can hide missing data, permissions, errors, operations, and integration behaviour. State clearly what is simulated.
Building production infrastructure to test wording
If the uncertainty is whether buyers care, a landing page, interview, or concierge test may answer it faster.
Calling an incomplete product an MVP
Missing failure states, support, analytics, or a real outcome creates weak evidence because users are reacting to incompleteness rather than the proposition.
Common questions
Can a prototype be built in code?
Yes. Use code when the uncertainty involves technical feasibility, interaction performance, device capability, or integration. It can still be disposable.
Can an MVP be no-code?
Yes. If a no-code system delivers the real core outcome safely and produces useful evidence, it can be an MVP.
Should investors see a prototype or MVP?
That depends on the claim. A prototype communicates the concept; an MVP can provide stronger evidence about real use, delivery, and demand.
How long should prototyping take?
Long enough to answer the defined question, often days to a few weeks. Stop when additional polish no longer improves the decision.
Is a beta the same as an MVP?
No. Beta describes a release stage or audience for a functioning product. An MVP describes the smallest product designed to test core value.
