MVP vs Prototype vs PoC: What to Build First (And Why It Matters)
Clear definitions and practical guidance on when to build a proof of concept, prototype, or MVP — so you spend your runway on the right thing at the right time.
Why This Question Matters More Than You Think
Most early-stage founders waste their first three to six months building the wrong thing. Not the wrong product — the wrong type of thing. They spend ten weeks building an MVP when a two-week PoC would have answered their core question. Or they ship a rough prototype to paying customers and wonder why churn is destroying them. Or they build a polished prototype, call it an MVP, and raise a seed round on it — then discover they need to rebuild the entire backend before they can onboard their second customer.
The confusion between proof of concept, prototype, and MVP is not semantic pedantry. It has real consequences: misallocated engineering time, runway burned on the wrong artefact, and — most expensively — late discovery of a fatal flaw that could have been caught in week two.
This post gives you precise definitions and the decision framework I use when advising founders on what to build first.
The Definitions (That Actually Hold Up in Practice)
Proof of Concept (PoC)
A proof of concept is an investigation. It answers a single, specific question: is this feasible?
That question can be technical — “can we process real-time video frames at the latency this product requires?” — or commercial — “will anyone pay for a tool that does X?” It can also be regulatory: “can we access the data we need under GDPR?” or operational: “can we source this at the margin the business model requires?”
The defining characteristic of a PoC is that it is disposable by design. You are not building something users will ever touch. You are not writing production code. You are building the minimum thing that generates evidence — a stress test, a landing page with an email capture, a back-of-envelope calculation backed by three customer interviews, or a quick technical spike. The code gets thrown away. The evidence does not.
A PoC answers the question “should we build this?” before you spend serious money finding out the hard way.
Prototype
A prototype is a simulation of an experience. It makes a concept tangible so that you — and more importantly, real potential users — can react to it.
Prototypes live on a spectrum. At one end: a series of static wireframe screens in Figma that simulate a user flow. At the other: a high-fidelity interactive mockup with realistic data and micro-animations, indistinguishable from the real product to a first-time user. Both are prototypes. Neither is a product.
The purpose of a prototype is to test assumptions about the product design — the information architecture, the workflow, the language, the user mental model — before those assumptions get baked into code. A prototype is shown to users. It is not shipped to users.
The critical discipline: do not write production code to build your prototype. Use Figma, Framer, a no-code tool, or a deliberately cobbled-together demo with mocked data. The moment you start treating prototype code as a foundation for the real product, you have lost the primary benefit — the freedom to throw it away when the user testing tells you it is wrong.
Minimum Viable Product (MVP)
An MVP is a real product with deliberately constrained scope.
This is where most of the confusion lives, because “minimum” has been stretched to mean almost anything. An MVP is not a prototype with a backend bolted on. It is not a rough build that you will clean up later. It is not “version one before the real version one.”
An MVP is production-quality software that does fewer things than the eventual product vision. It handles real users, real data, real payments, real failures. It has proper authentication, error handling, and monitoring. It can be shown to paying customers without embarrassment. What it lacks is the second, third, and fourth feature tier — the integrations, the advanced reporting, the collaboration tools, the mobile app.
The scoping discipline of an MVP is deciding what to defer, not what corners to cut on the things you do build. A properly built MVP is boring in the best sense: it works reliably, every time, for the users it was designed to serve.
Side-by-Side Comparison
| PoC | Prototype | MVP | |
|---|---|---|---|
| Primary question | Is this feasible? | Is this the right experience? | Does this business work? |
| Audience | Internal team / investors | Target users | Paying customers |
| Code quality | Throwaway / spike | Throwaway / low-fi | Production standard |
| Typical duration | 1–4 weeks | 4–8 weeks | 10–14 weeks |
| Success metric | Question answered | User insight generated | Retention + revenue |
| Risk if skipped | Building the unfeasible | Building the wrong thing | Shipping too early |
| Common mistake | Showing it to users | Deploying it to users | Cutting the wrong scope |
When to Use Each One
Use a PoC when your biggest risk is feasibility
If you have a technical assumption that the entire product depends on — and you have not yet validated it — run a PoC before anything else. Examples:
- You are building a real-time collaboration tool and have not proven you can handle the WebSocket concurrency at your expected scale.
- You need access to a third-party data source and do not know whether the API terms permit your intended use.
- Your unit economics depend on an AI model achieving a certain accuracy threshold, and you have not tested it on real data.
These are binary questions. Get the answer before you build around the assumption.
Use a prototype when your biggest risk is product design
If you know the thing is technically feasible but you are uncertain whether users will understand, want, or adopt the experience you have designed, run a prototype through at least two rounds of user testing before you write a line of backend code.
This is especially important for products with non-obvious workflows — tools for professionals with existing habits, multi-step processes, anything involving data visualisation or complex configuration. User testing a Figma prototype costs two weeks. Discovering the same design problems after you have built the backend costs two months.
Use an MVP when you have validated the concept and need to prove the business
Once you know the thing is buildable and users respond well to the experience, the next question is whether they will pay for it and keep paying. That requires a real product — one that actually does the thing, reliably, without hand-holding.
If you have done the upstream validation work, your MVP scope is much clearer: you know which features users actually care about (from prototype testing), you know which technical constraints are real (from your PoC), and you can build a focused production system without second-guessing the fundamentals.
The Most Common Mistakes
Calling a prototype an MVP. This is the one that does the most damage. Founders show a prototype to investors, get funding, then discover they have no real product — just a demo. Now they are under pressure to ship something real, with investor money burning, but without having done the architectural thinking that should have preceded the build. The rebuild almost always takes longer than building the MVP correctly from the start would have.
Doing a PoC in your head. Founders with deep domain expertise sometimes skip the PoC because they are confident the thing can be built. Sometimes they are right. More often, they have missed a dependency, underestimated a technical constraint, or assumed market access that does not exist. The point of a PoC is not that you do not know the answer — it is that you should generate evidence rather than rely on assumption.
Building production infrastructure into a prototype. Some founders, particularly technical ones, are uncomfortable with throwaway code. They convince themselves that if they are going to build a demo, they should build it “properly.” This is a trap. The entire value of a prototype is the freedom to discard it. If you build production infrastructure under a prototype, you have spent the time and money of an MVP to generate prototype-level learning.
Scoping the MVP by cutting engineering standards rather than features. The MVP should be narrower, not sloppier. Cutting auth security, skipping error handling, deploying without monitoring — these are not MVP decisions. They are technical debt that accrues interest immediately. The correct scope cuts are: fewer user roles, fewer integrations, fewer reporting views, no mobile app. Not: weaker security, no logging, no backups.
Treating an MVP as the end, not the beginning. An MVP is not a destination — it is a learning instrument. Build it, get it in front of users who pay, and then use what you learn to decide what to build next. Founders who over-invest in their MVP scope — who build towards a polished v1 rather than a focused learning vehicle — typically do so at the cost of the iteration speed that the early stage requires.
What Investors Actually Look For
Seed investors are not buying a product. They are buying a hypothesis that has been intelligently de-risked. The artefact you bring to a seed conversation matters less than the quality of evidence you have generated.
A founder who says “we did a PoC, here’s what we learned, we built a prototype and tested it with forty users, here are the insights, here is the MVP we are now building with those learnings” is making a more credible case than a founder who says “we spent six months building the product and here is the demo.” The former demonstrates epistemic discipline. The latter demonstrates a willingness to burn runway on untested assumptions.
At pre-seed, a credible PoC plus strong founder-market fit is often sufficient. At seed, investors want to see an MVP with real usage — not just the product, but evidence that users find it worth returning to. Prototype-stage traction (signups on a landing page, waitlist numbers) is useful context but rarely sufficient for a seed round from a European institutional investor.
The mistake to avoid: presenting an artefact as more mature than it is. Experienced investors will ask one or two questions that immediately reveal whether your “MVP” is a prototype or your “traction” is theoretical. The credibility cost of overstating maturity is not recoverable.
A Practical Decision Framework
Before committing to what to build, ask these three questions in order:
1. Is there a feasibility assumption the entire product depends on that we have not validated? If yes: run a PoC first. Everything else is premature.
2. Have we tested our product design with real users? If no: build a prototype and run at least two rounds of user testing before writing production code.
3. Do we have enough signal on user behaviour and design to build a focused production system? If yes: define your MVP scope, commit to production engineering standards, and build.
This is not a rigid sequence — you may compress or combine stages depending on your domain expertise and the nature of the risk. But it is the right order of questions.
If you are at the stage of scoping your MVP, the post on how to build a SaaS MVP covers the architecture decisions, feature scoping, and engineering standards in depth.
The Honest Summary
PoC, prototype, and MVP are not interchangeable terms for “early-stage product.” They are distinct tools for distinct purposes, used at distinct stages of de-risking a business.
Use the wrong one and you waste time validating the wrong question. Call one by another’s name and you mislead investors, misalign your team, and miscalibrate your own understanding of where you actually are.
The discipline is knowing which question you are trying to answer — and building the minimum thing that answers it, nothing more.
Jahja Nur Zulbeari
Founder & Technical Architect
Zulbera — Digital Infrastructure Studio