The Short Answer
What is the difference between an MVP, a prototype and a proof of concept?
A proof of concept tests whether something can be built. A prototype tests what it should look like and how people would use it. An MVP tests whether real customers want it, by giving them the smallest working version. A pilot, which comes after, tests whether it works inside a real customer's operations.
The easiest way to keep them apart is to ask who the audience is. A proof of concept is for your own team. A prototype is for your team, designers and a handful of test users. An MVP is for strangers who have the problem you are solving. A pilot is for a few committed customers who have agreed to try it for real.
Four Terms, Four Questions
| Proof of concept | Prototype | MVP | Pilot | |
|---|---|---|---|---|
| Question it answers | Can it be built? | What should it be? | Do people want it? | Does it work in real operations? |
| Audience | Your team | Your team and test users | Real customers | A few committed customers |
| Working software? | Often partial | Usually not | Yes | Yes |
| Kept afterwards? | Usually thrown away | Usually thrown away | Built on | Built on |
| Typical output | A yes or no, with evidence | Clickable screens, user feedback | Usage and payment data | A rollout decision |
These are not stages every product must pass through. Plenty of products need no proof of concept, because nothing about them is technically new. What matters is matching the next thing you build to the biggest open question you have.
Proof of Concept
What is a proof of concept in software?
A proof of concept is a small, often throwaway experiment that shows a technical idea can work: an algorithm runs fast enough, two systems can be connected, or a model can reach the accuracy you need. It usually has no proper interface and is not shown to customers.
The European Commission's Technology Readiness Level scale, used across EU research funding, puts “experimental proof of concept” at level 3 of 9. A prototype demonstrated in an operational environment does not arrive until level 7. That gap is a useful reminder: proving something can work is a long way from having something people can use.
You need a proof of concept when the risk is technical, for example:
- An AI feature that only has value above a certain accuracy.
- An integration with a system whose API you have not seen working.
- A performance requirement, such as processing a large file in seconds.
- Hardware, sensors or a data source you have not tested.
If your product is a booking system, a marketplace or a dashboard, the technology is well proven and you can usually skip this step.
Prototype
What is a prototype?
A prototype is a model of the product, from paper sketches to clickable screens, used to test what it should look like and how people would use it before anyone writes production code. It is built to be changed or thrown away.
The UK government's Service Manual describes this phase, which it calls alpha, as building prototypes that are “just complex enough” to test ideas, “not production quality code”. It says alphas tend to last 6 to 8 weeks, and that teams should throw away any code at the end. It also says you should not start building the service during discovery, the research phase before alpha, which typically takes 4 to 8 weeks.
You do not need many people to test a prototype. Jakob Nielsen's widely cited Nielsen Norman Group analysis found that testing with five users uncovers about 85% of a design's usability problems. Several small rounds of five beat one large round.
A prototype tells you whether people understand the product and can use it. It cannot tell you whether they will pay for it or come back next week. People are polite about prototypes in a way they are not about products they have to use.
Minimum Viable Product
What is an MVP?
Eric Ries defined the minimum viable product in 2009 as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. In practice, it is the smallest real product that strangers can use without you explaining it.
The key word in Ries's definition is learning. An MVP is not a cheap version of the full product; it is an experiment that happens to be a product. It needs a hypothesis (“independent gyms will pay £49 a month to replace paper booking”) and a metric, decided before launch, that tells you whether the hypothesis was right.
An MVP does not always have to be software. Dropbox's founder Drew Houston famously tested demand with a demo video before the product was widely available; he told TechCrunch that 75,000 people joined the waiting list within 24 hours. But once the question is “will people use this every week” or “will they pay”, only working software answers it. Unlike a prototype, an MVP's code is usually kept and built on, which is why it needs to be built properly.
For what goes into one and what it costs, see the complete guide to MVP development and how to scope an MVP.
Pilot
What is the difference between an MVP and a pilot?
An MVP tests whether there is demand. A pilot assumes there is, and tests whether the product works inside a real customer's operations, with a small group, agreed success criteria and a date to decide whether to roll out.
Pilots are common in business-to-business sales, healthcare, finance and the public sector, where a buyer will not commit to a full rollout without seeing the product work in their own environment. GOV.UK's equivalent is private beta: the best idea from alpha is built “for real” and a limited number of people are invited to use it before it opens to everyone. Running a formal pilot before you know anyone wants the product adds months of process to a question an MVP could answer faster.
The Order Most Products Follow
Proof of concept
Prove the hard technical part works. Throw the code away.
Prototype
Test the design with around five users per round. Throw it away.
MVP
Ship the smallest real product and measure one metric decided in advance.
Pilot
Run it inside a few customers’ operations before a full rollout.
Skip any step whose question you can already answer. A founder with a clear design and a well-known technology can go straight to an MVP. A founder whose product depends on an unproven model should not go near an MVP until a proof of concept says it can work.
Which to Build Next
Answer four questions about where your idea is today.
Interactive tool
Which one should you build next?
Answer four questions. The result follows the definitions in this guide.
1.Is it still uncertain whether the core technology can work at all?
2.Do you know what the product should look like and how people would use it?
3.Has anyone outside your team used it, or paid for something like it?
4.Do you need to prove it works inside a customer’s real operations before a wider rollout?
Answer all four questions to see a recommendation.
Four Expensive Mix-Ups
- Treating a prototype as an MVP. Clickable screens that test well with five people do not prove demand. Positive feedback on a prototype is a reason to build an MVP, not a reason to raise money as if demand were proven.
- Shipping prototype code to customers. Prototype code is built to be thrown away. Putting it in front of paying customers means rebuilding later, usually under pressure. GOV.UK's advice to discard alpha code exists for this reason.
- Building an MVP when the risk is technical. If the product only works when a model reaches a certain accuracy, spending months on sign-up flows before testing that model is backwards.
- Running a pilot before proving demand. A pilot with a large customer feels like progress, but if the core idea has not been tested with the wider market you may be building one customer's custom software.
If you are ready for an MVP, the next questions are scope, time and money: how long an MVP takes, what a $15k MVP includes vs a $50k quote, and how Loomstrat builds MVPs on a fixed price.
Frequently Asked Questions
Is a prototype the same as an MVP?
No. A prototype tests what a product should look like and how people would use it, usually without production code. An MVP is a working product used by real customers to test whether they want it. Prototype code is normally thrown away; MVP code is built on.
What comes first, a proof of concept or a prototype?
A proof of concept, if there is technical risk, because there is no point designing a product that cannot be built. If the technology is well proven, skip the proof of concept and start with a prototype or an MVP.
How long does a prototype take?
Days to weeks, depending on fidelity. The UK government’s Service Manual says its prototyping phase, alpha, tends to last 6 to 8 weeks, but that covers testing several ideas, not building one set of screens.
How many users do you need to test a prototype?
Around five per round. Jakob Nielsen’s Nielsen Norman Group analysis found five users uncover about 85% of usability problems, so several small rounds are more useful than one large one.
What is the difference between a PoC and an MVP?
A proof of concept (PoC) answers whether something can be built, for your own team. An MVP answers whether customers want it, using a working product in their hands. The EU’s Technology Readiness Level scale puts experimental proof of concept at level 3 of 9.
What is the difference between an MVP and a pilot?
An MVP tests demand with the smallest working product. A pilot assumes demand and tests whether the product works inside a few real customers’ operations before a full rollout. Pilots are common in B2B, healthcare and the public sector.
Can an MVP be built without code?
Sometimes. Landing pages, demo videos and manual services can test demand; Dropbox’s demo video drew 75,000 waiting-list sign-ups in 24 hours, according to its founder. Testing whether people keep using or paying for a product usually needs working software.
Name the question first, then build the cheapest thing that answers it. That single habit stops most founders building the wrong thing first.