DEV Community: Nikita Sivtsov

MVP vs MLP: How to Pick the Right Launch Strategy

Nikita Sivtsov — Tue, 16 Jun 2026 14:27:08 +0000

Every founder faces the same question before shipping: how much should we build before letting anyone in?

Two frameworks try to answer it. The Minimum Viable Product and the Minimum Lovable Product. They look similar on the surface - both are about shipping small - but they point at completely different problems. Picking the wrong one for your situation is one of the more expensive mistakes you can make early on.

Where these ideas came from

The term MVP was coined in 2001 by Frank Robinson, CEO of SyncDev, who described it as the product that "maximizes return on risk for both the vendor and the customer." Eric Ries then popularized it through the Lean Startup movement, and for a decade it became the default playbook: ship rough, learn fast, iterate.

But somewhere along the way founders started using "MVP" as cover for shipping broken things. Users got tired of being beta testers.

That reaction is where MLP came in. Brian de Haaff of Aha! introduced the term in 2013. His argument was simple: a product people tolerate is not the same as a product they reach for.

What MVP actually means

An MVP is a stripped-down version of a product built to test one hypothesis with real users. Not "let's ship something and see." One specific hypothesis.

The clearest example is Drew Houston with Dropbox in 2008. Instead of building cloud sync infrastructure, he recorded a four-minute demo video showing how the product would work. The waitlist jumped from a few thousand to 75,000 overnight. No working product. Just a demand test.

Airbnb was even rougher. Chesky and Gebbia rented out three air mattresses for $80 each during a design conference in San Francisco. A site, some mattresses, breakfast included. They were not building a hospitality platform - they were checking whether strangers would pay to sleep on a stranger's floor.

"Viable" means the smallest thing that produces a real signal. Signal says yes, you build. Signal says no, you pivot before the costs pile up.

What MLP brings to the table

An MLP is a small first version that people genuinely enjoy using. Not "works fine" - actually enjoy.

De Haaff had a sharp way of putting it: you could eat cat food if you really had to, but you are unlikely to be clamoring for a second serving. Most MVPs are the cat food version of a product. They work. Nobody wants seconds.

An MLP cuts scope just as ruthlessly as an MVP. But the savings get reinvested into what ships. Copy is production-ready. Onboarding feels considered. Every surviving feature gets the full treatment instead of being left half-finished.

The actual comparison

	MVP	MLP
Goal	Test whether anyone wants this	Test whether users will return and tell friends
Mindset	Chase data	Chase delight
Features	Bare minimum to validate a use case	Fewer features, but each one polished
Design/UX	Rough UI, no brand work	Design is core to the build
Time to launch	Weeks	Months or more
Cost	Low	Higher upfront
Best for	Unproven demand, short runway	Validated demand, competitive market
Examples	Dropbox demo video, Airbnb mattresses	Superhuman, Linear

The underlying difference: MVP asks "will anyone use this?" MLP asks "will the people who try it come back and stay?"

When MVP makes sense

MVP is the right call when your biggest unknown is demand. If you are not sure anyone wants the thing, the fastest way to find out is to put a rough version in front of real people and watch what happens. Polish slows down the answer here.

MVP wins in these situations:

Untested markets where you cannot name a single competitor
B2B tools and internal pilots, where buyers tolerate rough edges if the workflow saves time
Short runway, where shipping in six weeks vs six months is the difference between learning and dying
Concierge or Wizard of Oz services, where the back end is humans doing the work manually

One warning attached: do not ship rough into a market where users already expect polish. A consumer photo app launching in 2025 against established players cannot get away with a half-finished onboarding. The bar has been set by someone else, and an MVP that ignores that reads as broken, not scrappy.

When MLP wins

MLP wins when demand is already validated. You know people want a better email client or a better issue tracker. The question is whether they will love yours enough to switch and stay.

Superhuman is the textbook case. Rahul Vohra spent a year on user interviews before writing much product code, then three more years building before public launch. He personally onboarded early users in two-hour sessions. When the product-market fit score sat at 22%, the team did not ship harder - they went back to survey data and doubled down on speed and keyboard shortcuts. Within a year the score hit 58%. Email already existed. The bet was that craft would pull the right users across.

Linear tells the same story from a different angle. By 2025 the company had 15,000 paying customers and a $1.25B valuation on almost no marketing spend, mostly through word of mouth from people who found the product unusually well-built. When management at some companies tried to consolidate onto incumbent tools, the teams using Linear revolted. That kind of loyalty comes from MLP discipline applied from day one.

How to actually choose

Before committing to either approach, four questions help:

