Prototype-First vs MVP: What to Build First

Two different questions, two different builds

A prototype exists to remove risk, not to ship. Its audience is your own team. It is judged on whether it proves or disproves an assumption — latency, data quality, integration feasibility — and it is often throwaway. A prototype-first process is a technical instrument.

An MVP exists to learn from real users. Its audience is the market. It is judged on behaviour — activation, retention, payment — and it is meant to ship and last. Building an MVP before the technical unknowns are resolved is how “small first version” turns into a large, late one.

Why teams mix them up

Both get described as “the smallest thing we can build”, so they are merged into one phase. The result is a first release that is simultaneously the market test, the first real integration and the production launch — every kind of risk arriving at once.

The tell is the cost of being wrong. If the answer changes your architecture, you are prototyping. If the answer changes what you build next, you are building an MVP.

The sequence that works

• Prototype the two or three riskiest technical assumptions — hardest integration, messiest data, performance-critical path.
• Build the MVP on top of what the prototype proved, scoped to the smallest set of users that can give a real answer.
• Let MVP usage, not opinion, decide the next increment.
• Keep the same evidence discipline throughout: each decision recorded, each assumption revisited.

What this means for budget and timeline

Prototype-first front-loads a short, cheap phase that usually shortens the total project. It converts the pre-build estimate from a wide range wearing a costume of precision into a plan built on resolved unknowns — the same reason we scope work this way.

An MVP that starts before the technical unknowns are resolved tends to expand, because the discovery that should have happened in a fortnight gets absorbed into the build instead.

When you can skip the prototype

If the build is genuinely well-trodden — a standard internal tool against systems you already know — the unknowns may be small enough to proceed. Prototyping earns its cost when there is real uncertainty: an unfamiliar integration, a hard performance target, or data nobody has cleaned.

So the question is never “do we always prototype?” It is “what do we not know yet, and what would it cost to find out late instead of now?”