MVP vs Prototype vs Proof of Concept: Which One Do You Actually Need?

MVP, prototype and proof of concept are often used as interchangeable labels for “something smaller than the final product”.

They are not the same thing.

Each is useful for a different uncertainty:

• Prototype: Can users understand and use this solution idea?
• Proof of concept: Can the difficult technical idea work?
• MVP: Will a sufficiently viable version create value when real users use it in a live context?

Choosing the wrong one wastes money because the team builds more evidence than it needs, or worse, builds the wrong kind of evidence entirely.

Start with the uncertainty

Before choosing an artefact, ask:

What do we not know that could cause us to stop or materially change the investment?

That uncertainty usually falls into one of four categories.

Desirability

Do users want the outcome strongly enough?

Usability

Can they understand and complete the core task?

Feasibility

Can the technology, integration or algorithm work under realistic constraints?

Viability

Can the product work commercially and operationally in the real world?

Different tools answer different questions.

What a prototype is for

A prototype represents a proposed experience without requiring the full production system behind it.

It may be:

• a paper sketch;
• clickable Figma screens;
• an interactive web prototype;
• a partially coded flow;
• a simulated service journey.

Use a prototype when the main questions are about:

• user understanding;
• navigation;
• interaction;
• information hierarchy;
• workflow concept;
• customer response to a proposition.

GOV.UK's Service Manual recommends prototyping before committing to production because prototypes make it faster and lower-risk to explore and test alternative designs.

Example

A bank wants to redesign a business-account application.

Before integrating identity verification, core banking and document systems, the team can prototype the end-to-end application journey and test whether business owners:

• understand the requirements;
• know which documents are needed;
• can complete the steps;
• understand the status and next action.

The riskiest question is interaction design, not whether the bank's API gateway can technically send JSON.

What a proof of concept is for

A proof of concept tests technical feasibility.

It is usually narrow and may have little or no polished user experience.

Use a POC when the main uncertainty is:

• can two systems integrate?
• can a model achieve acceptable accuracy?
• can a device capture the required signal?
• can the architecture handle a performance constraint?
• can data be extracted and transformed reliably?
• can an AI agent use the required tool safely?

Example

A logistics company wants computer vision to identify damaged parcels.

Before building a user application, the team can test whether available images and models can detect relevant damage at acceptable precision and recall.

If the technical capability is inadequate, a beautiful prototype would have answered the wrong question.

What an MVP is for

An MVP is a live product or service designed to test whether real use creates enough value to justify further investment.

It should be narrow, but the core journey must be viable for the users and context in which it is released.

Use an MVP when you need evidence about:

• activation;
• real behaviour;
• willingness to pay;
• repeat use;
• retention;
• transaction economics;
• operational support burden;
• live workflow fit.

Example

A retailer wants a B2B wholesale ordering platform.

A prototype can test whether store owners understand the ordering flow.

A POC can test whether inventory can synchronise from the ERP.

An MVP can test whether a controlled group of stores actually place and repeat orders through the new channel.

Three different questions. Three different artefacts.

They can appear in sequence

A sensible product-discovery path can look like:

Problem research → Prototype → Proof of concept → MVP → Scale

But not every product requires every stage.

If technical feasibility is already well understood, skip the POC.

If the product is an internal workflow with known users and known value, the team may move from process discovery directly into a production pilot.

The stages should reduce uncertainty, not satisfy a methodology checklist.

Compare them directly

When you need a prototype

Choose a prototype first when statements like these are true:

• We know the problem but not the best interaction.
• Users currently struggle with a complex process.
• Stakeholders disagree about the proposed journey.
• We need to test several design approaches quickly.
• Building the backend would be expensive before usability is understood.

The goal is not visual approval.

The goal is evidence from people attempting the task.

When you need a POC

Choose a proof of concept first when:

• the core technology has not been proven in your environment;
• an integration is the dominant risk;
• performance or latency may make the idea unworkable;
• an AI capability needs benchmark evaluation;
• data quality may prevent the proposed solution;
• a hardware/software interaction is uncertain.

Define a technical acceptance criterion before building it.

For example:

The document extraction approach must correctly identify six required fields in at least the agreed percentage of a representative validation set while keeping average processing time below the required threshold.

