MVP, MLP, MMP: The Names Don’t Matter. What Changes Under the Hood Does.

The definitions are not the hard part. A minimum viable product tests whether the idea is worth building at all. A minimum lovable product tests whether anyone will choose it over what they already use. A minimum marketable product is the one you can put a price on and support. None of that is in dispute, and none of it tells an engineer what to actually build differently at each stage — which is the question that determines the timeline, the budget, and how much of the first version survives into the second.

Eric Ries’s original framing of an MVP is about validated learning through the fastest possible build-measure-learn loop — not a smaller version of the final product, a faster way to find out if the final product is worth building. That idea holds up. What doesn’t hold up is treating MVP, MLP and MMP as a size ladder, where each stage is just a bigger version of the last one. They aren’t. They are three different answers to the same question: what is this system currently allowed to fake?

What’s allowed to be fake, stage by stage

MVP: a monolith, on purpose. Auth can be a hardcoded check or none at all, because you are testing a hypothesis, not defending a product. The data model is allowed to be wrong — not sloppy, just provisional, because you don’t yet know which fields matter. Caching can be minimal to nonexistent, ops can be manual, everything can run in one environment, and there is no formal SLA because there is no one yet to hold you to one. None of this is cutting corners. It is correctly not paying for answers you don’t have yet, on infrastructure a failed hypothesis would make worthless anyway.

MLP: this is where fakes start getting expensive to keep, and where a different kind of fake becomes unaffordable for the first time. The data model has to become real, because real users are now creating real data inside it, and a schema change after that point means a migration, not an edit. Auth has to become real too, even if narrow — one role, one permission boundary — because the product now has users worth protecting from each other. Basic observability earns its cost here: not full tracing, just enough to know when something broke before a user tells you. And because MLP is the stage where you are asking someone to feel something rather than just validate an assumption, two things an MVP could skip stop being optional: real design-system consistency — three different button styles read as noise at MVP and as carelessness at MLP, exactly when a first impression is being formed — and enough performance headroom that the delightful part of the product isn’t sitting behind a three-second spinner, because a slow delight reads to a user as no delight at all.

MMP: this is where the system stops being allowed to have a single point of failure. Horizontal scalability, because a marketing win that takes the product down under its own load is worse than no marketing win. A defined SLA — a stated number someone can hold you to, not a vibe — because you are now asking a budget owner to bet a real line item on uptime. A security and compliance posture matched to the specific market you are entering, not a generic checklist copied from the last project: a consumer app and a workflow touching health or financial data do not need the same posture, and building the wrong one wastes months in either direction. And a real support and on-call model — a rotation, an escalation path, a stated response time — not you, personally, awake at 2 a.m., which was tenable for a dozen early users and is not tenable for a budget line.

The mistake this framework is actually for preventing

Skip a stage’s real question and you pay for it later at a worse exchange rate. Shipping an MVP’s hypothesis-testing infrastructure with an MLP’s data-model commitments burns time and money getting something durable that a failed hypothesis would have thrown away regardless. Shipping an MMP’s traffic and its SLA promises on an MVP’s auth, observability, and single environment is how a small incident becomes a serious one — nobody could see it coming, no boundary contained it, and the SLA you signed is now a number you are actively missing in front of the customer who asked for it.

The stage isn’t how big the product is. It’s how much of it you’re still allowed to fake.

Naming the stage correctly matters less than being honest about which column you’re actually in — because the column, not the name, is what tells you which fakes are still cheap and which ones just turned into technical debt with your name on it. A three-stage ladder is not a maturity arrow you climb by default; it is a bill of materials, and the expensive mistake is building the wrong stage’s bill for the question you are actually trying to answer.