Prototype vs MVP vs proof of concept

Start with the decision, not the artifact name

Ask what uncertainty blocks the next responsible decision. If the team cannot agree on the user flow, it may need a prototype. If the product depends on an uncertain API, algorithm or hardware interaction, it may need a proof of concept. If the problem, path and operating boundary are sufficiently understood and the team needs evidence from real use, it may need an MVP. The artifact is selected by the question, not by which label sounds more advanced.

Write a one-sentence decision before choosing the format. Name who will use or inspect the artifact, where it will run, which data it may touch and what result would change the plan. Also state what the result cannot demonstrate. This prevents a stakeholder demo from becoming an accidental production commitment and stops a narrow technical success from being presented as validation of an entire business.

Use a prototype to learn about experience and understanding

A prototype can range from a sketch to a realistic interactive flow. Its job is to make an idea inspectable, support conversation and test how people understand or navigate a proposed experience. Fidelity should match the question. A rough artifact may be better for comparing information structure, while a more realistic interaction may be needed to observe a complex task. The team should expect to revise or discard it.

Protect prototype boundaries. Label it clearly, control access where confusion or sensitive context is possible, and avoid live credentials or production data. Prototype code may omit security, performance, recovery and maintainability work that a released service needs. Official GOV.UK guidance explicitly separates prototype kits from live services. Reusing prototype code is a new engineering decision that requires review, not an automatic shortcut.

Use a proof of concept to isolate technical feasibility

A proof of concept tests a narrow technical claim such as whether a representative integration can exchange required data, whether a computation can meet a defined constraint or whether an architecture can survive one important failure. Define the input, environment, success condition and known exclusions. Keep the claim small enough that a successful result has a clear meaning and a failed result can still inform the next decision.

A proof of concept does not establish that users want the product, that the complete workflow is usable or that the implementation is safe to operate. It may use synthetic data, temporary infrastructure or simplified permissions. Record those differences. If code is carried forward, inspect dependencies, secrets, data handling, failure behaviour, licensing, performance and ownership as if it were newly introduced. Technical feasibility is one evidence layer, not release approval.

Use an MVP for a complete, bounded real-world path

An MVP should preserve one meaningful end-to-end outcome for the intended user. It may have few features, but the chosen path must be coherent enough to create interpretable evidence. Define who may access it, what support exists, what is measured and which decision the evidence will inform. Avoid reducing scope until the product becomes a collection of screens that cannot complete the user’s task.

Because an MVP is released rather than merely demonstrated, its boundary can include authentication, authorisation, privacy, accessibility, error handling, monitoring and recovery where the context requires them. Minimum does not mean exempt from consequential safeguards. A successful deployment proves delivery to an environment at a timestamp. It does not by itself prove regular use, satisfaction, revenue or a durable market.

Sequence artifacts only when each one removes uncertainty

A team does not need to build all three artifacts in a fixed order. It can move from a paper prototype to an MVP when technical feasibility is familiar, or run a proof of concept before any detailed interface when one dependency could invalidate the idea. It can also stop after evidence shows the problem is weak or the operating burden is unjustified. Skipping unnecessary artifacts is disciplined when the decision record explains why.

At every transition, write what was learned, which assumptions remain, what code or data may be reused and who approves the next exposure level. IVRYN publishes a methodology that separates implementation, public delivery and external outcomes. Apply the same separation here. A prototype, proof of concept and MVP are useful when each has a bounded claim and a named decision, not when the labels are used as a ladder of implied success.

Decision criteria

Use the same questions for every option before choosing.