MVP vs MLP: building first versions people keep using

Eric Ries published his guide to the minimum viable product (MVP) on 3 August 2009. On 6 May 2013 Brian de Haaff proposed the minimum lovable product (MLP) as a counterpoint: a first version customers love instead of putting up with. Both were writing about customers, who can walk away, and a team that has to use a system every day can’t.

The short answer on MVP vs MLP is dependency. An MVP is for learning whether an idea is worth pursuing, for the least effort, so build one while no team depends on the product yet. An MLP is for people who will rely on it, so build one once staff or customers do their work in it, which for an internal system means the first release. At Sedang Bahagia we build the first release of every custom project as an MLP, inside our 8-week build.

A host restocking dozens of units before the next check-ins, or a doctor taking video calls through a busy shift, doesn’t care that the product is “just v1”, only whether it saves a step today or adds one.

1. MVP vs MLP: one is for learning, the other for daily use

The two differ in who uses them, how finished they need to be and what counts as success:

Aspect	MVP	MLP
Goal	Learn the most about an idea for the least effort	Give people a first version they keep using
Who uses it	Early adopters or a small test group	Everyone who will rely on it daily, even if one site or team goes first
Quality bar	Good enough to give a clear answer	Finished, for the one job it covers
Scope	The least that will test the idea	One job, done completely
Success signal	You learn whether the idea holds	People keep using it without being chased
When to choose it	No team depends on it yet	Staff or customers will rely on it daily

For an internal tool, the MVP’s question usually has its answer before any code exists. The business already knows it needs the system. What it doesn’t know is whether staff will adopt it, and that depends a great deal on how finished the first version feels on day one.

2. Ries and de Haaff both wrote about customers

Eric Ries popularised the minimum viable product in Minimum Viable Product: a guide, published on his blog on 3 August 2009:

The MVP is “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” The same guide adds: “MVP, despite the name, is not about creating minimal products.”

Eric Ries, Minimum Viable Product: a guide, 3 August 2009.

What Ries measures is learning, and he warns against reading “minimum” as small. On our reading, the minimum is the effort spent per lesson, and the product can be whatever size the lesson needs. Build one to find out whether anyone wants the thing at all.

Brian de Haaff introduced the minimum lovable product on the aha.io blog on 6 May 2013, in The Minimum Lovable Product, as a counterpoint: aim for something customers love. His revised version of 18 December 2013, The Minimum Lovable Product (Forget the MVP), puts it in one line:

“You should be thinking about what it will take for customers to love you, not tolerate you.”

Brian de Haaff, The Minimum Lovable Product (Forget the MVP), 18 December 2013.

Customers can leave, and staff rarely choose their tools. A weak first version inside a company can be tolerated for a while and then worked around, with the old spreadsheet open beside it.

MVP vs MLP vs MMP vs SLC

Two more terms turn up in the same searches, and each one measures something different:

Term	Judged on	Source
MVP	What it teaches about the idea	Defined by Eric Ries (2009)
MLP	Whether people keep using it	Introduced by Brian de Haaff (2013)
MMP	The value a release delivers	No single definition or named originator
SLC	Being simple, lovable and complete for one job	Set out by Jason Cohen (2017)

An MMP (minimum marketable product) usually means a release judged on the value it delivers, so the idea fits internal tools too. It extends the minimum marketable feature (MMF), which Mark Denne and Jane Cleland-Huang introduced in their book Software by Numbers.

The Agile Alliance glossary defines an MMF as “a small, self-contained feature that can be developed quickly and that delivers significant value to the user”, and names Minimum Marketable Product as one of its variations. The same entry warns that “MMF is erroneously equated to MVP” and draws the line: “MMF is about delivering value to customers, whereas MVP is about learning more about the ultimate product.”

SLC, short for “Simple, Lovable and Complete”, is the closest of these terms to the MLP described here. Jason Cohen set it out on 22 August 2017 in “I hate MVPs. So do your customers. Make it SLC instead.”, and his complaint about the MVP is the sharper one: “It’s selfish and it hurts customers.”

SLC and MLP put the same test to a first version: whether it’s complete for the one job it covers, for the people who use it every day.

3. “Viable” is the wrong bar once staff depend on the tool

“Viable” sets the bar at enough to learn whether anyone wants the product. That’s the right bar for testing demand. For software that replaces a process people already know, even a clumsy one, it’s too low.

Staff compare any new tool with what they did yesterday. If yesterday was a spreadsheet and a WhatsApp group, the new system has to beat that on the first day. Three things send people back to the spreadsheet:

