VISUOSOFTS · WEB DEVELOPMENT
PoC, prototype, MVP — three terms used interchangeably and wrongly, costing businesses real money. Understanding the differences (and when to use each) is the key to validating ideas efficiently: the right validation at the right stage. This guide defines them clearly.
Written for UK founders and product owners: the validation vocabulary, correctly.
POC — PROVE IT CAN WORK
The Proof of Concept answers: can it be built? The PoC is the technical validation — the risky assumption tested in code, the feasibility demonstrated, the spike solution. It is internal, rough, and disposable: the PoC that proves the concept has done its job and is typically discarded, not evolved.
Use the PoC when: the technical risk is the highest (the unproven integration, the novel algorithm — the can-we), the build-vs-buy needs the evidence, or the team needs the confidence. The PoC is cheap insurance against the expensive discovery — the "it can't be done" found in week two, not month six. Timebox it ruthlessly (the 1–2 weeks — the focused); the PoC that grows is the product in disguise. For the testing discipline that follows validation, see mobile app testing.
PROTOTYPE — SHOW HOW IT FEELS
The prototype answers: how will it feel? The prototype is the experience validation — the clickable mockup, the interactive demo, the look-and-feel made tangible. It is for the stakeholders and users: the investors shown, the users tested, the team aligned — the vision made visible before the building begins.
Use the prototype when: the UX is the risk (the complex flows — the usable?), the stakeholders need convincing (the shown beats the described), or the user testing must happen pre-build (the validated). The fidelity matches the question: the paper sketches for the flows, the clickable Figma for the feel, the coded for the interactions. The prototype's value is the feedback it generates — the tested, the iterated, the learned-before-building.
MVP — TEST IF IT IS WANTED
The MVP (Minimum Viable Product) answers: will they use it (and pay)? The MVP is the market validation — the smallest releasable product that delivers the core value to real users, in production, with real consequences. It is not the rough demo — it is the real product, minimally scoped: the usable, the reliable, the lovable-enough.
Use the MVP when: the market risk is the highest (the will-they — the validated with revenue or retention, not opinions), the learning must be real (the production data — the behavioural, not the stated), and the business needs the proof (the traction — the funded, the scaled). The MVP's discipline: the minimum (the smallest that tests the hypothesis — the scoped ruthlessly), the viable (the actually usable — the minimum is not the shoddy), the measured (the hypothesis, the metric — the learned).
SIDE BY SIDE — THE DIFFERENCES
The audience: the PoC (the technical team — the internal), the prototype (the stakeholders and users — the shown), the MVP (the market — the real users, the paying). The question: the PoC (can it be built?), the prototype (how will it feel?), the MVP (will they want it?). The output: the PoC (the technical answer — the disposable), the prototype (the experience — the iterated), the MVP (the product — the evolved).
The cost curve: the PoC cheapest (the days to weeks), the prototype moderate (the design effort), the MVP significant (the real product — the investment). The risk addressed: the PoC (the technical), the prototype (the usability), the MVP (the market). The confusion costs: the MVP built to answer the technical question (the overbuilt PoC), the prototype shipped as the product (the underbuilt MVP) — the wrong tool for the question is the money wasted.
THE SEQUENCE — THE VALIDATION JOURNEY
The typical journey: the PoC (the technical risks retired — the can-we), the prototype (the experience validated — the usable?), the MVP (the market tested — the wanted?), then the full product (the scaled — the proven). Each stage gates the next: the failed PoC saves the prototype's cost; the failed prototype saves the MVP's; the failed MVP — the cheapest failure that teaches the market truth.
The sequence adapts: the low-technical-risk skips the PoC (the standard stack — the known); the simple UX lightens the prototype (the straightforward — the quick); but the MVP is rarely skipped honestly — the market validation is the validation that matters most. The sequence's discipline: the each stage's question answered before the next stage's money is spent. Our application development work follows this validation discipline — the right proof at the right stage.
MISTAKES TO AVOID — THE VALIDATION FAILURES
The mistakes: the terms confused (the "MVP" that is the prototype — the mis-scoped), the stages skipped (the full product built on the unvalidated — the expensive lesson), the PoC evolved (the disposable grown into the product — the technical debt), the MVP bloated (the "minimum" with everything — the un-minimal), and the learning skipped (the built but not measured — the validation theatre).
Avoid through the discipline: the question defined per stage (the answered explicitly), the exit criteria (the what-proves-it — the decided upfront), and the honesty (the failed validation celebrated — the money saved, not the ego bruised). Talk to us about the validation — the PoC, the prototype, the MVP — done correctly, in sequence.
The validation mindset, installed: the question before the building, the evidence before the scaling, the learning before the investing — the discipline that never fails.
POC VS PROTOTYPE VS MVP — FAQs
Can the PoC become the MVP?
No — the PoC is the disposable technical spike; evolving it into the product builds on the throwaway foundations. The PoC's learnings inform the build; its code should not become the build.
How much should an MVP cost?
The minimum that tests the hypothesis with real users — the scope decides, not the formula. The well-scoped MVP is the fraction of the full product; the bloated "MVP" is the full product renamed. Ruthless scoping is the cost control.
Do we need all three stages?
Not always — the low-risk stages can be lightened or skipped. But the question each answers must be answered somehow: the technical confidence, the usability confidence, the market confidence — the skipped stage is the unanswered question.
What's the difference between a prototype and a mockup?
The interactivity: the mockup shows (the static — the look), the prototype behaves (the clickable — the feel). The mockup answers "how will it look?"; the prototype "how will it work?". The question decides the fidelity.
How long should each stage take?
The PoC 1–2 weeks (the timeboxed), the prototype 2–4 weeks (the designed and tested), the MVP 2–4 months (the built and launched) — the typical. The scope and complexity move these; the timeboxing discipline keeps them honest.
