In short
A proof of concept tests whether a risky technical mechanism is feasible. A prototype represents the experience to test comprehension, flow, or desirability. An MVP delivers the smallest real outcome to real users so the team can test behaviour, operations, or payment. Choose the artefact that answers the current risk with the least commitment.
One table
| Artefact | Primary question | Audience | Expected output |
|---|---|---|---|
| Proof of concept | Can the risky mechanism work? | Technical team and decision-makers | Feasibility evidence and constraints |
| Prototype | Can people understand and use the proposed experience? | Representative users and team | Flow, comprehension, and design evidence |
| MVP | Will real users receive and value the outcome? | Bounded real audience | Behavioural, operational, or commercial evidence |
Proof of concept
A POC isolates technical uncertainty: can a model classify the data accurately enough, can the legacy API support the workflow, can the device capture the signal, or can a performance target be reached?
It may be ugly, insecure, manually operated, and unsuitable for users. That is acceptable when it is contained and clearly not production.
A useful POC ends with:
- result against success criteria;
- observed limits and failure modes;
- data or infrastructure assumptions;
- recommendation to proceed, change, or stop;
- work required to productionise the approach.
Do not quietly turn experimental POC code into production merely because it appears to work once.
Prototype
A prototype represents structure and interaction. It may range from sketches to interactive design or coded behaviour.
Use it to test:
- whether the value is understood;
- information hierarchy;
- sequence and navigation;
- terminology;
- important states;
- competing design directions.
Prototype tests reveal where people hesitate and why. They do not prove reliability, willingness to pay, or repeated use.
MVP
An MVP delivers the real core value, even if internal operations remain manual and the feature set is narrow.
It needs:
- a defined audience and hypothesis;
- a complete value path;
- necessary data and rules;
- safe access and permissions;
- failure and support paths;
- measurement;
- operational ownership.
The MVP costs more because it creates real obligations, not because it needs every future feature.
A sensible sequence
Use POC → prototype → MVP when both technical and experience uncertainty are high. Use only a prototype when the technology is ordinary. Move directly to a concierge MVP when interaction is simple but delivery and demand are uncertain.
The sequence is not maturity theatre. Each step must earn the next investment.
Common questions
Which comes first: POC or prototype?
Start with the risk that could invalidate the project most cheaply. Technical feasibility may require a POC first; comprehension or workflow may require a prototype.
Is a POC shown to users?
Usually not. It is often unsafe, incomplete, and designed to test a technical mechanism rather than deliver an experience.
Can a prototype become an MVP?
Sometimes coded prototypes can be hardened, but plan explicitly for data, security, accessibility, errors, monitoring, testing, and maintainability. Do not assume the transition is automatic.
Does an MVP need a POC?
Only when important technical feasibility remains uncertain. Ordinary product functionality does not need a ceremonial POC.
How do we know when to move forward?
Define success and stop criteria before each artefact. Proceed when the evidence reduces the targeted risk enough to justify the next investment.
