Martin Bell6 Min ReadUpdated Jul 13, 2026Proof of Concept vs Prototype vs MVP: What to Build and Why
A proof of concept tests feasibility, a prototype tests a proposed experience, and an MVP tests customer value. Choose from the uncertainty—not a fixed sequence.
A proof of concept (POC), prototype, and minimum viable product (MVP) answer different questions:
- POC: Can a critical technical, scientific, operational, or integration mechanism work under stated conditions?
- Prototype: How should the proposed concept or experience work?
- MVP: Will a specific customer use, buy, or repeat the value under real conditions?
They do not form a mandatory sequence. A team may build only one, run a POC and prototype in parallel, or sell a manual MVP before proving how to automate it.
POC vs prototype vs MVP comparison
| Dimension | Proof of concept | Prototype | MVP |
|---|---|---|---|
| Primary uncertainty | Feasibility | Interaction or concept | Customer or business value |
| Audience | Technical team, specialists, approvers | Test participants, team, stakeholders | Real target customers |
| Scope | One risky mechanism | Selected workflow or form | Smallest complete value test |
| Production readiness | Usually no | Usually no | Safe and reliable enough for bounded real use |
| Evidence | Mechanism works within defined conditions | People understand and use proposed interaction | Commitment, activation, outcome, repeat behavior, economics |
| Typical output | Test result and limits | Sketch, mock-up, model, or simulation | Live service, pilot, or product |
| Main misuse | Treating feasibility as demand | Treating preference as demand | Building too much before defining the hypothesis |
What a proof of concept tests
A POC isolates a feasibility risk that could invalidate the plan.
Examples:
- Can the system parse the three file formats with an agreed accuracy definition?
- Can a material withstand a defined load and environment?
- Can an integration return the required data within the permitted access model?
- Can a manual operating procedure meet a safety or quality condition?
A POC needs conditions and acceptance criteria:
Under [test conditions], the mechanism will [observable performance] while remaining within [quality, safety, cost, or resource boundary].
Record data, assumptions, environment, exclusions, and failure. “It worked once” is not a complete feasibility conclusion.
What a prototype tests
A prototype makes an idea concrete enough to inspect.
Examples:
- A paper onboarding sequence.
- A clickable dashboard.
- A physical form model.
- A role-played service interaction.
- A coded interface using synthetic data.
Set participants a real task and observe behavior. Ask what they expected, where they hesitated, and what information they needed. Avoid presenting a simulated result as a functioning capability.
The MVP vs prototype comparison goes deeper on interaction evidence and live value evidence.
What an MVP tests
An MVP tests a customer or business hypothesis through a real value exchange. It can be manual.
Examples:
- A paid concierge service.
- A bounded B2B pilot.
- A manually operated marketplace match.
- A single-feature product.
- A live workshop that produces a completed artifact.
Eric Ries's MVP definition emphasizes validated customer learning with the least effort. The MVP examples hub shows ten formats and their evidence.
Choose the artifact from the uncertainty
| If the decisive question is… | Start with… |
|---|---|
| Can the underlying mechanism work? | POC |
| Can users understand and complete the proposed interaction? | Prototype |
| Will a buyer commit to the outcome? | Paid or commitment-based MVP |
| Can the team deliver the outcome manually? | Concierge MVP |
| Can the mechanism work and the experience make sense? | POC and prototype in parallel |
| Will anyone care before automation exists? | Manual MVP before the automation POC |
Choose the cheapest responsible artifact that can change the decision.
Example: document-analysis product
A founder wants to flag missing obligations in supplier contracts.
POC
Using a permitted, representative set of documents, test whether the proposed method can identify a narrowly defined obligation with a prewritten evaluation method. Record false positives, false negatives, document limits, review requirements, data controls, and cost.
Prototype
Show legal-operations users a synthetic review interface. Ask them to locate the source clause, assess the flag, correct it, and export an action. Observe comprehension and trust boundaries.
MVP
Run a bounded paid pilot in which qualified human review remains part of delivery. Measure valid intake, completed review, customer action, turnaround, review effort, repeat demand, and commercial commitment.
The POC does not prove legal adequacy or demand. The prototype does not prove the analysis works. The MVP does not prove the process can scale without human review.
Example: marketplace
The central risk may not be technical.
- Prototype: Test whether buyers understand supplier profiles and request flow.
- MVP: Manually recruit, qualify, match, and support a few real transactions.
- POC: Later, test a technically uncertain matching or identity mechanism if it becomes the constraint.
Building a matching algorithm first would answer a less important question than whether both sides complete a valuable exchange.
Plan a POC
Use this template:
- Mechanism and why it matters.
- Test environment and representative inputs.
- Operational definition of success and failure.
- Quality, safety, security, and compliance boundaries.
- Measurement method.
- Time, cost, and compute limit.
- Known exclusions.
- Next decision if the result passes, fails, or is inconclusive.
For scientific, medical, legal, safety-critical, financial, or regulated claims, use qualified specialists and applicable standards. A startup POC is not professional certification.
Plan a prototype test
- User and context.
- Task the participant must complete.
- Fidelity required for the question.
- Elements that are simulated.
- Observation and note method.
- Comprehension or task criterion.
- Consent, privacy, and accessibility needs.
- Revision decision.
Do not ask only “Would you use this?” Have participants do the proposed task.
Plan an MVP test
- Customer and triggering problem.
- Value hypothesis.
- Customer input and completed result.
- Price or meaningful commitment.
- Delivery method and manual steps.
- Activation and repeat-use definition.
- Direct cost and founder labor.
- Acquisition source.
- Legal, safety, privacy, and quality guardrails.
- Continue, revise, pivot, or stop rule.
The customer validation guide can help distinguish opinion, commitment, and repeat behavior.
Common mistakes
Forcing a linear POC → prototype → MVP sequence
The uncertainty determines order. Do not build an unnecessary artifact just to complete a framework.
Letting the POC expand into the product
Exploratory code or materials may not meet production security, quality, maintainability, accessibility, or compliance requirements.
Measuring prototype satisfaction
Preference is weak. Observe task behavior and misunderstanding.
Calling a landing-page signup an MVP result
A page may test messaging or demand. It does not prove delivery, value, retention, or economics.
Exposing customers to unresolved feasibility risk
If failure could harm people, data, money, property, or legal rights, do not use a live MVP to discover basic safety.
Hiding simulation or human work
Disclose what is manual, mocked, unavailable, or experimental. Honest boundaries improve evidence and trust.
A POC proves only bounded feasibility. A prototype clarifies only the proposed experience. An MVP tests only the customer and business hypotheses exposed by its design. Name the uncertainty first, then choose the artifact that can answer it responsibly.
Martin Bell
Founder of 100 Tasks. Martin Bell has launched or supported 120+ startups and turned Rocket Internet venture-building discipline into a step-by-step system used by 25,000+ founders and startups.
