Prototype, MVP or pilot: what do you actually need?
Proof of concept, clickable mockup, prototype, MVP, pilot: these terms come up constantly in conversations about new products, and almost everyone means something different by them. That's not just a language problem. Pick the wrong step and you either build too much too early or keep testing with dummies for too long.
Here are the differences in plain language, plus a simple decision guide.
The terms in one sentence
- Proof of concept: proves that something is technically feasible. Usually doesn't look like much.
- Prototype or clickable mockup: shows how the product should look and be used. Doesn't really work, but feels as if it does.
- MVP: the smallest working version that lets real users complete a real task.
- Pilot: an MVP in real use, with real users, real data and real operations over a fixed period.
The comparison
| Proof of concept | Prototype | MVP | Pilot | |
|---|---|---|---|---|
| Answers | Is it technically possible? | Do users understand it? | Do they use it and pay? | Does it work day to day? |
| Actually works | partly | no | yes | yes |
| Typical duration | days | about a week | weeks | weeks to months |
| Effort | low | low | medium | medium to high |
When to start with a prototype
A prototype is the right start when the biggest uncertainty lies with the users: do they understand the offer? Can they find their way through the flow? Do they want it at all?
Typical situations:
- You need to convince people internally before budget is released.
- You want to talk to five to ten potential customers and show them something.
- You're not sure about the flow yet and want to compare variants.
A good prototype costs a fraction of an MVP and often saves weeks, because mistakes surface before they get programmed. At Framepass this step is called the Sprint: in about one week you go from idea to concept, scope and clickable prototype.
When an MVP is the right choice
You need an MVP when you want to see real behaviour, not just opinions. People often say yes in interviews and act differently later. Only when they sign up, enter data or pay do you know whether your product holds up.
An MVP makes sense when:
- the problem and the rough flow are clear,
- you want to know whether people use the product repeatedly or pay for it,
- you need data for the next investment decision.
How to plan an MVP and what it costs is covered in MVP development.
What makes a pilot
A pilot goes one step further: the product runs in real operations, often inside a company, with a limited group and a fixed period. Things that were secondary in the MVP now count: stability, privacy, support and connecting existing systems.
In practice, MVP and pilot often blur. That's why the Framepass package for this step is called Pilot: one working core flow, live, tested with real users or internally in day-to-day operations.
Five questions for your decision
- Is it technically unclear whether it can be done at all? Then start with a proof of concept.
- Is it unclear whether users understand the offer? Then start with a prototype.
- Do you know what to build, but not whether it will be used? Then you need an MVP.
- Does it have to work in a company's daily routine? Then plan a pilot with a fixed period and clear success criteria.
- Do you already have a working product? Then it's about further development, not the first step anymore.
Frequently asked questions
What is the difference between a prototype and an MVP?
A prototype shows how a product should look and be used, but doesn't really work. An MVP is the smallest working version that lets real users complete a real task.
What is a clickable mockup?
A clickable mockup is a prototype whose screens are linked so the flow can be clicked through, without any real logic running in the background.
What is a proof of concept?
A proof of concept shows that an idea is technically feasible. It answers a technical question, not whether users want the product.
Where should I start?
With the step that answers your biggest uncertainty most cheaply: a proof of concept for technical doubts, a prototype for doubts about whether users understand it, an MVP to test real usage.
Conclusion
The terms matter less than the question behind them: what do you need to know next, and what is the cheapest way to that answer? Answer that honestly and you save yourself expensive detours, no matter what the step ends up being called.
