"Let's build a prototype" and "let's build an MVP" get used interchangeably, and the conflation is expensive. We've seen founders pour three months into a polished prototype when a two-week MVP would have answered the real question—and the reverse, shipping a shaky MVP when a one-week clickable prototype would have killed the idea before any code was written.
These are different tools for different jobs. Picking the right one starts with naming what you actually don't know.
The Core Difference
A prototype is a throwaway experiment designed to answer one specific question. It can be a Figma flow, a clickable mock, a paper sketch, or a rough technical proof-of-concept. Nobody uses it to do real work. Its only job is to reduce uncertainty cheaply.
An MVP is a real product—narrow in scope, but genuinely usable. Real users solve real problems with it. It runs in production, handles real data, and gives you behavioral feedback instead of opinions.
Put more bluntly:
- A prototype asks: could this work?
- An MVP asks: do people actually want this when it does work?
The first question is about feasibility and desirability in the abstract. The second is about demand under real conditions—with real money, real effort, real switching costs.
The Three Kinds of Prototypes (and What Each Is For)
Not all prototypes are the same. The common thread is that they're cheap to throw away; the differences are about which unknown they attack.
1. Design prototypes (wireframes, Figma flows, clickable mocks) answer do users understand this? Put it in front of five users, watch where they get stuck, iterate in hours instead of weeks. If your risk is "will anyone figure out how to use this," start here.
2. Functional prototypes (a rough end-to-end flow, often in no-code or stitched-together tools) answer does this workflow hang together? They're for validating that the pieces connect, not that the code is any good.
3. Technical proof-of-concepts answer can we actually build this? If your product depends on something genuinely uncertain—real-time sync at scale, an ML model hitting a required accuracy, an integration with a finicky third-party API—build the smallest thing that proves the hard part works. Nothing else. No UI. No auth. Just the scary part, isolated.
The Decision Framework: Name Your Riskiest Assumption
Before building anything, write down the one assumption that, if wrong, makes the whole idea collapse. Then pick the cheapest tool that tests it.
| Your biggest risk | Build this first |
|---|---|
| "Users won't understand the flow" | Design prototype |
| "The technical approach won't work" | Technical proof-of-concept |
| "Nobody actually has this problem" | Skip to customer interviews |
| "People say they want this, but won't pay or switch" | MVP |
| "The unit economics don't work at scale" | MVP with real pricing |
Notice that for two of these rows, the answer isn't "build something" at all. If your biggest unknown is whether the problem exists, twenty customer conversations will teach you more than any prototype.
When to Prototype First, Then MVP
Sequence them when the prototype kills a cheap-to-test assumption that would invalidate the MVP. Example: you're building a tool that stitches together five SaaS APIs. If the core integration doesn't work, the MVP is pointless. Spend a week on a technical PoC first, isolated from everything else. If it works, you know the MVP is worth building. If it doesn't, you saved three months.
Sequence them when the UX is genuinely novel. If your product asks users to do something they've never done before, a clickable prototype will expose confusion in days. Shipping an MVP and watching users bounce tells you the same thing, but slower and more expensively.
When to Skip the Prototype
Skip it when the real risk is demand, not feasibility or clarity. If you're building a variant of something that already exists (another project management tool, another invoicing app), the question isn't "can this be built" or "will users understand it"—the answer to both is obviously yes. The question is "will anyone switch." Only a real product in real users' hands answers that.
Skip it when the prototype would take nearly as long as the MVP. There's a point where the cost of faking something (stubbing APIs, mocking data, building a throwaway UI) approaches the cost of just building the thin real version. When you hit that point, build the real thin thing.
The Throwaway Rule
The single most common mistake we see: treating a prototype as the starting point of the real codebase. Someone builds a quick proof-of-concept, it kind of works, and then the team tries to harden it into production instead of rewriting.
This almost always goes badly. Prototype code was written to answer a question, not to be maintained. It has no tests, no error handling, no auth, no thought about the edge cases that dominate production. Wrapping it in a production shell doesn't fix those problems—it just buries them.
If the prototype proves the idea works, celebrate, then rewrite the MVP from scratch with the knowledge you now have. You'll do it faster the second time, and the result will be something you can actually build on. For more on what that rewrite should look like, see What Makes a Good MVP.
Two Anti-Patterns to Watch For
The polished prototype. Weeks spent making a Figma file pixel-perfect and interactive before anyone's used it. If the prototype's job is to learn, learn with the ugliest version that still answers the question. Polish is an MVP concern.
The "MVP" that's really a prototype. Shipping something to five friends who give you polite feedback. That's not an MVP—that's a prototype with an audience that won't tell you the truth. An MVP needs real users with a real reason to use it, ideally ones willing to pay or switch away from an existing solution.
How to Pick, in One Sentence
If your biggest unknown is about the product itself—how it works, whether it can work, whether users get it—prototype. If your biggest unknown is about the market—whether people care enough to use and pay for a working version—MVP.
Everything else is a variation on that theme.
Ready to Figure Out What to Build?
We help founders decide between prototype, MVP, or something in between—and then build whichever one actually answers their question. Often in a 30-minute conversation we can save you a month of building the wrong thing.
Get in touch if you want a second opinion before you start.