Founders often ask us for an MVP when what they need first is a proof of concept, or a prototype. The three answer different questions, and building the wrong one wastes the most expensive part of a project: time. This guide explains what each one tests, who sees it, what goes into it, and how to decide which to build first.
The short answer
- Proof of concept (PoC): answers "can this be built?" It tests one technical risk, usually in private, and is thrown away.
- Prototype: answers "will people understand and want this?" It shows how the product works, often without real code behind it, and is used in user testing and with investors.
- MVP (minimum viable product): answers "will people use it, and pay for it?" It is a real, working first version that real customers use.
Most products need at most two of these before launch. Many need only an MVP.
Side by side
| Proof of concept | Prototype | MVP | |
|---|---|---|---|
| Question it answers | Is it technically possible? | Do users understand it, and do they want it? | Will people use it and pay? |
| Who sees it | The team, sometimes an investor | Test users, stakeholders, investors | Real customers |
| What it is | A script, a spike or a small internal demo | Clickable screens, from sketches to high-fidelity designs | A working product with a small feature set |
| Real data and accounts | Sometimes, one narrow case | No, or sample data | Yes |
| Code quality | Disposable | Usually no production code | Production code that will grow |
| What happens next | Thrown away; the learning stays | Becomes the design reference for the build | Becomes version 1 of the product |
| Typical output | A yes or no on one risk | Test findings and a design the team agrees on | Usage data, feedback and first revenue |
Proof of concept: test the risky part first
A PoC is worth it when one part of the idea might not work at all. Examples:
- An AI feature has to extract the right fields from messy supplier invoices. Before anything else, run real invoices through a model and measure how often it gets them right.
- A product depends on an ERP or a third-party API that may not expose the data you need. Prove you can read and write the records you need.
- A real-time feature has to handle a certain number of simultaneous users. Load-test the core before designing screens.
Keep a PoC narrow: one question, one written success criterion, and real inputs. If you find yourself adding a login screen, it has stopped being a PoC.
If the idea relies on AI, the PoC is usually an evaluation set: real examples with the expected answers, scored automatically. Our guide to building an AI MVP covers how to set one up.
Prototype: test the experience before paying for code
A prototype shows how the product will work so you can test it with people before development starts. Nielsen Norman Group distinguishes low-fidelity prototypes, such as paper sketches, from high-fidelity ones that look and behave close to the final product. Both are useful at different stages.
Build a prototype when:
- The workflow is new, or has several steps users could get lost in.
- You need to agree on what the product does with co-founders, stakeholders or a client.
- You are raising money and need to show the product, not describe it.
A good prototype covers the main path from start to the useful result, with realistic content. Test it with five or so people from your target group, watch where they hesitate, and change the design before any code is written. Changing a screen in Figma takes minutes; changing it after it is built takes days.
What a prototype can't tell you: whether people will come back, whether they'll pay, and whether the product holds up with real data.
MVP: the smallest real product
The Lean Startup describes the MVP as the way to begin learning as quickly as possible. In practice it is the smallest version of the product that a real customer can use for its main job, and ideally pay for.
An MVP is not a rough prototype with a login added. It is real software:
- Real accounts and real data, stored securely.
- One core workflow that works end to end.
- For a subscription product, billing and separation between customers from day one. Our SaaS MVP guide explains why.
- Code that the next versions will build on, not throw away.
What keeps it minimal is the scope, not the quality. Cut features, not foundations.
How to choose your first step
Answer these in order:
- Is there a part that might be technically impossible? If yes, start with a proof of concept for that part only.
- Is the workflow new, or do several people need to agree on it? If yes, build a prototype and test it with users.
- Do you already know users want this, from a waiting list, pre-orders, an existing client or your own experience? If yes, go straight to the MVP.
| Situation | Start with |
|---|---|
| AI must do a task you've never seen a model do reliably | Proof of concept with an evaluation set |
| A new workflow for non-technical users | Prototype, then MVP |
| You're replacing a spreadsheet process you know well | MVP |
| An integration you're not sure the other system supports | Proof of concept for the integration |
| Raising a pre-seed round with no product yet | Prototype |
| An existing client is waiting to use it | MVP |
Common mistakes
- Calling a prototype an MVP. Clickable screens can't show whether people will keep using a product.
- Polishing the PoC. A proof of concept that grows into the product carries shortcuts into production.
- Skipping the prototype for a complex workflow. Design problems found after the build are the most expensive to fix.
- An MVP with ten features. Every extra feature delays the first real feedback.
- No written success criterion. Without one, every result looks like a reason to keep going.
A sensible path for most products
- Discovery: write down the user, the job, the riskiest assumption and how you'll know it worked.
- If there's a technical risk, a short proof of concept on that risk.
- If the workflow is new, a prototype tested with real users.
- The MVP, scoped to the one job, with real accounts and data.
- Launch to a small group, measure, and decide what to build next.
The UK Government's service manual describes a similar sequence: a discovery phase to understand the problem, an alpha phase to try out different solutions, and a beta phase to build a real service and test it with users.
Want help deciding?
We help founders and product teams decide what to build first, then build it: proofs of concept for AI and integration risks, prototypes in Figma, and SaaS and AI MVPs in TypeScript. Tell us your idea on our MVP development page, or see how we build SaaS products and UI/UX designs.
