Prototype vs MVP vs proof of concept: which should you build first?
A proof of concept, a prototype and an MVP each answer a different question. Building them in the wrong order, or treating a demo as a product, is how early budgets get spent on questions that were already settled while the open one waits.
Should you build a prototype or an MVP first?
Quick answer
Prototype vs MVP is a choice about which question is still open. A prototype tests whether people understand and want the flow, using sample data. An MVP is a small, real product that shows whether people will use it or pay for it. Agnotic Technologies builds both and starts with whichever answers your riskiest question.
| Criterion | Prototype | MVP |
|---|---|---|
| Question it answers | Do people understand and want this flow? | Will people use it, or pay for it, in real conditions? |
| Audience | Target users in test sessions, stakeholders and investors | Early customers and real users in their daily work |
| Fidelity | Anything from clickable screens to rough working code | Production quality for every feature it includes |
| Data | Sample or invented data only | Real data, with the security and privacy controls that requires |
| Code kept afterwards | Little or none: design decisions carry over, code usually does not | All of it: the MVP is the first version of the product |
| Security and operations | Out of scope, which is why it must never face real users or data | Sign-in, access control, logging, backups and monitoring from the first release |
| Exit criteria | Users complete the main tasks in tests, and the team agrees the scope | The agreed usage, retention or revenue signals are reached, or a clear decision to change course |
| Evidence for investors or a first customer | Test session findings and a scope people agreed to | Usage data, customer feedback and, where it applies, payments |
What they are
What is Prototype
A prototype is a model of the product that people can click through or try, built to test the flow, wording and layout with users. It may be a clickable design or throwaway code, it runs on sample data and it is not meant to be deployed.
What is MVP
An MVP is the smallest release of the real product that users can rely on: production code, real data, sign-in, security and support. It exists to learn whether the product creates value in use, so it has to be built to be kept and extended.
Key differences
Where does a proof of concept fit?
Before both, when the open question is technical: will this API return the data we need, can this model reach a usable accuracy, can this device stream reliably enough? A proof of concept answers that one question for the engineering team and technical decision makers, usually with no user interface at all. Feasibility tests for AI models have their own approach, covered on our AI proof of concept page.
In what order should you run them?
The default order is a proof of concept for the riskiest technical assumption, a prototype for the riskiest user assumption, then the MVP. Skip the proof of concept when the technology is well known, such as a standard web app on a common stack. Skip the prototype when the flow copies one users already know, but still test the wording. Never skip deciding which question is open.
What must a prototype never become?
Production code with demo shortcuts: hard-coded credentials, missing authorization checks, sample and real data mixed together, no tests and no logging. NIST SP 800-218 observes that few software development life cycle models address security in detail, so secure development practices usually have to be added to each one. A prototype leaves those practices out on purpose, which is why it cannot be promoted as it stands.
Should you rewrite or harden the prototype?
Rewrite when the prototype was a design tool or throwaway code. Harden only when it was built on the production stack with tests and a reviewed architecture. To list what the MVP needs that the prototype lacked, use a product quality model: ISO/IEC 25010:2023 defines nine quality characteristics as a reference for specifying and evaluating product quality, including setting acceptance criteria.
How do you test a prototype with users?
ISO 9241-210:2019 sets out requirements and recommendations for human-centred design activities throughout the life cycle of interactive systems, and testing designs with users is central to it. In practice, give participants realistic tasks, watch without helping, note where they hesitate and change the prototype between rounds. How much fidelity each round needs is covered on our wireframing and clickable prototypes page.
When to use each
When to use Prototype
- You have not yet watched target users try the main flow.
- Stakeholders disagree on what the product should do, and a shared model would settle it.
- An investor or first customer needs to see the idea before committing.
- The flow touches sensitive data, and you want feedback before any real data is involved.
When to use Minimum viable product (MVP)
- Users have tried a prototype and the flow held up.
- The technical risk is known, or a proof of concept has already tested it.
- You need usage, retention or payment evidence that only real use produces.
- A first customer is ready to run it in their own work.
Which should you build first? A decision list
1. Is the main technical risk untested, such as an integration, a data source or a model's accuracy? Run a proof of concept on that one risk first.
2. Have target users tried the main flow? If not, build a prototype and test it before writing production code.
3. Do stakeholders still disagree on scope? A prototype they can click through settles it faster than more documents.
4. Are both risks answered? Build the MVP, with real data, security and support, around the one job users showed they need.
5. Was the prototype built on the production stack, with tests and a reviewed design? Only then harden it; otherwise keep the design and rewrite the code.
6. Did the MVP miss its exit criteria? Go back to prototyping for the part that failed instead of adding features.