MVP vs prototype: what should a startup build first?

A prototype is a representation of the experience. It might be sketches, wireframes or a clickable set of screens. It is designed to make an idea understandable enough to discuss, test and improve before engineering effort is committed.

An MVP is a working product that people can use for a real purpose. It needs enough design, engineering and operational thinking to deliver the core value reliably, even though many future features are intentionally left out.

Start with a prototype when the most important uncertainty is about the experience itself.

Move to an MVP once the core problem and user journey are clear enough that real behaviour will teach you more than another round of simulated screens. The MVP should make a promise that a user can actually experience: book something, manage something, learn something, sell something or complete another meaningful task.

It does not need every edge case solved forever. It does need honest boundaries, reliable core actions and a way for the team to observe what happens after launch.

For many early-stage products, the sequence is discovery, prototype, MVP, then iteration. Each stage answers a different question: Is the problem worth solving? Do people understand the solution? Will they use a working version? What should improve next?

Skipping straight to a large build can be expensive if the team has not agreed on the first user journey. Staying in prototype mode for too long can also delay the feedback that only real usage can provide. The useful decision is not prototype or MVP forever—it is which uncertainty needs to be reduced next.