What a prototype, a minimum viable product and a pilot each test, how they differ in cost and risk, and how to pick the right first step.
In short
Build a prototype when you need to learn whether people understand and want a solution, an MVP when you need real users to prove they will use or pay for it, and a pilot when you need to prove a solution works in real operations before rolling it out. Most new digital products go prototype first, then MVP; pilots suit internal tools and B2B rollouts.
"Let's build an MVP" has become the default answer to every new product idea, and it often means building too much too early. A prototype (prototyp), a minimum viable product and a pilot answer different questions, at very different costs. This comparison from Devies, a Gothenburg-based product and engineering consultancy, is for founders, product leads and business owners deciding what to build first.
What are a prototype, an MVP and a pilot?
Each of the three is a way to reduce a specific risk before committing to a full product. They differ in what they test and who uses them.
A prototype is a model of a solution built to test an idea, usually with a small number of users in a controlled session. It can be a clickable design, a paper sketch or throwaway code. The UK government's service manual describes the alpha phase in exactly these terms: build prototypes, test the riskiest assumptions, and expect to throw away the code and many of the ideas at the end.
A minimum viable product (MVP) is the smallest working version of a product that real users can use in real conditions, built to learn as much as possible with the least effort. Eric Ries, who popularised the term, defines it as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort, and stresses that it is not about building minimal products for their own sake.
A pilot is a limited rollout of a working solution to a defined group, site or time period, to prove it works in real operations before scaling. Pilots are common for internal systems, AI tools and B2B products sold into large organisations, where the question is less "do people want this?" and more "does it work here, with our data, processes and people?".
How do they compare?
The table compares the three across the criteria that usually decide which comes first.
Criterion
Prototype
MVP
Pilot
Main question
Prototype
Do people understand and want this solution?
MVP
Will real users use, return to or pay for it?
Pilot
Does it work in real operations at our scale?
Users
Prototype
5 to 10 people in test sessions
MVP
Early real customers or users
Pilot
A defined team, site or customer segment
Fidelity
Prototype
Low to high, often not working software
MVP
Working, narrow, production quality where it matters
Pilot
Working, close to the final solution
Typical time
Prototype
Days to a few weeks
MVP
Weeks to a few months
Pilot
One to three months of use
Code reuse
Prototype
Expect to throw it away
MVP
Foundation for the product
Pilot
Usually becomes the product
Main risk reduced
Prototype
Wrong problem or wrong solution
MVP
No demand or no habit
Pilot
Operational, technical or organisational failure
Evidence produced
Prototype
Observed behaviour and feedback
MVP
Usage, retention, conversion, revenue
Pilot
Measured effect against a baseline
The key difference is what counts as success. A prototype succeeds when it changes your mind cheaply. An MVP succeeds when it produces evidence of real demand or real use. A pilot succeeds when it shows a measurable effect in operations and reveals what must change before rollout.
When should you start with a prototype?
Start with a prototype when the biggest uncertainty is about the problem or the solution, not about technology or scale. It is the cheapest way to be wrong.
Choose a prototype when
- You are not yet sure which problem matters most to users, or how they would expect to solve it.
- Several solution ideas compete and you need to choose before building.
- The interface or workflow is new and you need to see whether people can use it.
- You need something concrete to show investors, management or a key customer.
Test the prototype with a handful of real users and watch what they do; our guide to usability testing on a budget describes a lightweight method. Five sessions often reveal the main problems.
When should you build an MVP?
Build an MVP when you have evidence that the problem is real and the solution makes sense, and the remaining question is whether people will actually use it, come back or pay. An MVP must be usable for real, which means reliable enough for the core flow and honest about what is missing.
Choose an MVP when
- Prototype tests showed that users understand and want the solution.
- You can define one core job the product does well, and leave the rest out.
- You can measure success with behaviour, such as sign-ups, repeated use or purchases, not only opinions.
- You can reach early users who tolerate gaps in return for solving their problem.
The commonest MVP mistake is scope. Every feature added "because customers will expect it" delays the learning. Write down the one hypothesis the MVP tests and cut anything that does not serve it. A realistic estimate helps here; our guide to software estimation leaders can trust explains how to size it.
Sometimes the narrow first version can go straight to production quality. Devies built a cross-platform Flutter app for reading industrial vibration sensors over Bluetooth Low Energy from concept to app store deployment in 30 days, with a white-label architecture so one codebase serves several customer configurations. A tight, well-understood scope made that possible.
When is a pilot the right first step?
A pilot is the right first step when the solution itself is reasonably proven, but you do not know whether it works in your organisation, with your data and your people. It is common for:
- Internal tools and AI assistants, where accuracy, adoption and process fit must be measured before rollout.
- B2B products sold to large customers, who want a limited deployment with agreed success criteria before signing a full contract.
- Replacements of existing systems, where you need to run the new solution in one unit or region first.
A good pilot has a baseline, a defined group, agreed success measures and a decision date: scale, change or stop. The service manual describes a similar step in its beta phase: a private beta with a limited number of users, followed by a public beta when the service can run at scale, as set out in how the beta phase works.
How do the three fit together?
For a new digital product, the usual order is prototype, then MVP, then scale. For a new internal or B2B solution, it is often prototype, then pilot, then rollout. Skipping the prototype is the most expensive shortcut, because it moves the cheapest learning into the most expensive phase.
Use these questions to decide where you are:
- Do we know which user problem we are solving? If not, do discovery work before building anything.
- Do we know whether our solution makes sense to users? If not, build a prototype.
- Do we know whether real users will use or pay for it? If not, build an MVP.
- Do we know whether it works in real operations at scale? If not, run a pilot.
- If all four answers are yes, build and scale the product.
Our guide to the digital product development process shows how these steps fit into the full path from idea to release.
Devies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
What is the difference between a prototype and an MVP?
A prototype is built to test an idea or a design, usually with a few users in a controlled session, and is often thrown away. An MVP is a working product used by real users in real conditions, built to learn whether people will actually use, return to or pay for it. A prototype answers "does this make sense?"; an MVP answers "will people use it?".
What does MVP stand for?
MVP stands for minimum viable product. The term was popularised by Eric Ries in the Lean Startup method, where it describes the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. "Minimum" refers to the effort needed to learn, not to building a poor or incomplete product.
How long does it take to build an MVP?
It depends on the scope, the platform and how much already exists, but most focused MVPs take from a few weeks to a few months. If the estimate grows beyond that, the scope usually includes features that do not test the core hypothesis. Agree the one question the MVP must answer, and cut everything that does not help answer it.
Is a pilot the same as a proof of concept?
No. A proof of concept tests whether something is technically possible, often in isolation and without real users. A pilot runs a working solution with real users in real operations for a limited group or period, to prove it delivers value and to find what must change before rollout. A proof of concept can come before a pilot, but it does not replace it.