A POC should end with a decision, not merely a demo.

When you need an MVP

Choose an MVP when the uncertainty cannot be resolved without real behaviour.

Examples:

• Will customers pay?
• Will they return?
• Will employees adopt the workflow when management is not watching?
• Can operations support the service economically?
• Will suppliers participate consistently?
• Does the marketplace have enough liquidity?

These are live-system questions.

Do not put production obligations into the wrong artefact

A prototype should not quietly become the production application because stakeholders liked it.

A POC should not be deployed to customers simply because the integration worked once.

A coded experiment may lack:

• security hardening;
• failure handling;
• accessibility;
• observability;
• maintainable architecture;
• support processes;
• data controls;
• automated testing.

Moving from evidence artefact to production requires an explicit engineering decision.

Do not overbuild the MVP either

Teams sometimes spend months turning an MVP into a miniature enterprise platform before a single real user has touched it.

Ask of each feature:

• Does it enable the core outcome?
• Does it protect the user or business from a material risk?
• Does it generate evidence required for the next decision?

If not, defer it.

Back-office work can sometimes remain manual during early validation.

For example, an MVP may use manual supplier verification before automating KYC or onboarding, provided the process is safe, lawful and operationally manageable.

A fourth option: concierge or service test

Sometimes you need none of the three.

If the assumption is whether customers value an outcome, manually deliver it first.

Examples:

• manually create a weekly analytics insight report before building the analytics product;
• manually match buyers and sellers before building a marketplace algorithm;
• provide a human research assistant before automating research with AI.

If nobody values the manually delivered outcome, automation has very little to rescue.

A decision tree

Ask these questions in order.

1. Do we understand the problem well enough?

If no, do discovery research.

2. Is the main uncertainty about the experience?

If yes, prototype.

3. Is the main uncertainty technical?

If yes, run a POC.

4. Is the main uncertainty real-world adoption or economics?

If yes, build an MVP or controlled production pilot.

5. Are the assumptions already well established?

If yes, you may simply need a properly scoped production release.

Not every build must be forced through experimental vocabulary.

Governance should match the artefact

Prototype gate

Decide whether the proposed experience is promising enough to pursue.

POC gate

Decide whether the technical approach meets defined acceptance criteria.

MVP gate

Decide whether behavioural and commercial evidence justify further investment.

At each gate, allow four outcomes:

• continue;
• adjust;
• repeat the test;
• stop.

If “stop” is not genuinely possible, the exercise is probably theatre.

Example: AI customer-support assistant

A team wants an AI support assistant.

Prototype

Test whether agents understand and trust a proposed interface that shows suggested responses and sources.

POC

Evaluate whether the model can answer representative support questions accurately from the knowledge base and cite the correct sources.

MVP

Deploy to a small support group, monitor acceptance, override rate, handling time, quality and customer outcomes.

Only after those results should the team decide whether to scale automation.

Example: mobile marketplace

Prototype

Test listing, search and checkout flow with buyers and sellers.

POC

Validate a difficult payments, logistics or identity-verification integration.

MVP

Launch in one constrained geography or category and test transaction liquidity, repeat behaviour and unit economics.

This sequence turns a large vision into a series of evidence-backed decisions.

Questions leadership should ask

1. What is the riskiest assumption right now?
2. Which artefact can test it most cheaply and credibly?
3. What evidence will we collect?
4. What is the acceptance threshold?
5. What production obligations apply to this artefact?
6. What are we deliberately not building?
7. What decision will follow the test?

Those questions are more valuable than arguing about whether a clickable prototype “counts as an MVP”.

Further reading

• GOV.UK Service Manual, Making prototypes: https://www.gov.uk/service-manual/design/making-prototypes
• GOV.UK Service Manual, How the alpha phase works: https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works
• GOV.UK Service Manual, How the beta phase works: https://www.gov.uk/service-manual/agile-delivery/how-the-beta-phase-works

Abrasim's Product Opportunity Sprint selects the validation method from the uncertainty. Sometimes that means a prototype, sometimes a technical POC, sometimes an MVP, and occasionally the most intelligent product decision is not to build anything yet.