MVP vs Prototype vs Proof of Concept

Ask five founders what an MVP is and you will get five answers. Ask them how an MVP differs from a prototype or a proof of concept and the answers get even more creative. The confusion is expensive: teams build a full product when a clickable mockup would have answered their question, or they show investors a slick prototype and call it traction.

The fix is simple. Each of these three artifacts exists to answer a different question. Once you know which question you are stuck on, you know what to build.

The short answer

• Proof of concept (PoC): can this be built at all?
• Prototype: will people understand and want to use it?
• MVP: will real customers adopt it, keep using it and pay for it?

Only the last one is real, shippable software used by real people. That is also why only the MVP can tell you whether you have a business.

What a proof of concept is

A proof of concept tests a technical risk. It is the right tool when your idea depends on something you are not sure is possible, such as getting acceptable accuracy from a model on your data, integrating with a legacy banking API, or processing video in real time on a phone.

A PoC is usually rough on purpose. It might be a script, a notebook or a single endpoint, and the code is often thrown away afterwards. Its audience is your own team, a technical co-founder or an investor doing diligence. Nobody outside the company needs to see it.

Build one when: there is a genuine "can we even do this?" question. Skip it when: the technology is well understood (a CRUD web app, a booking flow, a marketplace). Writing a PoC for a login form is just a slower MVP.

What a prototype is

A prototype tests the experience. It is usually built in a design tool such as Figma and linked together so that people can tap through the key flows. There is no real backend behind it. Data is fake, and nothing is saved.

Prototypes are cheap, fast to change and brilliant at exposing confusion. Put one in front of five people from your target audience, ask them to complete a task, and watch where they hesitate. You will learn more in an afternoon than from a month of internal debate.

Build one when: the product has a non-obvious flow, you are choosing between two designs, or you need something to show in customer interviews before writing code. Skip it when: you already know the flow cold and the interface is conventional.

What an MVP is

The term "minimum viable product" was popularised by Eric Ries in The Lean Startup. The idea is to build the smallest version of the product that lets you learn from real customers with the least effort. Two words in that definition do a lot of work: viable and learn.

Viable means it genuinely works end to end for the one job you are promising. Users can sign up, do the thing, and get the result. Learn means you decide in advance which behaviour you will measure, such as sign-ups, repeat use or willingness to pay, so that the launch produces evidence and not just a feeling.

An MVP is not a buggy beta, and it is not "version one of everything". It is a deliberately narrow product. If you are unsure what to cut, our guide to prioritizing MVP features walks through a method, and how to build an MVP in 4 weeks shows what the build itself looks like.

Side by side

The effort figures are rules of thumb. They shift a lot with scope, team and how decisive the stakeholders are.

Which one do you need right now?

Work backwards from your biggest unanswered risk.

"I am not sure this is technically possible"

Start with a proof of concept. Timebox it, define what "good enough" means before you begin (for example, "answers 8 of 10 test questions correctly"), and stop as soon as you have your answer.

"I am not sure people will understand it"

Build a prototype and run five to eight short usability sessions. Watch what people do instead of asking what they think.

"I am not sure anyone will pay for it"

This is the question most founders are really facing, and it is the one only an MVP, or something very close to it, can answer. In its analysis of venture-backed companies that shut down since 2023, CB Insights found that 43% cited poor product-market fit among their reasons, and many listed several reasons. Running out of money is usually the end of the story, but missing the market is often how the story starts.

"I know the tech works, the flow is standard, and customers are asking for it"

Go straight to the MVP. Skipping the earlier steps is fine when the earlier risks are already low.

Common mistakes

• Calling a prototype an MVP. A polished mockup can win compliments, but compliments are not evidence of demand. Only real usage is.
• Over-building the proof of concept. If you are polishing a PoC, you are building a product without the benefits of one.
• Treating the MVP as a small version of everything. Choose one customer, one problem and one core flow. Everything else can wait.
• Launching without a success metric. Decide before launch what result would make you continue, change direction or stop.
• Doing all three in strict sequence out of habit. They are tools, not mandatory stages. Use the one that answers your current question.

The takeaway

Do not ask "should I build an MVP, a prototype or a PoC?" Ask "what is the riskiest thing I do not know yet?" Then build the cheapest thing that answers it. Early on that is often a prototype, and once the idea survives contact with users it is an MVP that proves people will actually pay for it.

If you are weighing up what to build first and what it should cost, our breakdown of MVP development cost in 2026 is a good next read.