Prototype or MVP? Building the Wrong One Costs You a Quarter

The words get used interchangeably, including by people who should know better, and the result is a specific and costly confusion: teams build a prototype, put real customers on it, and then spend a quarter retrofitting the things a prototype is allowed to skip.

The distinction is not about size or polish. It is about intent, and it decides what you are allowed to leave out.

What a prototype is for

A prototype answers one question you cannot answer by thinking. Will anyone use this? Can this interaction be made to feel right? Is this technically possible at all?

Because it exists to answer a question, it can cheat at everything else. Hard-coded data, one account, no permissions, no error handling, no deployment story. Those are not flaws; they are the point. A prototype that worries about failure paths is a slow MVP.

The test is whether you could delete it without regret. Memory Master was ours: a small matching game built to try an idea, never positioned as a product. That is a healthy prototype, because nothing depends on it.

If deleting yours would be painful, it is not a prototype any more, whatever you call it. Something is depending on it, and that something is usually users.

What an MVP is for

An MVP is the first version of a product you intend to keep and grow. Minimal describes its scope, not its quality. It has real users, real data and real consequences when it breaks.

So it cannot skip the things a prototype can. Users must not see each other's data. Money must be decided on the server. Failures need handling. It must be deployable without ceremony, because you will deploy it many times. None of that is gold-plating; it is the minimum for something strangers rely on.

What an MVP does skip is scope. Fewer features, one user type instead of four, one payment method, manual steps where automation can wait. How to scope an MVP is about making those cuts without removing the reason anyone would use it.

Which one you need

Answer one question: what are you uncertain about?

• Uncertain whether anyone wants it: prototype, and put it in front of twenty people.
• Uncertain whether it is buildable at all: prototype the risky part only, nothing else.
• Confident people want it, uncertain what exactly to build: prototype a few versions quickly.
• Confident about the problem and roughly what to build: MVP, and treat it as real from day one.
• Already have paying customers waiting: MVP, and resist the temptation to demo your way there.

Most people building a first product need both, in that order. The error is not doing both. It is doing the first and calling it the second.

The drift that costs a quarter

Here is the sequence we see most often, and it never feels like a mistake while it happens.

You build a prototype quickly, often with an AI builder. It demos well. Someone asks to try it, so you give them a login. They tell a colleague. Within a month you have a dozen real users, real data and a system with no permissions model, secrets in the wrong place and no way to deploy without holding your breath.

Nothing was decided. The prototype simply never got thrown away, and now it cannot be, because people depend on it. The work to make it real is the same work it would have been at the start, except now it has to happen under load, with data you cannot lose and users who notice outages. From AI prototype to production maps exactly what that work turns out to be.

How to keep the line clear

Write down, before you start, which one you are building and what question it answers. A sentence is enough, and it prevents months of drift.

Give a prototype an expiry. Two weeks, a decision, then either discard it or commit to the real build. Keep prototype users inside your circle: colleagues, friends, people who know it is an experiment. The moment a stranger depends on it, the clock starts.

And when you move to the MVP, be honest about whether you are keeping the prototype's code. Often you can, and the structure is fine. Sometimes the fastest path is to keep the learning and rewrite the thing, which feels wasteful and usually is not, because what you were buying was the answer, not the code.

If you are not sure which side of the line your project is on, describe it to us and we will tell you plainly, including when the answer is that you do not need us yet.