Minimum lovable product: where to spend the love
A minimum lovable product isn’t a more polished MVP. It’s an MVP with its love concentrated in one place. Here’s how a non-technical founder decides where that love goes, and where “lovable” turns into an expensive excuse to over-build.
A founder we worked with last year came to a build kickoff with a list of 41 things the first version “had to feel great.” Smooth animations on every screen. A custom onboarding tour. Light and dark mode. He had read three articles about building a minimum lovable product over the weekend and arrived convinced that “lovable” meant “polished everywhere.” That instinct, more than any technical mistake, is what blows up first builds.
A minimum lovable product (MLP) is the smallest version of a product that people actually like using, not just tolerate. It does one thing so well that users forgive everything still rough around it. The word that trips founders up is “lovable.” They read it as a polish dial to turn all the way up. It’s not. Love is a budget, and the whole skill is deciding where to spend it.
So we built him something other than his list. One screen, the booking flow his customers would touch every single day, was genuinely good: fast, obvious, hard to get wrong. The other forty things were honest and plain. He launched in seven weeks instead of five months. His first ten customers never once mentioned dark mode. They mentioned the booking flow, unprompted, in three of the first five sales calls.
What a minimum lovable product actually is
The term comes from Laurence McCahill at The Happy Startup School, who in 2014 proposed it as the answer to a real problem: the original minimum viable product had curdled into a license to ship something half-broken and call it lean. His fix was to change the question. Instead of “what’s the least we can build and still launch,” ask “what’s the least we can build that someone will love.”
That’s a good correction. But somewhere between 2014 and now, “lovable” got flattened into “more features, nicer design, fuller experience.” That reading is how a non-technical founder ends up with a 41-item must-feel-great list and a five-month build for a product nobody has paid for yet.
The accurate reading is narrower and more useful. A minimum lovable product concentrates its quality. It picks the one moment where a user decides whether this thing is worth their time, and it makes that one moment unmistakably good. Everywhere else, it stays deliberately, visibly minimal. The product isn’t uniformly polished. It’s lopsided on purpose.
Minimum viable product vs minimum lovable product
The MVP vs MLP debate gets framed as polished versus unpolished, and that framing is wrong. Both are minimal. The difference is where the minimalism lives.
A minimum viable product asks how small the scope can be and still teach you something true about demand. Its risk is being so thin it validates nothing. We’ve written before about why most MVPs are too small to validate anything real; that article is about the size of the thing.
A minimum lovable product takes the scope as roughly given and asks a different question: of the things we’re building, which one carries the verdict? Its risk runs the other way. Where an MVP fails by being too thin, an MLP fails by spreading its quality so evenly that nothing stands out and the budget is gone before launch. One is a scoping decision. The other is a concentration decision. You make the MVP call first, then the MLP call inside it.
Put plainly: the MVP question is how much do we build. The MLP question is where does the quality go. Treating them as the same conversation is how founders end up either shipping junk or shipping late.
When “lovable” becomes an excuse to gold-plate
Here is the failure mode nobody in the top search results warns you about, because they’re mostly written for product managers at funded companies, not for a founder spending their own runway.
“Lovable” is the most expensive word in a kickoff meeting. It has no edges. Every feature can be argued into the lovable bucket, because every feature could, in principle, be more delightful. A developer who wants to build the fancy thing, and a founder who wants the product to feel premium, will agree with each other all the way into a blown budget. We’ve watched first builds double in cost not because the scope grew, but because the word “lovable” was applied uniformly and nobody pushed back.
The tell is when polish requests attach to screens users barely see. Animated transitions on the admin settings page. A beautifully designed empty state for a report your first customers won’t run for months. This is craft pointed at the wrong target. Good design is good business, but design spent where no one is looking is just cost wearing a nice outfit.
The discipline of a real MLP is saying “no, that part stays plain” out loud, on purpose, and being able to explain why. If your studio never tells you a part of the product is intentionally rough, you’re not building an MLP. You’re building a maximum lovable product on a minimum budget, and the math doesn’t close.
The love-budget framework: deciding where the love goes
Treat lovability as a fixed budget you’re allocating, not a quality level you’re setting. Before the build starts, run the candidate screens and flows through four questions. The ones that score highest get the love. Everything else gets to be honest and plain.
1. Does the user touch it on day one, or every day? The flow a customer hits in their first session, and the flow they repeat daily, are where verdicts get formed. A booking screen used twenty times a week earns love. A bulk-export feature used once a quarter does not.
2. Is this the moment they decide we’re worth it? Every product has one place where the user silently grades you. For a fintech, the first transaction clearing. For a marketplace, the first match that feels right. Find that moment and overspend there, even if it’s a single screen.
3. Would roughness here read as broken, or just basic? Some rough edges read as “early and focused.” Others read as “these people can’t build software.” A plain settings page is fine. A checkout that feels janky is fatal, because money makes people nervous and jankiness reads as risk. Spend love wherever roughness would be misread as incompetence.
4. Is this where we’re different, or where we’re the same as everyone? Pour love into the part that is your actual reason to exist. The parts that are table stakes, login, a basic dashboard, can look like everyone else’s and lose you nothing.
Most products have one, maybe two flows that win on all four questions. That’s your love budget. Concentrate there. The framework’s real job is to give you, the non-technical founder, the language to defend “leave it plain” against a roomful of people who all sincerely want to make everything nicer.
What this looks like in a real build
The scheduling founder’s MLP had exactly one lovable surface: the booking flow. We spent real design and engineering time on it. Sub-second response, no dead ends, a confirmation that felt solid. Everything behind it, the account settings, the reporting, the team-management screens, was built to work and nothing more. Gray where gray was fine.
His competitors had fuller products. More settings, more polish spread across more screens. They also took longer to ship anything and felt, to a new user, like a lot of okay instead of one thing that was great. Six months after launch he had the budget and the customer feedback to make the reporting screens lovable too, this time knowing exactly which reports people actually ran. That’s the right order: earn the next surface, don’t pre-build it.
A useful gut check before you start: decisions about polish get made when you approve designs, not when code ships. If you don’t know the difference between a wireframe, a mockup, and a prototype, you’ll give cosmetic feedback on the structural stuff and structural feedback on the cosmetic stuff, and your love budget will leak out in the review cycle before a line of code is written.
How to brief a studio for a minimum lovable product
If you’re paying someone to build this, the brief is where the love budget gets set or lost. Three things to put in writing.
Name the one lovable surface explicitly. Not “make it feel premium.” Write: “The booking flow is the one experience that has to be genuinely good. Spend here.” A good partner will push back on your choice or confirm it. A black-box vendor will just say yes and bill you for polish everywhere. Tech partners shouldn’t be black boxes; the back-and-forth about where quality goes is exactly the conversation worth having.
Name what stays plain. This is the part founders skip, and it’s the part that protects the budget. “Settings, reporting, and team management should work correctly and look standard. Do not spend design time making them special in v1.” Putting roughness in writing makes it a decision instead of an accident.
Tie it to the money. The love budget comes out of the same pot as everything else, so know what that pot is. Our pieces on what it costs to build an app and on the build-versus-buy decision that sits upstream of all of this cover the numbers. The short version: every screen you make lovable is a screen you’re paying premium for. One premium surface is affordable on almost any budget. Ten is how a first build quietly becomes a second fundraise.
FAQ
What is the difference between a minimum viable product and a minimum lovable product?
An MVP is about scope: the smallest build that still tests real demand. An MLP is about concentration: taking that scope and making one core experience genuinely good while leaving the rest deliberately plain. You decide the MVP scope first, then decide inside it where the lovability goes. They’re sequential, not competing.
What is a minimum lovable solution?
Same idea, applied to internal or operational tools instead of a customer-facing product. The “lovable” surface is wherever your team spends the most time. A daily ops dashboard earns real care; a config screen used once a month doesn’t. Concentrate the quality where the hours go.
What is a minimum acceptable product?
A minimum acceptable product is the floor: it works and won’t embarrass you, but no part of it is built to be liked. It’s a fine target for a throwaway internal tool. It’s a weak target for anything a customer chooses to use, because “acceptable” rarely earns word of mouth. An MLP costs a little more than a minimum acceptable product and concentrates that extra cost in one place.
What is a minimum lovable product on Amazon?
This usually refers to Amazon’s “working backwards” practice of writing the press release and FAQ before building. It’s a method for forcing clarity on what users will love before you start, which is compatible with everything above. Different tool, same instinct: decide what has to be loved before you spend.
Where should a non-technical founder spend the love first?
On the single flow your customers touch most and judge you by, usually the first real action they take in the product. Make that one thing unmistakably good. Let the rest be honest and plain until customers tell you what to improve next.
A minimum lovable product is not the maximum you can afford to polish. It’s the one thing you refuse to ship rough, surrounded by everything you were brave enough to leave plain. Pick that one thing well, and your first ten customers will tell you whether you picked right.