MVP vs prototype vs proof of concept: which one do you need?

A proof of concept asks whether it can work. A prototype asks whether people understand and want it. An MVP asks whether they’ll use it and pay for it. Build the one that answers the question you actually have.

The three terms get used interchangeably, and that’s expensive. Founders build an MVP when a prototype would have answered their question in a third of the time, or show investors a demo and call it an MVP. Here’s what each one is, what it proves and how to choose.

Proof of concept: can it work?

A proof of concept tests whether an idea is possible. Usually that means technical feasibility: can we get this data, can this model produce useful output, can these systems talk to each other. Sometimes it’s commercial: will a partner integrate, will a supplier agree.

It’s usually rough, often not something a customer would ever see, and it can be thrown away once it has answered its question. Its audience is you, your technical team or a technically minded investor.

Build one when the idea depends on something you’re not sure is possible.

Prototype: will people get it, and want it?

A prototype shows how the product would work and feel. It can be clickable screens in a design tool or a coded front end with sample data. It looks like the real thing, and you put it in front of the people you’re building for.

A prototype answers the questions that sink most products: do people understand what it does, can they complete the core task, do they care enough to want it. It’s also the most persuasive thing you can show an investor short of a live product, because they can use it rather than imagine it.

Build one when you believe the idea is possible, but you need evidence that people understand and want it, or you need to raise on it.

MVP: will they use it, and pay?

A minimum viable product is the first version real customers use. It’s live, it works end to end, and it does one job well enough that people choose it. It’s the smallest product that proves the business, and the first one that can earn money and give you real usage data.

Build one when you’re confident in the idea and the design, and the next thing to learn is whether people will adopt it, stay and pay.

Side by side

	Proof of concept	Prototype	MVP
The question	Can it work?	Do people get it and want it?	Will they use it and pay?
Who sees it	You and your technical team	Target users and investors	Real customers
What it is	A rough technical test	Realistic screens, clickable or coded	A live, working product
What you keep	The answer	The design and the evidence	The product
Typical time with us	Days to a few weeks	3 to 6 weeks	6 to 12 weeks
Typical cost with us	Part of a prototype	€8k to €20k	€15k to €50k

The cost figures are our own typical ranges, to give you reference points. We often fold technical feasibility checks into a prototype project, which is why a proof of concept rarely needs a budget of its own.

Which one do you need?

Work through the questions in order, and stop at the first one you can’t answer:

1. Can it be built? If you’re genuinely unsure, test that first. It’s usually quick.
2. Do people understand it and want it? If you don’t have evidence, build a prototype and test it with the people you’re building for.
3. Will they use it and pay? Only a live product answers that. This is when you build the MVP.

If you’re raising a pre-seed or seed round, a well-tested prototype is often enough to show investors the product and the evidence behind it. Many founders raise on the prototype and build the MVP with the money.

Mistakes we see most

• Building an MVP to answer a prototype’s question. Twelve weeks of engineering to find out users don’t understand the core flow, when three weeks of prototype testing would have told you.
• Calling a demo an MVP. If customers can’t use it without you in the room, it isn’t one yet.
• Testing the prototype with friends. Friends are kind. Test with the people you actually want as customers.
• Throwing the prototype away. A good prototype becomes the blueprint for the MVP. The design, the decisions and the evidence all carry forward.

How they fit together

For most products the path runs in order: a quick feasibility check if you need one, a prototype to test the idea with real people, then an MVP built on what the prototype taught you. Each step is cheaper than the next, and each one reduces the risk of the next.

We design and build all three, so nothing is lost between steps. Our proof of concept service produces a tested prototype, clickable or coded, in three to six weeks, and our MVP development takes it to real users. If you’re weighing up the budget, our guide to what an MVP costs goes into the numbers.