Prototype or MVP: which one first?

Founders use "prototype" and "MVP" as if they were the same thing at different sizes. They are different tools for different questions, and building the wrong one first is one of the more expensive mistakes I see. The short version: a prototype answers "is this the right thing," and an MVP answers "can we deliver it." You need both answers eventually. Which one you need first depends on which of those two questions you are less sure about.

What a prototype is for

A prototype is a fake that is good enough to learn from. It might be clickable screens with real copy, a spreadsheet that does the calculation by hand, or one person doing behind the curtain what software will do later. Nobody pays for it and it does not have to survive contact with a hundred users. Its only job is to put something concrete in front of the people you interviewed and watch what they do with it.

Prototypes are cheap and disposable, which is the whole advantage. When a prototype is wrong, you throw it away and lose a week. When an MVP is wrong, you have code, a database schema, and an engineer's month invested in a direction you have to unwind.

What an MVP is for

An MVP is real software that does one thing for real users, with real consequences when it fails. It exists to find out whether you can actually deliver the value the prototype promised, at a cost that makes sense, and whether people keep using it once the novelty wears off. ShiftFlow was an MVP from day one: it published actual rosters to actual employees, and a mistake would have been a union grievance. There was no prototype stage because the store manager already knew exactly what she needed. The uncertainty was in delivery, so we built.

The one question

Ask yourself: if I built this exactly as I imagine it, and it worked perfectly, would people use it? If your honest answer is "I think so," you need a prototype. You are unsure about the thing itself. If your honest answer is "yes, I've watched them struggle without it, they've asked for it, they're paying for a workaround," then the thing is not the risk, the execution is, and you can go to an MVP.

Dwell is a clear prototype case. The idea, a bank-verified trust score for renters without Canadian credit history, is appealing and unproven. Two interviews have already changed the design and knocked out the pricing model. Building an MVP now would mean writing code around assumptions that are visibly still moving. So the working prototype comes first, the remaining interviews run against it, and the build decision waits. It looks slow from the outside. It is the cheaper order.

Squint went the other way. The problem, that manual site audits take hours so agencies don't do them for cold outreach, was well established. The uncertainty was whether an automated audit could produce something persuasive enough to send to a prospect. That is a delivery question, so Squint went straight to a working tool, used internally on real prospects. What discovery changed was the positioning, from a developer QA utility to a pitch generator, and that reframing happened alongside the build rather than before it.

What each one costs

A prototype engagement at ProductGurus runs three to six weeks and ends with clickable screens using real data, a usability test plan, and a spec your engineers can build from. An MVP is a different order of commitment, usually months, and for client work we hand that stage to your own engineering team with the spec and prototype as the brief. The reason is honest: the expensive questions should be answered before production code exists, and once they are, the build is a known quantity that a good team can execute without us.

The mistake in the middle

The worst outcome is the thing that is neither: a prototype that grew a database and a login system and is now too expensive to throw away, but was never designed to survive real use. It usually happens when a prototype tests well and the team decides to "just keep going." Don't. Take what the prototype taught you, write it down as requirements, and build the MVP properly. The prototype did its job by being wrong cheaply, and it can retire now.

Sources and further reading

• Inspired, Marty Cagan (SVPG). On prototypes as the primary tool of discovery.
• ShiftFlow case study. An MVP that skipped the prototype, and why that was right.
• Dwell case study. A prototype-first product with the build deliberately on hold.