MVP vs Prototype vs Proof of Concept: What’s the Difference and Which Do You Need
These three terms are used interchangeably by founders, investors, and developers — and they mean completely different things. Getting the distinction wrong leads to building the wrong artifact for the question you are trying to answer, wasting time and money in the process.
Building the Wrong Thing for the Right Question
A proof of concept (PoC) answers the question: can this be built? A prototype answers the question: does this design work for users? A minimum viable product (MVP) answers the question: will users pay for this? These are three fundamentally different questions that require three fundamentally different artifacts. A founder who builds an MVP when they need a prototype spends $15,000 to answer a question that a $500 Figma prototype could have answered in a week. A founder who builds a prototype when they need an MVP discovers, after positive user testing feedback, that they still do not know whether anyone will pay for the product.
When to Build Each One
| Artifact | Question It Answers | What It Is | Cost Range | Timeline |
|---|---|---|---|---|
| Proof of Concept (PoC) | Can this be built? Does the core technology work? | A technical demonstration of a specific capability or integration — not user-facing; may be a script, a data pipeline, or an API integration test | $500-5,000 | 1-2 weeks |
| Prototype | Does this design make sense to users? Will users understand the flow? | A clickable, non-functional mock-up of the product’s key screens and flows — typically built in Figma; no real data, no real logic | $500-3,000 | 1-2 weeks |
| Minimum Viable Product (MVP) | Will users pay for this? Does this product solve a real problem? | A functional product with real data, real logic, and real user authentication — capable of being used by real users for real tasks and accepting real payment | $6,000-25,000 | 4-12 weeks |
Practical Decision Guide for Founders
When you need a Proof of Concept
A PoC is warranted when a specific technical integration or capability is genuinely uncertain and the entire product concept depends on it. Example: a founder building a compliance tool that needs to connect to a specific government data API should build a PoC to confirm the API is accessible, returns usable data, and can be integrated before committing to a full MVP build. If the PoC fails — the API is not publicly accessible — the founder has saved a $15,000 MVP investment by spending $1,000 on a PoC first.
When you need a Prototype
A prototype is warranted when the core UX flow is complex, unfamiliar, or involves a novel interaction pattern that you want to validate before building. For simple, well-understood flows (a sign-up, a dashboard, a form submission), a prototype is typically unnecessary — go directly to the MVP build. For two-sided marketplaces with complex matching flows or data visualisation products where the chart design drives core value, a Figma prototype run through 5 user testing sessions before development begins prevents expensive UX redesigns after the product is built.
When you need an MVP
An MVP is warranted when: the problem has been validated through user research; the core flow is defined; and the user testing question is no longer does this make sense but will people pay for this? At this point, a Figma prototype cannot generate the commercial viability signal you need — only a functional product with a real payment flow can do that.
🔗 Related reading on sasolutionspk.com
Minimum Viable Product Strategy: How to Launch Fast and Validate Your Idea
SA’s full MVP strategy guide — the context in which the MVP fits within the broader product validation and launch process.
How These Artifacts Work Together
For most product concepts, the optimal sequence is: user research (to validate the problem) then prototype (to validate the flow, for complex UX) then MVP (to validate commercial viability) then product iterations (to reach product-market fit). Many founders skip the prototype step and go directly from user research to MVP, which is appropriate for simple, well-understood flows.
User research first
Always. Before any artifact. 10-15 conversations with target users about the problem, not the solution, is the cheapest possible validation investment and the one most frequently skipped.
Prototype if the flow is complex
If the core UX involves novel interaction patterns, multi-step flows with complex branching logic, or a data visualisation design that is central to the value delivery, invest in a prototype before the MVP build.
MVP to test commercial viability
Once the problem is validated and the flow is tested, build the MVP. The MVP’s job is to answer one question: will real users in the target segment pay real money for this product?
Q: Can a landing page be considered an MVP?
A landing page is a lightweight demand validation artifact — sometimes called a smoke test or pre-MVP. It tests whether people are interested enough in the described product to give their email address, which is a weaker signal than whether they will pay. A landing page is appropriate before building even a prototype when you want to validate market size and interest level before investing in design or development. It generates a useful signal but should not be confused with an MVP: a landing page tells you people are curious; an MVP with paying users tells you people value the product enough to spend money on it.
Q: How do I know if I need a PoC before my MVP build?
SA’s test: is there a specific technical component of your MVP that could fail in a way that would make the entire product concept non-viable — and is that component genuinely uncertain? If yes, build a PoC for that specific component before committing to the full MVP. If the technical components of your product are all standard integrations (Stripe payments, OAuth login, a REST API connection to a well-documented SaaS tool), there is no meaningful technical uncertainty to validate — go directly to the MVP build.
Q: Do investors care whether I show them a prototype, a PoC, or an MVP?
Investors at pre-seed and seed care primarily about two things: the quality of the insight behind the product and the traction evidence (paying users, retention data, or strong demand signal from a validated landing page). A polished Figma prototype with zero user engagement is less compelling than a rough but functional MVP with 20 paying customers. Show the most advanced artifact that has generated real user interaction — and be specific about what the artifact is and what question it was designed to answer.
Ready to Build Your MVP?
SA Solutions builds MVPs in weeks using Bubble.io. Start with a free audit or scope your build in 48 hours with a Discovery Sprint.
