BYD TechThe short answer
A proof of concept tests whether something can be built at all. A prototype shows how the product will look and flow, with nothing real behind the screens. An MVP is real software that real users can sign up for and use. They answer three different questions, so the right one depends on which risk worries you most.
Key points
- Proof of concept: can this be built? It tests a technical risk.
- Prototype: will people understand and want this flow? It tests the design.
- MVP: will people actually use it, and keep using it? It tests demand.
- Many products skip the proof of concept. Few should skip the prototype.
The three, side by side
| Proof of concept | Prototype | MVP | |
|---|---|---|---|
| Question it answers | Can it be built? | How should it work? | Will people use it? |
| Who sees it | Your own team | Test users, investors, developers | Real users |
| Is it real software? | A rough, partial piece | No. Linked screens only | Yes |
| What you keep | A yes or no, and what you learned | The agreed flow and design | A working product and usage data |
| Risk it removes | Technical | Design and usability | Demand |
Proof of concept: can this be built?
A proof of concept is a small experiment aimed at one technical doubt. Can the AI model read these invoices accurately enough? Can the app sync when the phone has been offline for a day? Will this hardware talk to that API? It is usually ugly, it is usually thrown away, and nobody outside the team needs to see it.
You need one only when the answer is honestly unknown. A booking app, a marketplace or a customer portal uses well-understood parts, so there is nothing to prove. An AI feature that has to be right on your own messy data is a different matter, which is why we test agents on real past tickets before launch in AI agent development.
Prototype: how should it work?
A prototype is a set of designed screens linked together so someone can tap through them. Nothing is saved and nothing is sent. It exists to test the flow before code makes changes expensive, and to give investors, first users and developers something concrete to react to.
- Use it to find where people hesitate. Watching five people try a flow shows most of its problems.
- Use it to agree on scope. A screen that is not in the prototype is not in v1.
- Do not confuse a good reaction with demand. People are polite about screens and honest with their time and money.
A clickable prototype is the first thing we make in UI/UX design, and it lives in your own Figma.
MVP: will people use it?
An MVP is real software, small on purpose. Users create accounts, do the one job the product exists for, and their data is stored. It is the only one of the three that can tell you whether people come back, because it is the only one they can really use.
Small does not mean sloppy. An MVP still needs sign-in that works, data that is safe, and backups. What it leaves out is breadth: the second user type, the reports, the settings nobody has asked for yet. The steps are in How to build an MVP.
Which one do you need?
- If you are not sure it can be built, start with a proof of concept for that one doubt.
- If it can clearly be built but you are not sure how it should work, start with a prototype.
- If the flow is agreed and the open question is whether people will use it, build the MVP.
- If you already have a no-code or AI-built version with real users, you have an MVP. The question now is what to keep and what to rebuild.
The common order is prototype, then MVP. A proof of concept comes first only when there is a real technical unknown.
Sources
Checked when this guide was written.
