A founder asks for an MVP, and then lists three pricing tiers, user accounts, a billing page, and a launch date eight weeks out. That describes a minimum marketable product, and settling which one you are building comes before anyone writes a quote.
The MVP vs MMP mix-up costs money in one of two ways. You ship something nobody can pay for, or you overbuild something nobody has asked for yet. I run Pixelean, a UI/UX design and web development agency.
This page gives you the question each of the three answers, what each one must include, and the signals that tell you to move on.
Key takeaways
- MVP, MMP, and MLP each answer a different question. They are not three stairs to climb in order.
- If you plan to charge on day one, you are building an MMP, and it needs billing, onboarding, and support that an MVP skips.
- Lovable is a design budget decision. It can be measured with retention, referrals, and one survey question.
- Sometimes the right first build is none of the three.
MVP vs MMP vs MLP at a glance
What separates the three is the question each one answers. The amount of product follows.
| The question it answers | Who uses it | What must work | What you can skip | How you know it worked | |
| MVP (minimum viable product) | Should this exist at all? | A small group of early adopters who feel the problem | One core job, end to end, and a way to measure return visits | Billing, settings, polish, every second use case | People come back without a reminder and ask what it costs |
| MMP (minimum marketable product) | Will someone pay for it now? | Paying customers who have never met you | The core job and everything on the checklist below | Secondary features, integrations, polish beyond what makes it clear | Strangers pay, reach value without a call, and stay |
| MLP (minimum lovable product) | Why would someone switch from what they use? | Users who already have an alternative | The one or two moments they repeat every day, done better than the incumbent | Breadth and feature parity | Retention flattens and users refer others unprompted |
| Prototype (no product yet) | Do people understand it and want it? | A handful of target users, watched one at a time | A clickable design with nothing behind it | All engineering | They complete the task and ask when they can have it |
The question you cannot answer yet tells you which one to build.
Where the three terms come from
The three terms were never one agreed system. They came from different people solving different problems in different decades, which is why every guide defines them differently.
MVP. Frank Robinson of SyncDev is widely credited with coining the term in 2001. SyncDev still defines an MVP as “the unique product that maximizes return on risk for both the vendor and the customer” (SyncDev). That is a commercial definition, and it reads much closer to what we now call an MMP. Eric Ries gave the term its current meaning. In 2009 he defined it as the version of a new product “which allows a team to collect the maximum amount of validated learning about customers with the least effort” (Lessons Learned, August 2009). The Lean Startup carried that definition everywhere in 2011.
Minimum marketable feature. Mark Denne and Jane Cleland-Huang introduced it in Software by Numbers, published in October 2003 (Pearson). It describes one feature that is worth shipping on its own, not a whole product.
MLP. Brian de Haaff, co-founder of Aha!, writes that he first described the minimum lovable product in 2013 (Brian de Haaff). Some guides credit Henrik Kniberg, but his widely shared post is dated January 2016, and his own term is “Earliest Lovable Product” (Crisp).
Not sure how your current website was built?
Send us the URL. We will tell you what is under it and what that means for your next redesign.
MVP. Should this exist at all?
An MVP, or minimum viable product, exists to produce learning. Revenue is a later question. Its one job is to tell you if a specific group of people has the problem badly enough to change their behavior.
Marty Cagan draws a useful distinction here. He calls the experiment an “MVP Test,” which keeps the experiment separate from the product (SVPG). So an MVP does not have to be software at all.
Forms it can take. A landing page with a waitlist, a concierge service you run by hand for the first few customers, or a “Wizard of Oz” front end, where the screen looks automated and a person does the work behind it.
What it must include. One core job, done end to end, and a way to measure if people come back.
What to skip. Billing, settings, polish, and every second use case.
The common mistake. An MVP that cannot measure anything. If you cannot see who returned, what they did, and where they stopped, you spent the money and learned nothing. I would take a plain MVP with analytics over a handsome one without them.
The classic example is Dropbox, and it holds up when you trace it. The product was hard to demonstrate in prototype form, so Drew Houston recorded a three-minute video of how it was meant to work. In his words, “Our beta waiting list went from 5,000 people to 75,000 people literally overnight” (Eric Ries, The Lean Startup, excerpted in TechCrunch, October 2011). Look at what that number is. It is a waiting list, not a user count, and its entire value was that it showed people wanted the product before it was finished.
For what a validation build costs, see our MVP cost breakdown, and for the build process itself, see our guide to choosing an MVP development company.
MMP. Will someone pay for it now?
An MMP is the smallest product a stranger can buy, use, and get help with, without you in the room. If you plan to charge money on day one, you are building an MMP, and it needs things an MVP never has.
That turns the MMP vs MVP comparison from a question of features into a question of obligations. The moment you take a payment, you owe the customer a working transaction. Before you charge, these eight things have to exist.
- Billing, receipts, and failed payment handling. Cards get declined and cards expire. If nothing retries the charge and tells the customer, you lose paying accounts without anyone deciding to leave.
- Onboarding that reaches first value without a founder on a call. If every new customer needs you to walk them through it, you have a service, and it stops growing at the edge of your calendar.
- Account basics. Sign up, password reset, and change email. They are dull, and a customer who is locked out cannot use what they paid for.
- A support path a customer can find. One visible email address or form is enough. A paying customer with a problem and nowhere to send it will ask the bank for the money back.
- Terms of service and a privacy policy. You are now holding money and personal data. You need written terms for both before the first charge, and a business buyer will ask to read them.
- Basic security that a buyer’s IT team will ask about. This one is for B2B, where you should expect written questions on who can access customer data, where it is stored, and how people sign in.
- Cancellation and refunds. Decide the policy and build the cancel button. A customer who cannot leave cleanly leaves loudly.
- Empty states and error states on the core flow. A new account has no data, so the empty screen is the first screen every customer sees. And when something fails, the product has to say what happened and what to do next.
Some guides call this a minimum sellable product, or MSP, which is the same idea under another name.
If you are charging, the pricing page is part of the product too, and our guide to SaaS pricing page design covers it.
The B2B exception. With one pilot customer, you can build the MMP for that customer first. The checklist shrinks to what their contract requires, and the rest waits for customer number two.
MLP. Why would someone switch?
An MLP is the smallest product that gives someone a reason to leave what they already use. That makes MVP vs MLP a competitive choice, and you only need lovable when the customer already has an alternative.
I avoid the word “delight” because nobody can budget for it. Lovable comes down to five design decisions, and each one is concrete.
- The one or two moments a user repeats every day. Those get the design budget, and everything else gets clear and plain.
- How fast those moments feel.
- The words on the screen.
- What happens when something goes wrong.
- What the screen looks like before there is any data.
When an MLP is a waste. Internal tools, products with no competitor, and anything the buyer is forced to use. In all three, nobody is choosing, so there is nobody to win over.
How to measure it. There are three ways, and all three come from users.
The first is retention that flattens instead of falling. Plot how many of a month’s new users are still active in each later week. A curve that levels off means a group of people has made the product a habit, and a curve that slides to zero means nobody has.
The second is unprompted referrals, meaning new users who say a current user sent them, with no referral program paying for it.
The third is the Sean Ellis question. You ask users how they would feel if they could no longer use the product, and you count the share who answer “very disappointed.” Rahul Vohra of Superhuman describes the benchmark in First Round Review. After benchmarking nearly a hundred startups, Ellis found that companies struggling to grow almost always had fewer than 40 percent answer “very disappointed,” and companies with strong traction almost always had more. Superhuman scored 22 percent the first time it asked (First Round Review, November 2018). The same question is a common test for product-market fit.
They are not stairs
The usual diagram shows three stairs, with the MVP first, then the MMP, then the MLP. I argue the diagram is wrong, and it is expensive, because three stairs means three builds and three invoices.
The right order depends on what you already know about your market, as three scenarios show.
A new category. Nobody has proved demand, and you do not know yet if the product should exist, so start with an MVP and spend as little as you can finding out.
A crowded category. Competitors have already proved demand, so a public MVP answers a question that has been answered. Build an MMP, and put the MLP budget into the one moment where you beat the incumbent.
An existing product. You do not need any of the three, because your customers already pay you. Ship a minimum marketable feature, the smallest addition that is worth something to them on its own.
What to design at each stage is covered in our SaaS UX design best practices guide.
Signals that say move on
Move on when customer behavior changes, whatever the roadmap says. I am not going to give you thresholds, because any number I gave you would be invented. Each signal below is something you can see.
MVP to MMP.
- People ask to pay, pre-order, or sign a letter of intent.
- They come back without being reminded.
- They complain when it breaks. A complaint means the product has become part of their work.
MMP to MLP.
- Churn reasons point to how it feels to use, not to missing features.
- Users compare you to a named competitor, and you lose.
If the churn reasons are about feel, a UX audit finds where.
Signals to stop.
- Praise without return visits. People are being polite.
- Sign-ups without use. The promise worked and the product did not.
- Every active user is someone you chased in person. That measures your effort, and demand is still unproven.
- Customers cancel and name the core job, not the experience. That sends you back to the MVP question.
What each one costs, in one paragraph
The cost follows the checklist, so an MMP costs more than an MVP that proves the same idea, and an MLP adds design time on top. The build path matters more than the label. Our MVP cost breakdown prices each path side by side.
Where Pixelean fits, and where it does not
MVP and MMP. We build validation MVPs and working no-code products on Webflow, Framer, WordPress, and Shopify, when the product fits them.
Coded products. We do the product design and the developer-ready file. Your engineers or your development partner write the code. We do not write the backend, and we do not subcontract it.
MLP. The design work on the repeated moments is what we do daily. It runs on our design plans.
Not a fit. Real-time features, heavy data, offline mobile, regulated data, an app that has to live in an app store, or a product whose entire value is the engineering. No-code stops at those six, so we would be the wrong builder. We also do not build on Bubble.
Frequently asked questions
What is the difference between an MVP and an MMP?
An MVP tests if a product should exist, and an MMP is the smallest version a stranger can pay for and use without your help. The dividing line is money. Once you charge, you need billing, onboarding, support, and terms.
Is an MLP better than an MVP?
No. They answer different questions, so neither is better. In an MLP vs MVP decision, ask if your customer already has an alternative. If they do, lovable design gives them a reason to switch. If nobody has proved demand yet, the MVP comes first.
Can an MVP make money?
Yes. Pre-orders, a paid pilot, or a concierge service all bring in money, and a payment is the strongest evidence of demand you can collect. But once you sell to strangers on a repeating basis, you owe them billing, support, and a way to cancel, and you are running an MMP.
What is a minimum marketable feature?
A minimum marketable feature is the smallest piece of functionality that is worth something to a customer on its own. Mark Denne and Jane Cleland-Huang introduced the term in Software by Numbers in 2003. It applies to products that already exist. You ship one feature, not a whole product.
Is a prototype the same as an MVP?
No. A prototype is a clickable design with no working product behind it. It tests if people understand the product and can complete the task. An MVP delivers the core job for real, even if a person does the work by hand, and it measures if people come back.
The bottom line
Name the question you are answering first. The build follows.
If you do not know that the product should exist, build an MVP and measure who comes back. If you plan to charge strangers, build an MMP and work through the checklist before the first invoice. If customers already have something they use, spend the design budget on the one moment where you can beat it.
And if you cannot say which question you are answering, do not build yet. A prototype and a few conversations cost far less than the wrong product.
Tell us what you plan to build and who pays for it. We will tell you which of the three it is and what it needs before launch. Send us your plan.
The bottom line
All sources read on October 13, 2026.
- SyncDev, “What is a Minimum Viable Product (MVP)?”
- Eric Ries, “Minimum Viable Product: a guide,” Lessons Learned, August 3, 2009.
- Eric Ries, “How DropBox Started As A Minimal Viable Product,” excerpt from The Lean Startup, TechCrunch, October 19, 2011.
- Mark Denne and Jane Cleland-Huang, Software by Numbers, Pearson, published October 8, 2003.
- Brian de Haaff, “Minimum Viable Product vs. Minimum Lovable Product,” October 15, 2020.
- Henrik Kniberg, “Making sense of MVP (Minimum Viable Product) and why I prefer Earliest Testable/Usable/Lovable,” Crisp’s Blog, January 25, 2016.
- Marty Cagan, “Minimum Viable Product,” Silicon Valley Product Group.
- Rahul Vohra, “How Superhuman Built an Engine to Find Product Market Fit,” First Round Review, November 13, 2018.
