A prototype is not an MVP
Prototype-versus-MVP guides are everywhere again, and the blur shows up in kickoffs: a polished Figma path labeled "MVP," or a weekend coded demo treated as the first release. A prototype is an instrument for learning — fidelity matched to the open risk, disposable when the answer lands. An MVP is a product: narrow, real, and something people can rely on next month. We have watched RuleCaddie, Veto, and Private Reserve stall when those labels swapped. The artifact looked finished. The question it was allowed to answer did not match the commitment the calendar assumed.
Different jobs, different finish lines
A prototype exists to answer a named question: will people understand this flow, does the citation path hold, can secrecy live where we think it does. Success is a clear keep, kill, or rewrite signal — not a deployable surface. The artifact can be paper, a clickable mock, a Wizard-of-Oz session, or a thin coded probe. What matters is that the instrument matches the risk still open.
An MVP exists to deliver a minimum of real value to real users under production constraints. Narrow is fine. Pretend is not. Within its scope it has to store data, fail honestly, and stay up. The word doing the work is product: strangers depend on it, so corners you cut in a prototype become support load and trust debt.
Mixing the finish lines is the failure mode. Teams celebrate a high-fidelity walkthrough as if demand and feasibility were settled, then discover the seam still unproven. Or they ship a "prototype" to a pilot cohort and inherit production obligations they never scoped — auth, backups, support paths, versioning.
Who touches it decides the rules
If the people using the artifact are colleagues and test participants, prototype rules apply: cut every corner that does not serve the question. Fake data, hard-coded replies, and missing edge cases are allowed when they are labeled. The session ends when the question is answered, not when the UI looks shippable.
The moment strangers depend on it — even a small pilot — MVP rules apply. Idempotent writes, clear failure states, and a path to undo or support are not polish; they are the product. A coded slice that proves a seam can become an MVP later, but only after you rename the commitment and fund the production surface.
We use that gate in practice. A RuleCaddie citation probe that only we run is a prototype. The same loop with golfers trusting answers in the field needs product obligations: refusal when confidence is low, logging that explains a wrong cite, and a keep/kill that is no longer about the demo.
Where the labels get swapped
The common swap is upward: stakeholder review of a clickable flow, then a roadmap item titled MVP. Curiosity and comprehension were tested. Persistence, integrations, and failure modes were not. The schedule inherits product certainty from prototype evidence.
The other swap is downward: a weekend build with real auth and a real database still called a prototype so nobody has to write kill criteria or support expectations. Attachment grows. The throwaway clause quietly dies. Six weeks later the "prototype" is the production path with no rehearsal for rollback.
Neither swap is fixed by climbing fidelity. A prettier Figma is still a prototype. A messier coded demo with users depending on it is already an MVP — underscoped. Name the audience and the question before you name the artifact.
How we choose on a build
If the open risk is understanding, sequencing, or whether the idea is worth building at all, start with a prototype. Time-box it. Write kill criteria before the first commit. Prefer the cheapest rung that can falsify the claim — paper before Figma, wizard before full model wire-up, coded probe only when the seam is the risk.
If the concept is settled and the remaining risk is whether a narrow product holds with real users, build an MVP. Scope it as a product: what is in, what is explicitly out, what "works" means on day one. Do not call it a prototype to soften the commitment.
When both risks remain, sequence them. Prototype the uncertain interaction or seam first. Promote only the answers you trust into an MVP plan. Keep the labels honest in the kickoff doc — the same discipline as not promoting a fake-door CTR into a roadmap or a proposed ADR into a decision.
Questions
- Can a coded prototype become the MVP?
- Only after you rename the commitment. A keep from a prototype authorizes a rewrite or a deliberate hardening pass — auth, failure paths, support, and the production surface you skipped on purpose. Shipping the spike repo as-is usually inherits every corner you cut.
- Is an MVP just a smaller product roadmap?
- No. An MVP is the smallest product that still delivers real value under real constraints. Cutting features without cutting production obligations still leaves you with a product — just a thin one. If nobody can depend on it, you built a prototype with a misleading label.
- How is this different from a proof of concept?
- A PoC proves a technical claim under named constraints, often with little UI. A prototype tests interaction or learning questions with an artifact matched to that risk. An MVP serves users. Spike, PoC, prototype, and MVP are different instruments — stacking the wrong one into the next label invents certainty.
Sources
- Prototype vs MVP — which one you actually need — Prototype answers a question; MVP serves real users. Who touches it changes the rules.
- Prototype vs MVP: choose the right test — Design/learning instrument versus deployable product with production considerations.
- Related: A fake door is not a prototype
- Related: Write the kill criteria before the first commit