July 19, 2026·7 min read

prototype vs MVP: which should you build first?

Prototype vs MVP explained: what each proves, what each costs, and how to pick the cheaper mistake before you spend your runway.

If you're about to spend money turning an idea into software, "prototype vs MVP" is the first decision that will save or waste your runway. Founders use the words interchangeably, then build the expensive one to answer a question the cheap one could have settled in a week. This is a practical guide to telling them apart and choosing the cheaper mistake.

The one-sentence difference

A prototype exists to answer a question. An MVP exists to serve customers.

That's it. A prototype is a disposable experiment aimed at your riskiest assumption — is this technically possible? do people actually want it? will they do the thing we need them to do? An MVP (minimum viable product) is a real, if small, product: you launch it, charge for it, support it, and improve it. One is a measuring instrument. The other is a business.

What a prototype proves (and what it costs)

A prototype is scoped to a single hypothesis. You build the thinnest runnable slice that can make that hypothesis fail, put it in front of the smallest audience that can give a real signal, and read the result.

Timeline: days to a couple of weeks.

Cost: low — you are deliberately not building the boring 80% (auth, billing, admin, polish).

Output: evidence and a decision. Not a product.

Fate: often thrown away. That's a feature, not a failure — you paid for the answer, not the code.

Good prototype questions: Can we get the model accurate enough on real data? Will restaurants actually upload their menus? Can we hit sub-100ms on this pipeline? Do users trust an AI to do this at all?

What an MVP proves (and what it costs)

An MVP assumes the core question is already answered "yes" and now asks a bigger one: can this be a business? It's the smallest thing you can charge for that a real customer would use unattended.

Timeline: weeks to months.

Cost: meaningfully higher — real products need the boring 80%.

Output: early revenue, retention data, and a foundation you keep building on.

Fate: it lives. You maintain and grow it.

Building an MVP is the right move once the prototype-stage risks are retired. Doing it before that is the classic runway-killer: you spend three months and your seed round building billing, onboarding, and an admin panel around an assumption that turns out to be wrong.

The expensive mistake: building an MVP to answer a prototype question

The most common failure we see isn't picking wrong — it's not realizing there was a choice. A founder "builds an MVP" that's really just a prototype question wearing a product's clothes. They spend MVP money and MVP time to learn a prototype-sized fact. The fact was cheap; the wrapper around it was not.

Ask yourself: what is the single most likely reason this fails? If the answer is a desirability or feasibility question ("nobody wants it" / "we can't build it well enough"), you have a prototype question — build the prototype. If the answer is a viability question ("people want it and we can build it, but can we make money / keep them?"), you're ready for the MVP.

A simple decision test

Score your idea on three risks:

Feasibility — are you sure you can technically build the core?

Desirability — are you sure people want it badly enough to change behavior?

Viability — are you sure the economics work?

If your biggest uncertainty is #1 or #2 → prototype first. If you're genuinely confident on #1 and #2 and only #3 is open → go MVP. Most pre-seed founders are least sure about #1 and #2 and should almost always prototype first. That's not caution; it's arithmetic. A wrong prototype costs a week. A wrong MVP costs a quarter.

Where "validation as code" fits

At codebefore we build the prototype as runnable code rather than a clickable mockup, because the risks that kill startups usually hide in the parts a mockup can't fake — the integration that doesn't exist, the model that isn't accurate enough, the latency you can't hit. A prototype that can actually fail the way production fails gives you a real answer. And because it's real code, if the answer is "build," your prototype becomes the honest first brick of the MVP instead of landfill.

That's the whole point of separating the two: spend the smallest amount to remove the biggest uncertainty, then graduate to an MVP only once the scary questions are settled. For a deeper look at running that first experiment, see startup validation with code.

TL;DR

Prototype = disposable experiment to answer your riskiest question. Days, cheap, often thrown away.

MVP = smallest real product you can charge for. Weeks–months, more expensive, you keep it.

Build the prototype first when feasibility or desirability is your biggest risk — which, for most early startups, it is.

Building an MVP to answer a prototype question is the most common way to burn a seed round.

If you're staring at "prototype vs MVP" for your own idea and not sure which mistake is cheaper, that's exactly the call we help founders make. Tell us the one thing you most need to prove →

frequently asked questions

What is the difference between a prototype and an MVP?

A prototype is a disposable experiment built to answer your riskiest question — is this possible, does anyone want it? An MVP is the smallest real product you can charge for and maintain. One is a measuring instrument; the other is a business.

Should I build a prototype or an MVP first?

Build the prototype first when your biggest uncertainty is feasibility or desirability — which, for most pre-seed founders, it is. Move to an MVP only once those prototype-stage risks are retired and the main open question is viability.

Why is building an MVP too early a mistake?

Because you spend MVP time and money — often months and a chunk of your seed round — building billing, onboarding, and admin around an assumption a one-week prototype could have tested. You pay product prices to learn a prototype-sized fact.