MVP or MLP: Building First Versions People Keep Using
A minimum viable product proves something works. A minimum lovable product gives people a reason to open it again tomorrow.
Key takeaways
- An MVP tests whether something can work; an MLP is a first version people choose to keep using.
- A lovable first version does one job completely, runs fast on the devices people already have, and uses the team's own words.
- Building an MLP in four weeks means cutting scope harder, not lowering quality: fewer screens, each one finished properly.
- For internal business systems, the first version is never an experiment for the staff who must use it every day.
An MVP (minimum viable product) answers whether something can work. An MLP (minimum lovable product) is a first version that people choose to open again tomorrow, because it does one job completely, runs fast on the devices they already have, and speaks their language. For business systems used daily, we build MLPs, and we get there by cutting scope harder rather than lowering quality.
An MVP is useful for an experiment. But the first version of a business system is not an experiment for the people who have to use it every day. A warehouse picker, a clinic receptionist or a field inspector does not care that the product is “just v1”. They care whether it saves them time today or adds a step.
Why “viable” is not enough for daily tools
“Viable” sets the bar at “it technically works”. That is fine for testing demand. It is a poor bar for software that replaces a process people already know, even a clumsy one.
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. If it is slower, has gaps, or needs a workaround for a common case, people quietly go back to the spreadsheet. After that, winning them back is much harder than getting it right the first time.
This is the main reason first versions fail inside companies. The product was viable. Nobody wanted to use it.
What makes a first version lovable
“Lovable” sounds soft, but in practice it comes down to three concrete things.
It does one job completely, without workarounds
A complete job means the user can start and finish the task inside the product. If a clinic receptionist can book an appointment but has to switch to another tool to send the reminder, the job is not complete.
In a multi-site business, such as the 60-clinic chain in Singapore behind our clinic management project, this matters even more. A gap that costs one receptionist a minute is repeated at every front desk, every day.
It is fast on the devices people already have
Many users in the region work on mid-range Android phones, shared counter PCs or older tablets. A product that feels quick on a new laptop in the office can be painful on those.
Speed also means working when the network does not. On a field inspection app in Kerteh, Malaysia, inspectors needed to capture findings with no reliable signal, so offline use was part of the first version, not a later upgrade.
It speaks the language and terms the team already uses
This is about words as much as languages. If the warehouse says “bin” and the software says “storage location”, every screen needs a small mental translation. Use the team’s own terms for statuses, roles and documents. Where teams work in more than one language, support the ones they actually use.
Smaller scope, higher finish
Building an MLP in four weeks means cutting scope harder, not lowering quality. Fewer screens, each one finished properly.
Functional, scalable, and enjoyable to use. In that order, and all three before launch.
The order matters. Functional comes first: the job must work, with real data, every time. Scalable comes next: the product must cope with the next hundred users and the next year of data without a rewrite. Enjoyable comes third, but it still comes before launch. It is not a phase two polish item.
How the trade-off looks in practice
| Approach | 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 |
Partly finished screens produce feedback about bugs. Finished screens produce feedback about what to build next, which is the feedback you actually want.
What “finished” means for one screen
A checklist we use before calling a screen done:
- It works with real data, including messy and missing values
- Empty states explain what to do next, rather than showing a blank page
- Errors say what went wrong in plain words and how to fix it
- Loading is fast on the slowest device the team uses
- It works on the screen sizes people actually use
- Labels use the team’s own terms
- The person who will use it has tried it and finished their task without help
None of these items are large on their own. Skipping them is what makes software feel unfinished.
How to decide what to cut
Cutting scope is the hard part. A few questions help:
- Which single job, if done well, would make people use this every day?
- Which features exist only because a competitor has them?
- What can stay manual for the first month without hurting anyone?
- Who asked for this feature, and how often would they use it?
Features that fail these questions are not deleted. They go on a written backlog and are reconsidered once real usage shows what people reach for. Our post on what a 4-week AI MVP includes shows how that backlog is built during the sprint.
When a plain MVP is the right call
There are times when “viable” is enough. If you are testing whether anyone wants the product at all, a landing page, a manual service behind a simple form, or a rough prototype can answer that cheaply. Nobody depends on it yet, so polish is wasted.
The line is dependency. Once real staff or customers rely on the product to do their work, they deserve a version that respects their time.
If you are planning a first version and are unsure how small it can be while still being worth using, talk to us about scope. Agreeing that is most of the work.
Frequently asked questions
What is the difference between an MVP and an MLP?
A minimum viable product is the smallest thing that proves an idea can work. A minimum lovable product is the smallest thing people are glad to use again, which means one job done completely rather than many jobs done partly.
Does an MLP take longer to build than an MVP?
Not necessarily. We build MLPs in the same four weeks by cutting more features, so the time saved goes into finishing the remaining screens properly.
When is a plain MVP the better choice?
When you are testing demand and nobody depends on the product yet, such as a landing page or a concierge test. Once real staff or customers rely on it daily, the bar should be higher.