Prototype vs MVP: the difference that actually matters
A prototype exists to answer a question and is meant to be thrown away. An MVP is the smallest version real people actually use and depend on, which means it has to be maintained. The difference is not size or polish — it is whether anyone is relying on the thing, and that single distinction decides how it should be built.
Teams get into trouble by building one and treating it as the other, in both directions.
A prototype is a question with code attached
Before you build one you should be able to say what it will tell you. "Will people understand this flow?" is a prototype. "Can this run fast enough on a big dataset?" is a prototype. "A version of the product" is not — it is a project without a question, and it will run until someone gets tired.
Because it is disposable, almost every engineering practice is optional. No tests. No error handling beyond what stops the demo. Hardcode anything not under examination. A prototype that took a week is usually a prototype that answered its question in a day and then got polished for four more.
An MVP is a product with the fat removed
The word minimum does most of the damage here. People hear it as rough, and it means small in scope while still being the real thing. If someone is going to enter data, come back tomorrow and expect it there, you cannot skip the parts that make that true.
- Their data survives. Nothing else matters if the thing forgets.
- Failures are visible rather than silent. Losing work quietly is the fastest way to lose a first user permanently.
- You can fix it without a rewrite. Your first real bug report arrives faster than you expect.
- It does one thing properly. Minimum is about how many things, not how well any of them works.
A useful test: could you charge for this without feeling uncomfortable? Not whether you will — whether the thing is honest enough that you could.
The two ways this goes wrong
Shipping a prototype as an MVP is the common one. It demoed well, someone said ship it, and now real people are storing real data in something built to answer a question. The bill arrives about six weeks later as a rewrite, usually at the least convenient moment.
The opposite is quieter and more expensive. Building an MVP when a prototype would have done means engineering a thing properly before knowing whether it should exist. Every hour spent on error handling for a feature nobody wants is an hour spent well on the wrong problem, and the sunk cost makes it harder to abandon.
Which one you need, in one question
Ask whether anyone will be upset if it stops working tomorrow. If nobody will, you want a prototype and you should build it as cheaply as possible. If someone will, you want an MVP and the shortcuts you were planning are not available.
Most projects want both, in that order. The mistake is skipping the first because the second feels more serious.
Two things neither of them is
A proof of concept is narrower than a prototype: it establishes that something is technically possible at all, usually with no interface, and it answers a question about feasibility rather than about people. If you are unsure whether an approach can work, that is what you want, and it is cheaper than either.
A beta is later than an MVP, not earlier. It is a finished product being tested at wider scale, and calling an unfinished thing a beta to lower expectations mostly works on you rather than on your users. They judge what is in front of them regardless of the label.
What AI generation changes about this
It changes the economics of the prototype far more than the MVP, and that asymmetry is worth understanding.
Prototypes are where generation is strongest: the whole point is that the code is disposable, so the usual objections about maintainability do not apply. Describing an app and getting a working version the same afternoon is exactly the job. Validating an idea by building it covers that in more detail.
MVPs benefit too, but less than the demos suggest, because the hard part of an MVP was never typing the code. It is deciding what to leave out, making failures survivable, and knowing which shortcuts are safe. Generation gets you a working first version quickly and does not make those decisions for you.
There is also a specific trap. A generated app that compiles and loads looks finished, which makes it easier than ever to mistake a prototype for an MVP — the failure mode where everything says success and half the request is missing is precisely what a demo cannot show you.
How to use both without the rewrite
- Write the question down before building a prototype, and stop when it is answered rather than when the thing feels finished.
- Decide in advance that the prototype's code is disposable. Saying it out loud is what stops it quietly becoming the foundation.
- When you move to an MVP, keep the decisions and throw away the code. What was valuable was learning which flow worked, not the file it was in.
- Build the MVP around whatever will hurt most if it breaks — usually storing data and getting it back.
The third point is the one people resist, and it is much easier to accept when the prototype cost an afternoon rather than a month. That is the real argument for building prototypes cheaply: not speed, but being willing to let them go.