What is the bigger risk - demand or retention? Demand risk points to MVP. Retention risk points to MLP.
Has a competitor already set a high quality bar? If yes, shipping rough will read as broken.
How much runway do you have? Under six months forces MVP whether you like it or not.
Can you name your earliest user and what they currently use? If no, go talk to people before picking either approach.

One more honest check: teams sometimes pick MLP because they are afraid of negative feedback on a rough product. And sometimes pick MVP because they do not want to invest in design. Both are bad reasons. Pick the approach that matches what you are actually testing.

If you want to go deeper on this - the full breakdown with more examples and a decision framework is here: MVP vs MLP: Which Launch Strategy Fits Your Product

MVP Architecture Mistakes That Will Ruin Your Life in 6 Months

Nikita Sivtsov — Wed, 27 May 2026 14:54:14 +0000

We've been building products for startups at Pollume for a while now, and there's a pattern that comes up so often it's almost funny. Team moves fast, ships something, gets traction, and then suddenly everything grinds to a halt. Adding a new feature takes two weeks. Fixing one bug breaks three other things. The codebase that felt totally fine at 100 users is quietly falling apart at 1000.
The worst part? Most of these situations were completely avoidable. They trace back to decisions made in the first few weeks of the project, when everyone was excited and moving fast and not really thinking about what happens later.
Here's what I keep seeing, and what actually helps.

Nobody talks about the monolith thing enough
There's this widespread belief in dev circles that microservices are the "correct" architecture and monoliths are just what you do before you know better. So teams reach for distributed architecture on day one, before they have a single paying user, before they even know if the product works.
What actually happens: you spend the first two months wiring services together instead of building product. Debugging becomes a nightmare because a request touches four different services. Deployment is a coordination exercise. And you're doing all of this complexity for a product that might pivot completely in three weeks anyway.
Shopify's Rails monolith handled 173 billion requests on Black Friday 2024. One codebase, massive scale. You do not need microservices on day one, and honestly probably not on day 300 either.
Start with a well-structured monolith where business logic lives in clear, isolated modules. You can extract services later when you actually have a reason to, not because it felt like the right thing to do in month one.

The database schema conversation nobody wants to have
I get it, schema design is boring. Everyone wants to start writing code. But the database is the thing that's hardest to change later, and getting it wrong is genuinely painful.
The mistake I see most often is picking a database based on familiarity and then just... winging the data model. Tables that made sense at first start doing weird things when they have a million rows and no proper indexing. Queries that took 10ms at launch take 4 seconds six months later.
Foursquare had a 17-hour outage in 2010 because their data became unbalanced as the platform grew. Not a code bug, not a server issue. Just a data model that wasn't designed for scale.
Spending an extra day mapping out your actual data relationships before writing code is one of the highest-leverage things you can do early on.

Writing code for problems you don't have yet
This one is a bit uncomfortable to talk about because it's so common. Teams build complex infrastructure for scale they haven't reached. They add caching layers, job queues, and elaborate abstractions to handle traffic spikes that don't exist yet, while the core product is completely unvalidated.
Startup Genome research found that premature scaling causes 74% of startup failures, and failed companies tend to write over three times more code than successful ones. Three times.
The version of this I see most often is teams building features nobody asked for because they seemed like obvious next steps. Meanwhile the one thing the product actually needs to do well is mediocre because the team's attention was spread across ten other things.
Define the one core action your product needs to do really well. Build only that. Measure whether people actually use it before adding anything else. It sounds obvious and it is genuinely hard to stick to.

Technical debt doesn't go away on its own, shockingly
Every team I've ever worked with has said some version of "we'll clean this up after the next release." And then the next release comes and there's a new urgent thing, and the shortcuts from three months ago are now load-bearing walls.
Shopify allocates about 10% of every sprint specifically to technical debt. Not as a special cleanup sprint, not as something that happens when things are quiet. Every sprint, 10%. That's how a 20-year-old Rails codebase still works at massive scale.
Even a small consistent allocation is better than a big cleanup that never happens, which is what "we'll deal with it later" always turns into.

The API stuff that seems fine until it isn't
Inconsistent endpoints, no versioning, internal database structure leaking into API responses — all of these feel like minor sins when you're building fast. They become a real problem when you have mobile clients on old versions, third-party integrations depending on specific response shapes, or a backend you want to refactor without breaking everything downstream.
A few things that cost almost nothing to do correctly from the start: consistent response formats, versioning (/api/v1/ from day one), and keeping what the API exposes separate from what's in the database. Boring stuff that saves weeks later.

I wrote a much more detailed version of all of this on the Pollume blog, including a full breakdown of how to structure your requirements before you write a single line of code: How to Build an MVP: Architecture Guide for 2026
If you've shipped an MVP and hit any of these walls, curious to hear what tripped you up the most. Drop it in the comments.