POC, prototype or MVP: which one does your idea need?

Three names, three different questions

A proof of concept, a prototype and an MVP are all early versions of something, which is why the names get swapped so freely. What separates them is the question each one is built to answer.

• POC

  The question

  Can this work at all?

  What you get

  A narrow test of the riskiest technical or business assumption, often with little or no interface.

  Who it is for

  The people deciding whether the idea is worth pursuing.

• Prototype

  The question

  Is this the right experience?

  What you get

  An interactive version people can click through and react to. It may not be connected to real data.

  Who it is for

  Users and stakeholders who need to see something before they can give useful feedback.

• MVP

  The question

  Will people use it?

  What you get

  A lean, working product built around one core journey and ready for real users.

  Who it is for

  The first real users, and whoever decides on the next investment.

When a proof of concept is the right start

Start with a proof of concept when there is real doubt about whether the idea can work. Perhaps it depends on data you have not worked with before, an integration nobody has attempted, or an AI capability that may not be accurate enough for the job. A proof of concept isolates that one doubt and tests it.

It is narrow on purpose. If the answer is no, you have found out before committing to a build. If the answer is yes, you know the foundations hold.

A proof of concept is not a small version of the product. It is scoped for validation, not for production, and treating it as the first release tends to mean rebuilding it later.

When a prototype is the right start

Start with a prototype when feasibility is not in question but the shape of the product is. People find it hard to react to a requirements document and easy to react to a screen. A prototype puts the journey in front of users and stakeholders so they can say what is missing, what is confusing and what they would never use.

It also helps a group agree. Differences that stay hidden in a written brief tend to surface as soon as everyone is looking at the same thing.

When to go straight to an MVP

Go to an MVP when you already know the idea is feasible and you have a clear view of the core journey. An MVP is a real product kept lean on purpose: one core use case, built well enough for real users to rely on, with everything else left out for now.

The discipline is in the leaving out. Agree up front what the first version will include, what it will not, and which assumption it exists to test.

What comes after the MVP

An MVP is not the finish line. The usual next step is a pilot: a controlled rollout to a limited group, where you learn how the product copes with real work and real exceptions. Full rollout follows once the pilot has shown what needs to change, and it brings work of its own, including infrastructure, security, support and integration with the systems around it.

Each stage should end with a decision to refine, move forward or stop. Stopping is a legitimate result, and far cheaper early than late.

How to choose between them

The quickest way to choose is to name your biggest uncertainty.

• If you cannot yet say whether the idea is technically or commercially possible, start with a proof of concept.
• If it is possible but you are unsure what people need to see and do, start with a prototype.
• If both are clear and you need evidence from real use, build an MVP.
• If you cannot tell which doubt is the biggest, working that out is the first job.

You do not have to pass through all three. Many ideas need only one early step before an MVP, and some need none.