A proof of concept answers "can this be built?". A prototype answers "is this the right experience?". An MVP answers "will people use it and pay for it?". They reduce three different risks: technical, design and market. Pick the one that matches your biggest unknown, and skip the ones whose question you can already answer.
Definitions
Proof of concept (PoC)
A small technical experiment that tests whether one specific thing is feasible. It has no real interface, no accounts and no polish. Its audience is internal: you, your engineers, sometimes a technical investor or a partner's IT team. The result is an answer, ideally with numbers attached: the model extracted the right fields from 92 of 100 sample invoices; the partner API returns availability in under a second; the sensor data can be read over Bluetooth on both platforms.
A good PoC is framed as a question with a pass mark agreed in advance. "Explore what AI can do for us" is not a PoC. "Can a hosted language model classify our support tickets into these eight categories with at least 90% agreement with our agents, on 500 historical tickets?" is one.
Prototype
A model of the product that shows how it would look and flow. Most prototypes today are clickable screen designs made in a design tool: they feel like an app when tapped through but nothing is stored and nothing is calculated. Some are coded, with fake data, when the interaction is too dynamic to simulate in a design tool.
The audience is external but guided: target users in a test session, stakeholders, investors. You learn whether people understand the product, whether they can find their way through it, and how they react to the promise. You do not learn whether they would come back next week, because there is nothing to come back to.
Minimum viable product (MVP)
The smallest working version of the product that lets real users complete the core job without you in the room, and lets you observe whether they do. It runs in production, stores real data, and takes real payments if payment is part of the test. It is narrow by design, but what it does, it does properly.
"Minimum" describes the scope. It does not describe the quality. An MVP that loses data or breaks at checkout does not test the market. It tests users' patience.
Side-by-side comparison
| Proof of concept | Prototype | MVP | |
|---|---|---|---|
| Question it answers | Can it be built? | Is this the right experience? | Will people use it and pay? |
| Risk it reduces | Technical feasibility | Usability and desirability | Market demand and retention |
| Audience | Internal team, technical stakeholders | Test users in guided sessions, investors, stakeholders | Real users on their own |
| Fidelity | Rough. Scripts, notebooks, a bare test page. | Looks real, does nothing real | Looks adequate, works for real, narrow scope |
| Typical time | 1–4 weeks | 1–3 weeks for a design prototype; longer if coded | 2–4 months |
| Typical cost band | Roughly $3,000–$20,000 | Roughly $2,000–$15,000 | Roughly $15,000–$80,000 for most scopes |
| What you learn | Whether the hard part works, how well, and what it would take to make it production-grade | Where people get confused, what they expect, whether the pitch lands | Activation, repeat use, willingness to pay, what users ask for next |
| What happens to the code | Discarded. The findings and sometimes a core algorithm carry forward. | Designs carry forward. Any code is discarded. | Kept and extended, if it was built on a sound stack |
| Main way it goes wrong | Grows an interface and becomes a bad MVP | Presented or sold as a working product | Scope grows until it is version two |
About the cost and time bands. These are planning estimates based on typical effort (one or two people for a PoC or prototype, a small team for an MVP) across the range of international market rates. They are not survey data and not a BBR price list. The arithmetic behind the MVP band is shown in our MVP cost breakdown.
Decision rules: which one do you need?
Start from the thing you are least sure about.
- "I do not know if this is technically possible, or possible at acceptable quality, speed or cost." Proof of concept. Common for AI features, computer vision, hardware, heavy data processing and integrations with systems you do not control.
- "It can obviously be built. I do not know if users will understand it or want it." Prototype, tested with five to eight people from the target group.
- "I need to raise money or get internal sign-off and have nothing to show." Prototype. It is the cheapest credible artifact. Be clear with your audience that it is a prototype.
- "People have told me they want it and I understand the workflow. I do not know if they will really use it or pay." MVP.
- "I already deliver this by hand to paying customers and it does not scale." MVP, and you can likely skip the prototype's user testing because the workflow is proven.
- "I am not sure anyone has this problem." None of the three. Interviews, a landing page or a manual service come first. See step one of our MVP process guide.
When you can skip a stage
Skip the PoC when the product is assembled from well-understood parts. A booking platform, a subscription content app or a B2B dashboard has no feasibility question worth paying to answer.
A separate prototype phase can be folded into the MVP project when the interface follows familiar patterns. Any competent MVP engagement includes a clickable design review before engineering starts, which does the prototype's job for the core journey.
Do not skip to a full product. The argument "we know what users want, an MVP would be a waste" is made most confidently by teams who have not yet shown the product to a user.
How they sequence
When all three are needed, the order follows the order in which the risks can kill the project: feasibility, then experience, then market.
- PoC: prove the hard part. One to four weeks.
- Prototype: design the experience around what the PoC showed is possible, and test it with users. One to three weeks.
- MVP: build the narrow working product. Two to four months; phase durations are in the MVP timeline guide.
Example: an AI product that needs all three
A founder wants an app that reads contractor quotes and flags missing items. The uncertain part is whether a language model can read messy PDF quotes accurately enough. A two-week PoC runs 100 real quotes through a hosted model and scores the output against a human reviewer. It passes, with a known weakness on scanned handwriting. The prototype then designs a flow that shows the model's confidence and lets users correct it. The MVP builds upload, analysis, a results screen and payment, and leaves handwriting support out. Our guide to building an AI product covers this evaluation-first approach in more depth.
Example: a product that needs only one
A physiotherapist who already sells exercise plans as PDFs wants clients to follow plans in an app with reminders. Nothing here is technically uncertain, and paying clients already exist. A design review inside the MVP project is enough. A separate PoC or prototype phase would add cost and delay without reducing any real risk.
Common confusions
"MVP" used to mean a cheap, low-quality version
The scope is minimal. The engineering should not be. A first release built on a mainstream stack with sensible structure can be extended for years. One built as a throwaway will be thrown away, usually at the moment you can least afford a rewrite. Stack choice is covered in choosing a tech stack for an MVP.
A PoC with a login screen
Once a proof of concept acquires accounts, styling and a settings page, it has stopped answering a feasibility question and started being a product built without product discipline. Keep PoCs ugly and short.
Pilot vs MVP
A pilot is a trial of a product with a specific customer or group, often in B2B, with agreed success criteria. An MVP is the thing being trialed. You can run a pilot with an MVP.
Wireframe, mockup, prototype
A wireframe is a layout sketch. A mockup is a static visual design. A prototype links screens so that someone can click through a flow. Only the last one can be tested with users in a meaningful way.
Prototype vs demo
A demo is scripted and driven by you. A prototype is handed to the user. If you only ever show it while holding the mouse, you are learning about your presentation, not about the product.
What to ask a vendor
When a proposal uses any of these terms, check that you and the vendor mean the same thing:
- What question will this deliverable answer, and what result counts as a pass?
- Who will use it, and will they use it unassisted?
- Does it store real data and run in a production environment?
- Which parts carry forward to the next stage, and which are discarded?
- If it succeeds, what is the next stage and roughly what does it cost?
At BBR, scoping starts with the same question this article does: which risk is still open. The MVP development page describes how a first-release engagement is structured, including the prototype review that happens before the build starts.