MVP or prototype — what's the difference and what to build first

"Do I need an MVP or a prototype?" — and half the people use the words as synonyms. They shouldn't: the two answer different questions, live for different lengths of time, and get shown to different people. Mix them up and you either show a raw sketch to paying users, or spend a month polishing something nobody wants. Let's lay it out and, at the end, say clearly where to start.

In short: the difference

• A prototype is a rough draft of the interface to feel out how it works. Buttons may lead nowhere, data may be fake. The goal: test the idea and the feel, often on yourself and a couple of friends.
• An MVP is already a working product with one core function, handed to real users. The goal: test whether it's needed at all and whether people will use it.

A prototype is about "how it looks and feels." An MVP is about "is there demand."

The axes to compare on

| Criterion | Prototype | MVP | |---|---|---| | Main question | how does it work? | is it needed? | | Who you show it to | yourself, friends | real users | | Actually works | not necessarily | yes, at least one function | | Data | fake, "for show" | real | | Lifespan | discarded after the test | grows into a product | | Time to build | hours–a day | days–a couple of weeks | | What it tests | interface and feel | demand and behavior |

Reads like this: a prototype is fast and disposable, an MVP is a bit longer and lives on.

A prototype answers "how," an MVP answers "whether"

Here's the takeaway. These are two different tests, and the usual order is: first a cheap prototype (feel out the interface, catch the obvious flaws), then an MVP (hand it to people, watch the behavior).

The beginner mistake is jumping straight to an MVP, skipping the cheap stage, OR getting stuck in endless prototyping and never showing the product to live people. Both waste time. A prototype keeps you from building something clumsy; an MVP keeps you from building something unwanted. And before any of it, it's worth testing the idea with no code at all.

Who should pick which

No hedging.

Start with a prototype if:

• you have the interface in your head and need to know if it's usable;
• you want to show "here's how it'll look" — to an investor, a friend, yourself;
• you're not sure about the screen flow yet and want to move things around by hand.

Start with an MVP if:

• the idea is clear and the main question is "will people buy / use it";
• you're ready to hand something live to real people;
• you want a real signal — visits, clicks, payments — not "looks cool."

The rule: a prototype for yourself, an MVP for users. In practice, with vibe coding the line blurs — a prototype easily grows into an MVP the same evening, and then into a full product.

FAQ: can I skip the prototype and go straight to an MVP?

Sometimes yes. If the idea is simple and the interface is obvious (a landing page with a button), you don't need a prototype — just build the MVP. A prototype earns its place when the interface is complex or you're not sure how it should work. Don't do a stage for the stage's sake.

FAQ: does an MVP have to involve code?

No. The most honest MVP is often no code at all: a landing page, a form, manual work behind the scenes. The point of an MVP is to test demand as cheaply as possible, not to write a lot of code. If a guess can be tested with a Google Form — test it with a form.