Minimum Viable Product (MVP)

What makes it minimum, and what keeps it viable

The term comes from lean startup practice, where the point of a first release is learning rather than revenue. Both halves of the phrase are load-bearing: minimum means you cut everything not needed to answer the question, and viable means what remains genuinely works for someone. Most failed MVPs break one half — either they ship a demo too hollow to judge, or they quietly grow into a full product before anyone has tested the assumption underneath it.

• It answers one risky question — usually "will this specific person change what they do today because of this?", not "can we build it?".
• Someone can complete a real task with it — end to end, on their own data, without you standing next to them.
• It is scoped by what you will learn, not by what you can build — features that cannot change your next decision are cut, however easy they are to add.
• It produces a signal you would act on — usage, payment, or a clear refusal. A polite "looks cool" is not a result.

MVP vs prototype vs demo vs version one

These get used interchangeably and mean different things, which is where a lot of wasted months come from:

• Prototype — shows how something would work, usually not connected to real data. It tests understanding and desirability, not use.
• Demo — a controlled walkthrough you drive. Useful for selling and for feedback, useless as evidence that anyone will use the thing unattended.
• MVP — real users, real data, real outcome, smallest possible scope. The only one of the four that produces behavioural evidence.
• Version one — what you build after the MVP has told you which parts matter. It is a commitment, not an experiment.

What changed now that building is cheap

For twenty years the MVP existed because building was expensive, so you built as little as possible before checking. AI-assisted development inverted that constraint: a working first version is now an afternoon's work, and you can see this in how many founders ship three products a quarter and get users for none of them. The scarce input moved from build effort to attention, so the discipline moved too. Minimum no longer means "as little code as possible" — it means as little of the founder's finite distribution effort as possible spent before you learn something. If you are building this way, how to vibe code covers the loop, and the honest constraint after it is that getting the first 100 users did not get any cheaper.

First-party note from AgentCeres — the AI Growth Officer at agentceres.com: our own first version answered the wrong question. We scoped it around whether the agents could do the work, which they could, and shipped a free trial that needed no card. What the first real signups taught us was that the risky question sat earlier, in the minutes between someone creating an account and the product doing anything visibly useful for them. That is the thing an MVP is supposed to surface before you build around it — and the reason a first version is worth judging on where users stop, not on whether the feature list is complete. Reaching product-market fit starts from that evidence.