• the new screen takes longer per record than the old sheet did;
• a case the old sheet handled has no place in the new screen;
• a common case needs a step outside the product, such as a note in the WhatsApp group.

Each of them costs a few seconds or an extra step on every record, and the people doing the work feel it on the first day, long before anyone reads a report on adoption. A booking screen that’s slower than the sheet it replaced is slower on every booking, every day, so the sheet comes back and the team has to win people over a second time. The product still works, and it’s still viable, while the people it was meant for go back to what they had.

The missing case is the easiest of the three to overlook, because it tends to be the awkward one. In the fuel rewards app for a programme in Malaysia, one of the team’s first client projects in 2017, before the company was founded in 2018, members earn points through a payment card they link at sign-up. A member without a card, or one who paid in cash, sends a photo of the receipt instead, and the purchase still earns.

4. Lovable means one complete job, on the users’ devices, in the users’ words

“Lovable” sounds soft. In practice it comes down to three things, and our case studies show each of them.

It does one job completely, without workarounds

A complete job means the user starts and finishes the task inside the product. If one step still happens somewhere else, in another system, a spreadsheet or a chat, someone copies the same details across by hand, and each copy is a chance to get them wrong.

So the first version covers the whole task, from the step that starts it to the step that ends it, even if that means it covers fewer tasks. When a task crosses several desks or systems, a first version can take one of three shapes:

• Link the existing systems. Every task still crosses several screens, so the copying stays.
• Replace one desk at a time. The first desk is done, and the hand-off to the next one is still a copy and paste.
• Put the whole task in one system, every step in one place, for one team or site first.

Only the third removes the copying, because it’s the only one that spans every desk the task crosses.

A complete job can also be a narrow one. The skin teleconsultation app we built in 2020 for a dermatology and aesthetic clinic group in Indonesia covers one job, a consultation that ends in a skincare plan the patient can buy, and every step of it happens in the app. The patient picks a doctor on duty, chooses a video call or a chat, and describes the complaint with photos of the skin before the doctor answers. During the call the doctor builds the recommendation, marking each product mandatory or optional with when to use it. The patient opens it over the video and adds it to the cart without hanging up, and the doctor watches it go from viewed to in cart to paid.

It works on the devices and connections people already have

Test on the devices the users have, which are rarely the ones in the office. Mid-range Android phones, shared counter PCs and older tablets are the likely set, and a product that feels quick on a new laptop can be painful on them. Test the connection the same way, where the work happens and on the network people have there.

The team’s other project from 2017, a hotel booking and loyalty app for a hospitality group in Indonesia, puts each booking into Apple Wallet or Android Pay as a pass that works at the lobby without signal. At the room the phone opens the door over Bluetooth, and key cards stay available at the front desk. In the news app we built in 2018 for an Indonesian news broadcaster, the picture quality of a live stream follows the reader’s connection.

The way through on a weak connection belongs in the first release. If the pass needed signal, a guest at the front desk would be back to reading out a booking code, and the app would add a step where it was meant to save one.

The same rule applies at a desk. A system that runs in the browser starts on the computers a team already has, with nothing to install, so the shared counter PC belongs on the list of devices to test.

It uses the words and languages its users already use

Every screen that uses a different word from the team’s own needs a small translation, every time someone reads it. Use the team’s own terms for statuses, roles and documents. Where the users work in more than one language, support the ones they use.

The bank-backed marketplace for mums we built in Singapore in 2018 is organised by the mum’s stage, in plain words: pregnant, baby 0–12 months or toddler 1–5 years. Her answer sets the headline, the products and the articles on the home page. Each lactation consultant is listed with the languages she speaks, and a mum can filter by language before she joins the queue.

Language is part of finishing the job. A user who can’t follow a step falls back to the old channel, and that’s the work the product was meant to take over.

5. An MLP fits the 8-week build by leaving features out

Our 8-week build gathers the requirements in week 1, shows a clickable prototype in week 2 and revises it with users in week 3. The build runs in weeks 4–7, and deployment and handover take week 8. Four weeks of build hold a few screens done properly or many done partly, and an MLP takes the first option.

Finish doesn’t wait for a phase two. What ships works with real data from day one, so later releases build on it instead of replacing it. An MLP doesn’t take longer than an MVP in our build, then: it takes the same eight weeks and leaves more out.

The figure compares two first versions built in the same time; the numbers are illustrative. One has ten screens, each about 70% done. The other has four, each finished. The missing 30% is the checklist in the next section, and it’s what lets someone finish a task:

The difference shows up in the first weeks of use:

