Prototype vs. Proof of Concept vs. MVP: What Should You Build First?

You have a software idea, a budget conversation on the calendar, and three people using three different words for the thing you should build next.

One calls it a prototype. Another calls it a proof of concept. Someone says “MVP” because MVP sounds like something that could be shown to a customer, an investor, or at least a conference room full of hopeful faces.

Here is the useful answer: build a prototype to test the experience, a proof of concept to test technical feasibility, and an MVP to test a narrow but real value exchange with real users. Choose the one that produces the evidence needed for your next decision. The label is not the strategy.

If you choose by prestige, you can spend MVP money to answer a prototype question—or mistake a convincing demo for a product that is ready to operate.

These three artifacts do three different jobs

The cleanest way to separate them is by the uncertainty they are supposed to reduce.

Artifact	The question it should answer	Typical audience	What it does not prove
Prototype	“How should this experience work?”	Prospective users, operators, stakeholders	That the underlying technology or operation is production-ready
Proof of concept	“Can this difficult technical idea work well enough to continue?”	Technical team and decision-makers	That people want the product or can use it comfortably
MVP	“Will real users complete and value this narrow journey?”	Real early users and the operating team	Product-market fit, scale, or long-term commercial success

A prototype may be a sketch, a clickable flow, or a realistic simulation. It exists to make an idea testable before the expensive parts harden around it.

A proof of concept is narrower and usually less charming. It attacks one technical unknown: Can the model classify the documents accurately enough for the intended review process? Can the old system exchange the required data? Can the unusual calculation finish inside an acceptable operating boundary? It is not there to win a beauty contest.

An MVP is a real product, just a deliberately narrow one. It needs enough reliability, security, support, and operational ownership for its chosen users and use case. “Minimum” removes everything that does not serve the first learning loop. It does not remove the parts that keep the loop honest.

Start with the decision that is stuck

Teams often start with a noun: “We need an MVP.” A better start is a decision: “We need to know whether dispatchers can understand this workflow before we commit to the integration,” or “We need to know whether the proposed AI step performs well enough on representative material to justify building the product around it.”

That distinction matters because discovery is supposed to clarify the problem, users, constraints, and measures of success before a team commits to a solution. The GOV.UK Service Manual’s discovery guidance explicitly treats stopping as a valid result when the evidence says the service is not worth pursuing. That is not failure. That is a relatively inexpensive answer arriving on time.

The wrong artifact produces activity without resolving the decision. A beautiful clickable prototype cannot prove that a difficult integration is feasible. A technical spike cannot tell you whether a customer understands the checkout. A live MVP cannot rescue a product whose problem was never clear.

Before you talk screens, features, or technology, write one sentence:

We cannot responsibly decide whether to ______ until we learn whether ______.

The second blank is the job of the artifact.

Use the Next Evidence Test

The Next Evidence Test is a five-part filter for choosing what to build now. It keeps the conversation attached to a business decision instead of a fashionable deliverable.

1. Name the blocked decision

What will become possible when the work is complete?

Perhaps you will decide whether to fund product development, keep or discard an interface direction, approve a risky integration, invite a small user group, or stop the idea entirely. If the team cannot name the decision, it is not ready to choose the artifact.

A useful decision has more than a happy path. “Continue only if the evidence clears the agreed bar” is a decision. “Build something so we can see it” is a calendar event wearing a strategy hat.

2. Find the riskiest unknown

Ask which unknown could make the rest of the plan irrelevant.

• If people may not understand the journey, lean toward a prototype.
• If one technical dependency may not work, lean toward a proof of concept.
• If the experience and feasibility are credible but real use is still unproven, lean toward an MVP.

This is why the sequence is not automatically prototype, then proof of concept, then MVP. The GOV.UK alpha guidance recommends doing the minimum needed to test the riskiest assumptions and warns that early code may be thrown away. Sometimes the biggest risk is technical, so the proof comes first. Sometimes the technology is ordinary and the experience is the mystery. Sometimes enough is already known to move into a tightly scoped MVP.

3. Choose the evidence audience

Who must observe the artifact for the result to count?

A product team can inspect a proof of concept. Prospective users should test a prototype intended to answer a usability question. Real early users need to complete the actual value-producing journey for an MVP to tell you anything useful about real operation.

Be precise about the audience. A stakeholder who already knows the proposed workflow can glide through a prototype that leaves a new customer completely lost. An engineer can celebrate a successful API call while the operations team discovers the resulting process is impossible to run. The right artifact shown to the wrong audience still gives you weak evidence.

4. Set the minimum honest realism

How real must the artifact be for the evidence to mean what you think it means?

Prototype fidelity should match the question. The GOV.UK prototyping guidance ranges from paper sketches to realistic code prototypes and cautions against treating prototype code as production code. If you are testing page order, a polished backend may be waste. If you are testing how someone handles a complicated interaction on a phone, boxes on a whiteboard may not be enough.

