MVP vs. Prototype vs. Proof of Concept: What to Build First

Each one tests a different risk. This table compares them side by side.

A proof of concept, or PoC, checks whether something is technically possible. It is usually a small piece of code that solves one hard problem and ignores everything else: no design, no accounts, no polish.

For example, a startup that wants to extract totals from photos of handwritten receipts should first test whether an AI model can read them accurately enough. If it cannot, no amount of design will save the product.

Most products do not need a PoC. If your idea is built from proven parts, such as accounts, payments, forms and dashboards, the technical risk is low and a PoC only delays the real question.

The code from a PoC is usually thrown away. It was written to answer one question quickly, not to carry a product.

A prototype shows how the product will work before anyone writes production code. It can be a set of sketches or a clickable, realistic interface that behaves almost like the real thing.

Nielsen Norman Group's guide to low- and high-fidelity prototypes explains the trade-off well. Low-fidelity sketches are faster and invite honest criticism; high-fidelity prototypes show realistic behaviour, which matters when you test specific flows.

A prototype is also the best tool for aligning people. AutoIntel, a B2B tool for the German used-car market, started as an interactive prototype on sample listings. The client walked its team through it and agreed on which fields and filters matter before the data pipeline was scoped.

An MVP, or minimum viable product, is the smallest version of your product that real users can use for real. It has working accounts, real data and, where it matters, real payments.

The goal is learning, not launching for its own sake. In the Lean Startup's words, you build an MVP "to begin the process of learning as quickly as possible".

An MVP can measure what a prototype cannot: whether people come back, and whether they pay. CarPixly, an AI photo studio for car listings, lets anyone sign up and explore the studio for free, and payment starts at the moment of value, the render. A model like that shows clearly how many visitors turn into paying users.

Most MVPs take 6–14 weeks to build, depending on complexity. Our guides on how long an MVP takes and what a SaaS MVP costs give the ranges by tier.

Start with the riskiest unknown. Ask these questions in order:

• Is there a real chance it cannot be built? For example, it depends on an AI model, a hardware sensor or an API you have not tested. Build a proof of concept.
• Is it unclear whether people understand the solution or want it? Build a prototype and test it with users.
• Do people understand and want it, and the open question is whether they will use it or pay? Build an MVP.

Most startups land on the second question. The technology is usually proven; what is unproven is whether the product makes sense to the people it is for.

Not sure which risk is the biggest in your idea? Send us a short brief and we will tell you which first step we would take, and why.

A prototype is only useful if real people try it. The good news is that you need fewer testers than most founders think.

Jakob Nielsen's research found that testing with 5 users uncovers most usability problems in a design. His advice is to run several small rounds instead of one large study.

A simple test round looks like this:

• Give each person a realistic task, such as "book a service for next Tuesday".
• Watch what they do without helping or explaining.
• Note where they hesitate, misread or give up.
• Fix the worst problems, then test the next version with new people.

Ask about their current behaviour too: how they solve the problem today and what it costs them. That tells you more about demand than asking whether they "would use" your product.

A prototype made from sketches is a learning tool and gets redrawn later. A high-fidelity prototype designed in real components is different: its flows, screens and design system become the starting point of the MVP.

That is why we design in reusable components from the first screen. When the prototype has been tested and approved, development starts on the same components instead of reinterpreting a picture.

A proof of concept works the other way. Its code answers one question and is usually rewritten properly inside the MVP, because it was never meant to carry real users.

Each step should end with a clear answer, not a feeling. Write down what "success" means before you start, so the result cannot be argued into whatever you hoped for.

• A proof of concept succeeds when the hard part works on realistic data, at the accuracy or speed the product needs. "It works on three test files" is not enough if users will send thousands.
• A prototype succeeds when most test users complete the main task without help, and describe the problem it solves in their own words.
• An MVP succeeds when real users come back without being reminded, or pay, at a rate that makes the next investment worth it.

If a step fails, that is useful too. A failed proof of concept saves you an expensive build. A confusing prototype tells you to change the flow while changes are still cheap.

Set a time limit for each step as well. A prototype that is still being polished after months has stopped being a test and turned into a product nobody can use yet.

Sometimes, yes. If you have already tested the idea, for example through a manual version of the service, you may know enough to go straight to an MVP.

For example, a founder who has been matching clients with tutors by hand for months, using spreadsheets and messages, already knows the flows and the questions people ask. A prototype would mostly confirm what they already know.

Skipping makes sense when three things are true: the technology is proven, you have watched real people go through the process, and you know which part of the process you want the software to handle first. If any of these is missing, a prototype is still the cheaper way to find out.

The same mistakes come up again and again:

• Calling a prototype an MVP. Clicks on a prototype show understanding, not usage or payment. Do not mistake one for the other.
• Polishing a proof of concept into a product. Code written to answer one question becomes a fragile base for everything built on it.
• Skipping the prototype. Building an MVP before testing the flows means paying developers to discover design problems.
• Building too much into the MVP. Every extra feature delays the moment you learn whether the core works.
• Testing with friends. People who like you will praise the idea. Test with people who have the problem and no reason to be kind.

Ready to choose your first step? Tell us about your idea and we will help you decide between a proof of concept, a prototype and an MVP.