Build an MVP when the main uncertainty is whether users want the product. Build a minimum lovable product, which is an MVP with more design and polish in the first session, when you are entering a market with strong incumbents and users will compare you on day one. Skip both and build a fuller first release only when regulation, a platform partner or a hardware dependency makes an incomplete product unshippable. And when the uncertainty is about the problem rather than the product, build something smaller than an MVP: a concierge service, a landing page or a clickable prototype.
Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.
"Do I need an MVP?" is a better question than most founders realise, because the answer is sometimes no. Sometimes the right first build is more polished than an MVP, sometimes it is larger, and sometimes it is not a build at all. This post sets out the three options founders actually choose between, the cases that decide it, and what to build when even an MVP is too much.
What is the difference between an MVP, an MLP and a full product?
| MVP | MLP (minimum lovable product) | Full first release | |
|---|---|---|---|
| Purpose | Learn whether users want it | Learn whether users want it, in a market where they will compare you immediately | Ship a complete product because an incomplete one cannot ship |
| Scope | One journey, three to six features | Same journey and features, with more design, polish and delight in the first session | Several journeys, often multiple roles, the features the market or regulator requires |
| Timeline | 8 to 16 weeks | 12 to 20 weeks | 6 to 12 months |
| Cost | $20,000 to $80,000 (€17,000 to €70,000, £15,000 to £60,000) | $40,000 to $120,000 (€35,000 to €105,000, £30,000 to £90,000) | $120,000 to $400,000 (€105,000 to €350,000, £90,000 to £295,000) |
| Right when | The question is demand and users will forgive roughness | The question is demand and users will not forgive roughness | Regulation, a partner or hardware makes anything less unshippable |
| Wrong when | You are competing with a polished incumbent on their own ground | You are solving an acute problem nobody else solves, and polish delays learning | Demand is unproven. This is how most expensive failures start. |
When is an MVP the right call?
When the main thing you do not know is whether users want the product, and the users have the problem acutely enough to tolerate roughness. Most B2B tools, most products in new categories, most products for underserved segments. These users have a painful problem and no good solution, and they will put up with an unpolished product that solves it. The MVP's job is to find out whether they come back, and polish would delay that answer without improving it. What an MVP is covers the scoping.
When is a minimum lovable product the right call?
When users have alternatives and will judge you against them in the first session. Consumer apps in established categories, products for design-conscious users, anything where the competition is polished and free. Here a rough MVP fails not because the idea is wrong but because users leave before they reach the idea. An MLP keeps the MVP's narrow scope, the same three to six features, and spends more on the design and the first session so that the comparison does not kill it. It is not an excuse for more features. A product with twelve features and polish is a full product with a fashionable name.
The test: would a user who has the problem and sees your rough product say "this is ugly but it solves it" or "this is ugly, I will go back to what I had"? The first is an MVP. The second is an MLP.
When should you skip the MVP and build a fuller first release?
- Regulation. A medical device, a payment product requiring a licence, a product handling data under rules that mandate specific controls. The regulator does not accept version one. Building software for regulated industries covers what that means for scope. Even here, the pre-regulatory validation can be done with something smaller.
- A platform partner's requirements. If distribution depends on a partner who will only integrate a product that meets a checklist, the checklist is the minimum.
- Hardware. A product that ships with a device has a manufacturing cycle that does not allow weekly iteration. The software side can still be built as an MVP, but the whole product cannot.
- A market where the minimum is large. A bank's core system, an airline's booking engine. Rare for startups, common for corporate innovation units.
Outside these cases, "we need the full product first" is almost always a founder who has not scoped. The full first release is how most expensive failures begin, as why most app ideas never ship describes.
When is even an MVP too much?
When you do not yet know whether the problem is real, who has it, or whether they would pay. An MVP tests the product. These questions are about the problem, and they can be answered without building anything:
- Customer interviews. Twenty conversations with people who should have the problem. Free.
- A landing page with a waiting list. Describes the product, asks for an email. A few hundred dollars.
- A concierge version. You do the job by hand for five customers. Costs your time.
- A clickable prototype. Designed screens, tested with ten target users. $5,000 to $15,000 (€4,500 to €13,000, £3,500 to £11,000).
- A pre-sale. Ask for money before the product exists. Free, and the most informative.
How to validate a startup idea before writing code covers each, and MVP vs prototype vs proof of concept covers where a functional prototype fits between these and an MVP.
Which to build
- Problem unproven: interviews, landing page, concierge, clickable prototype.
- Problem proven, product unproven, users forgiving: MVP.
- Problem proven, product unproven, users comparing: MLP.
- Regulation, partner or hardware sets a large minimum: fuller first release, with the validation done beforehand by cheaper means.
How 7L decides
The first phase of the Startupper Program is vision and validation, and its output is often a recommendation not to build yet. When we do build, the choice between MVP and MLP is made in discovery from one question: what will users compare this with in the first session? Full first releases we build for regulated and corporate clients, and we still scope them in phases. If you are unsure which of the four you need, tell us what you know and what you do not, and we will say which question to answer first.
Frequently asked questions
Is a minimum lovable product just a marketing term?
Partly. It was coined to correct the idea that an MVP can be ugly. The useful content is the test: will users compare you with a polished alternative in the first session? If so, the first session needs more design than a classic MVP. The scope should stay the same.
Does an MLP cost much more than an MVP?
Typically 30 to 50 percent more, almost all of it in design and front-end polish. The backend, the features and the timeline are similar. The cost is worth it when the alternative is users leaving before they reach the value.
Can I start with an MVP and make it lovable later?
Yes, and it is the right order when users are forgiving. Polish is cheap to add to a product that works and expensive to add to a product nobody wanted. Start with the MVP unless the first-session comparison test says otherwise.
What if my investors want to see a full product?
They want to see evidence of demand. A full product without users is weaker evidence than an MVP with retention. Show them the plan: what the MVP tests, what the numbers will be, and what the full product becomes once the numbers are in.
I am in a regulated industry. Can I still validate cheaply?
Yes. Interviews, landing pages, pre-sales and clickable prototypes have no regulatory implications. A concierge service may, depending on the activity. Validate the problem by those means, then scope the compliant first release knowing it is wanted.