Prototype vs MVP: where the line is

A prototype answers whether the idea makes sense to a person looking at it. An MVP answers whether real people will use it, and maybe pay, when it is the only thing they have.

Teams mix these words all the time, and it costs them. Someone says prototype, someone else hears product, and three weeks later a throwaway demo is being asked to handle real customers. So let me draw the lines the way I use them at planning.

Four things, four questions

Every one of these exists to answer a single question. If you cannot say the question in one sentence, you are building something without a reason.

• Spike: can we do this at all? It is a short, timeboxed experiment on a technical doubt. Can this payment provider handle partial refunds? Can we read that file format? The output is an answer, not a feature.
• Prototype: does this make sense to the person using it? It simulates the experience. Screens, a fake flow, sample data. People react, you watch where they get lost.
• MVP: will people use it for real, and will it earn its keep? It is the smallest version that does one job end to end for actual users, with real data and real consequences.
• Product: can we keep this running and growing? Now reliability, support, billing, permissions and the boring parts matter as much as the headline feature.

Notice that only the last two need to survive contact with a customer who is not your friend. The first two are allowed to be ugly, partial and wrong.

What to measure at each stage

A spike is measured by whether the doubt is gone. You end with yes, no, or yes but it costs this much. Nothing else counts.

A prototype is measured by behavior in front of you. Do five people finish the task without help? Where do they hesitate? Do they describe the value back to you in their own words? Opinions like "looks nice" are noise. Hesitation is data.

An MVP is measured by repeat use and a commitment of some kind: a signup that comes back, a booking, a card on file, a team that stops using the spreadsheet. One visit tells you about your marketing. The second visit tells you about your product.

A product is measured by retention, cost to serve and how much of the backlog is fixing instead of building. When fixing eats the sprint, you have a product, whether you planned for it or not.

One idea through all four stages

Say a small clinic wants patients to reschedule appointments without calling the front desk. That is the idea. Here is how it moves.

The spike comes first, because the whole thing depends on the clinic's existing calendar system. Can we read free slots from it and write a change back? Two days. The answer is yes for reading, no for writing, so changes will go through a confirmation by the front desk. That shapes everything after, and we learned it before building anything.

The prototype is a clickable flow with five fake patients and invented slots. The PO sits with three real patients and the receptionist. Patients get the flow right away. The receptionist asks who approves the change and how she will see it. That is a question no spec would have raised, and it costs an afternoon.

The MVP is one clinic, one doctor, real appointments. Sign in by phone number, pick a new slot, the request lands in a list the receptionist approves. No reminders, no payments, no second clinic. We watch for two weeks. How many reschedule requests come in, how many calls to the desk disappear, how many patients return to use it twice.

Only after that numbers hold up does it become a product: more doctors, reminders, roles, audit trail, a way to export data. Each of those comes from something the MVP taught us, not from a brainstorm.

When to throw the code away and when to keep it

Spike code goes in the bin. Always. It was written to learn, so it skips tests, error handling and naming. Keep the note that says what you learned, not the code.

Prototype code is usually thrown away too, but with a caveat. If the prototype was a fake that only draws screens, discard it. If it was built on a real stack with a real database, you may keep a good part. The test is whether someone can explain what each piece does and who owns it.

MVP code you keep, or you lie to yourself about the schedule. It will have shortcuts, so write them down as backlog items the same week you take them. Shortcuts with no owner become the product's permanent personality.

A prototype you cannot afford to throw away has already turned into a product, just a bad one.

How a PO decides which one is needed now

Start from your biggest uncertainty, not from your roadmap. If the doubt is technical, spike. If the doubt is whether people understand or want the thing, prototype. If the doubt is whether they will come back and it is worth running, MVP. If the doubt is how to scale something that already works, you are in product territory.

A quick check helps. Ask what decision you will make when the result arrives. If the answer is "nothing changes either way", skip the stage. Teams burn weeks on prototypes for ideas already decided, and weeks on MVPs for questions a conversation with five users would have settled.

Where tooling changes the math

The cost of the early stages used to push people to skip them. Today you can describe an app in a chat in a tool like StarBuild and get a working full-stack version with a database and sign-in, so a prototype with real data costs hours, not sprints. That makes the prototype and the first MVP cheaper. It does not make the questions go away. You still have to know what you are testing, and you still have to decide what to delete.

So write the question at the top of the ticket before you build anything. Then pick the cheapest thing that answers it, and be honest about which label it wears. Most arguments about prototype versus MVP are really arguments about what the team is allowed to promise to customers.