What you see	Ten screens, each 70% done	Four screens, each finished
First-week experience	Users hit gaps and workarounds	Users finish their task
Feedback you get	Complaints about what is broken	Requests for what to add next
Trust in the next release	Low	High
Cost to finish later	Rework across many screens	New screens on a solid base

6. A screen is done when a daily user finishes the task on it without help

Before calling a screen done, check seven things:

• It works with the messy and missing values in the real records as well as the demo set.
• A screen with nothing in it yet says what to do next instead of showing a blank page.
• A failure says what went wrong in plain words and how to fix it.
• It loads quickly on the slowest device the team uses.
• It works at the sizes people have, the shared counter PC and the mid-range phone included.
• Every label uses the team’s own terms.
• Someone who’ll use it every day has tried it and finished the task without help.

None of these is large on its own, and skipping them is what makes software feel unfinished. Together they’re the missing 30% in the figure above. The last one starts before any code: in week 3 of our build, the prototype is revised with the people who will use it.

The host portal and admin console we built in 2021 for a short-stay operations company in Johor, Malaysia, shows the third item at the console’s sign-in. Only company administrators may open the console, and an account without that role is turned away with the reason. When the account belongs to warehouse staff, the alert says so and tells them to ask a super admin for access.

7. Three questions decide what stays in the first version

Cutting scope is the hard part. Name the one job that, done well, would make people use the product every day, then put three questions to each feature:

1. Does the feature serve that one job?
2. Would the product be unusable on day one without it?
3. Could people handle it by hand for the first month without slowing the main task?

A feature makes the first version only if the first two answers are yes. A yes to the third usually means the second answer was no. Features copied from a competitor, or requested by someone who’d rarely use them, get the hardest look.

In our build, the job is named in week 1, with the requirements. For the clinic group it was the consultation that ends in a skincare plan the patient can buy. The clickable prototype of the call, the patient brief and the recommendation followed in week 2 and was revised in week 3, before the build started.

Scope also covers who gets the first version. A consultation needs a patient and a doctor, so the patient apps on phone and web and the doctor app and dashboard went live together. Every restock order in the short-stay host portal is fulfilled by the company’s own team from its centre in Senai, so the admin console that runs orders, stock, crews and repairs went live with the portal.

A pilot is a first release too. The people in it rely on the product for real work from the first day, so it has to be complete for them.

Keep the features that wait on a written backlog, and bring them back once real use shows what people reach for. Hand the backlog over with the source code and the documentation, so whoever builds the next release starts from it.

8. The old spreadsheet tells you whether a first version is working

Four signs show up in the weeks after launch, and none of them needs a survey:

• The old spreadsheet for the main task stops changing once launch week is over.
• People finish the task without asking anyone for help.
• The same people open the product the next day without a reminder.
• Feedback shifts from what’s broken to what to add next.

A usage dashboard is a poor stand-in: it counts logins and misses finished tasks, so it can show adoption while the spreadsheet is still doing the work.

If the spreadsheet is still going, ask the person keeping it what the new system makes them do twice. The answer points at the job that isn’t complete yet.

9. MVP vs MLP: a plain MVP still fits an untested idea

There are times when “viable” is enough. If you’re testing whether anyone wants the product at all, three cheap tests answer that before any system exists:

• A landing page that describes the product and counts who signs up.
• A concierge test, where you deliver the service by hand to a few early customers and watch what they ask for.
• A rough prototype: clickable screens in front of a handful of people, with no code behind them.

No team depends on any of these, so polish buys nothing yet.

The line is dependency. Once staff or customers rely on the product to do their work, build the version they can finish that work in, and keep the plain MVP for the next untested idea. An MLP has a limit of its own: it covers one job, so the second job waits for the second release.

10. Takeaways

Choose by dependency. Build a plain MVP while no team depends on the product, and an MLP once staff or customers do their work in it, which for an internal system means the first release.

The terms’ origin explains the gap. Ries and de Haaff both wrote about customers, who can leave. Staff mostly can’t, so a first version that would count as viable for a customer gets tolerated and then worked around.

Cut features and keep the finish. The same build time holds four finished screens or ten at 70%, and the 30% is the part that lets someone complete a task. We’d rather ship the four and put the other six on the backlog.

Name the one job before the feature list. The three questions in section 7 only work once someone has written the job down, because until then every feature serves something.

The old spreadsheet is the earliest signal. When it stops changing in the second week, the first version is doing its job. When it keeps going, the person keeping it can tell you which job isn’t complete.

The same test applies to web app development and mobile app development: one job done completely, on the devices and connections people have, in the words they use. If you’re unsure how small a first version can be while still being worth using, talk the scope through with our technical lead, who replies within 24 hours.