A proof of concept needs realism around the technical risk—not everywhere else. Use representative inputs and constraints where they affect the result. Keep the surrounding product as small as possible.

An MVP crosses a different line because people depend on it for a real task. It may serve one narrow journey, but that journey needs truthful data handling, a usable fallback, an owner, and a way to learn what happened. A painted door can test interest. It cannot quietly collect sensitive information or promise a service that does not exist.

5. Write the exit criteria before the build

What result leads to “continue,” “change direction,” or “stop”?

Define that before anyone becomes emotionally attached to the artifact. The criteria can be qualitative when a made-up number would create fake certainty. For example:

• Prototype: intended users can complete the core flow without being coached past the same misunderstanding.
• Proof of concept: the difficult capability works on representative cases within the required operating constraints, and the failure modes are visible enough to evaluate.
• MVP: a defined early-user group can complete the narrow value journey, while the team can support, observe, and improve it responsibly.

The purpose is not to manufacture a green light. It is to prevent every outcome from being translated into “just one more sprint.”

A prototype should be convincing enough to learn from—not to confuse with production

The dangerous prototype is the one that looks finished.

That sounds backward, but polish changes expectations. A realistic interface can help someone respond naturally. It can also make an internal audience assume the security, integrations, error handling, and support model are hiding just behind the screen.

The Atlassian product-development guide describes prototypes, proofs of concept, and MVPs as different ways to make a concept testable, with technical feasibility, usability, and value among the questions that can be validated. The practical lesson is simple: state what is real, what is simulated, and what the test cannot establish.

Put a label on the artifact. Protect access when confusion would cause harm. Keep production credentials and sensitive data out of work that does not need them. If code was written to make a test happen quickly, do not let a successful presentation silently promote it into the production foundation.

A proof of concept should attack one scary dependency

The best proof of concept is almost rude in its focus.

It does not need the full navigation, the account area, or a dashboard with twelve tasteful charts. It needs the smallest credible environment around the technical question that could kill the idea.

Imagine a proposed application that depends on reading a messy set of business documents. The proof of concept is not “build the document platform.” It might be “evaluate whether the extraction approach finds the required fields across representative document types, exposes uncertainty, and fails in ways a reviewer can recognize.”

That result may support an MVP. It may point to a different design. It may show that the promise needs to shrink. All three outcomes are useful.

What you should resist is the wandering proof of concept: every week adds another feature because the artifact is becoming fun to demo. Once it starts accumulating product expectations without product controls, you have created the most expensive kind of ambiguity.

An MVP should complete one real loop

An MVP is not a prototype with a database attached. It is the smallest real product that lets a specific user reach a specific valuable outcome—and lets the business learn from that use.

That requires a complete loop. The user can begin the task, make the necessary decisions, reach an outcome, and get help when the narrow system cannot continue. The team can observe useful evidence, correct problems, and decide what comes next.

This is where the One-Hypothesis Rule for MVP feature prioritization takes over. Once you have chosen an MVP, that framework helps decide which features are essential to the learning loop and which are simply impatient ideas from the future.

If the product is headed into a serious implementation conversation, the Build-Ready Brief helps make the users, workflow, boundaries, data, integrations, ownership, and acceptance evidence visible without pretending discovery is finished.

Sometimes the right answer is a sequence

These artifacts are not rival teams. A deliberate sequence can remove different risks without asking one build to prove everything.

Consider a hypothetical scheduling product with an unusual optimization engine:

1. A proof of concept tests whether the engine can produce acceptable options under representative constraints.
2. A prototype tests whether a dispatcher understands, edits, and trusts those options.
3. An MVP lets one defined user group run a narrow scheduling journey with real operating support and feedback.

Each step earns the next one. Each has its own audience and exit criteria. Nothing is called “phase one of the inevitable full build.”

You can also skip a step. If the technical approach is ordinary and the workflow is already well understood, manufacturing a proof of concept may be ceremony. If the product depends on one uncertain capability, jumping straight to a live MVP may force you to build a house around a science experiment.

Buy the next piece of evidence

The prototype-versus-proof-of-concept-versus-MVP decision is not really about terminology. It is about refusing to buy more software than the next responsible decision requires.

Name the decision. Find the riskiest unknown. Choose the people whose response counts. Build only the realism the test needs. Decide in advance what happens when the evidence arrives.

Then the artifact has done its job—even if the answer is “not yet,” “not this way,” or “not at all.”

If you know the business problem but are unsure whether the next move should be a prototype, technical proof, or real first release, MVP development is the natural place to start. I can help turn the uncertainty into a focused learning plan, build the right-sized artifact, and make sure the next investment follows evidence instead of momentum.