Why You Should Build an MVP Before the Full Product (And I Mean It)
I've seen it happen too many times. A founder, smart, passionate, maybe a little sleep-deprived, spends 18 months and a chunk of their savings building what they believe is the perfect product. Every feature thought through. Every edge case handled. The UI polished to a shine.
Then they launch.
And... crickets.
Not because they lacked talent. Not because they didn't work hard. But because nobody actually wanted what they built, at least not in the way they built it. And by the time they found out, it was too late to pivot without starting from scratch.
This is exactly the problem a Minimum Viable Product (MVP) is designed to prevent.
What Even Is an MVP?
An MVP isn't a crappy version of your product. Let's clear that up right away.
It's the smallest, leanest version of your idea that lets you answer one question: Does this solve a real problem for real people?
That's it. Not "does it look good?" Not "does it have all the features?" Just: does it work, do people want it, and will they use it?
The goal is to learn as fast as possible before spending years building something nobody asked for.
The Real Reasons to Start Small
1. You're Probably Wrong About Something
Not to be harsh, but you are. Every founder is. Your assumptions about who your user is, what they need, how much they'll pay, how they'll find you, at least some of those assumptions are off.
The question is: do you find out now, when you've built a landing page and a basic feature, or do you find out after 2 years and $500k?
An MVP forces you to go talk to users early. It forces feedback. It forces reality.
2. The Market Changes While You're Building
The longer you spend in "build mode," the more the world moves around you. A competitor launches. A trend shifts. What was a gap in the market six months ago might be crowded by the time you're ready to ship.
Speed isn't just about efficiency. It's about staying relevant.
3. You Learn What to Build Next
Here's the thing nobody tells you: users don't always know what they want until they have something to react to. When you put even a rough version in front of them, they'll surprise you. They'll ignore the feature you were most proud of and obsessively use the one you threw in as an afterthought.
That feedback is gold. You can't get it from interviews alone.
Real Companies That Did This Right
Dropbox: A Video Before a Product
Drew Houston didn't build Dropbox first. He made a 3-minute demo video showing how the product would work. That's it. No app. No backend. Just a video.
Overnight, their waitlist went from 5,000 to 75,000 people. That validated the idea before a single line of production code was written. They knew people wanted it. Then they built it.
Airbnb: Air Mattresses and a Website
Brian Chesky and Joe Gebbia couldn't afford rent in San Francisco. So they bought a few air mattresses, put up a basic website offering a "bed and breakfast" in their apartment for a design conference, and rented out space to three strangers.
That janky little website was their MVP. They weren't thinking about building a $75 billion company. They were thinking about whether anyone would actually pay to sleep in a stranger's living room. Turns out, yes. So they kept going.
Zappos: Selling Shoes Without Owning Shoes
Nick Swinmurn wanted to test if people would buy shoes online. Instead of building a warehouse and buying inventory, he walked into local shoe stores, photographed their shoes, listed them on a basic website, and when someone ordered, he went back to the store, bought the shoes at retail price, and shipped them himself.
He lost money on every sale. But he proved the concept. People will buy shoes on the internet. That was worth losing a few dollars per order to find out.
Buffer: A Two-Page Website
Joel Gascoigne built Buffer with a landing page. Not an app, a landing page. It described what Buffer would do (schedule your social media posts) and had a button to sign up.
When people clicked the button, they got a message saying the product wasn't ready yet. But they could leave their email. Hundreds of people did. Joel had his answer. He built the product.
The Mistakes People Make With MVPs
Treating "minimum" as the goal. The point isn't to be lazy. The point is to be focused. Your MVP should still solve the core problem well. If it's buggy and confusing, you'll get bad signal.
Building for too long before shipping. Some people spend 6 months on their "MVP." At that point, just call it a product. An MVP should take weeks, not months.
Ignoring the feedback. You launch, you get feedback, and then you... keep building what you originally planned anyway. This defeats the whole purpose. The feedback IS the product.
Skipping the "viable" part. Minimum doesn't mean broken. It means focused. If it doesn't actually solve the problem in a usable way, you're not learning anything meaningful.
What This Looks Like in Practice
You don't need to build an app to test most ideas.
- Concierge MVP: Do the thing manually, by hand, for the first few users. Figure out what they actually need before automating it.
- Landing page MVP: Describe your product. Put a "Get Early Access" button. See if people sign up.
- Wizard of Oz MVP: Make it look automated. Run it manually behind the scenes. This is what Zappos did.
- Prototype MVP: Build just enough to demonstrate the core interaction. Not production-ready, but real enough to test with.
The Bottom Line
The goal of a startup isn't to build a product. The goal is to find a problem worth solving and figure out how to solve it sustainably.
An MVP is just the fastest way to find out if you're on the right track.
The founders who build great companies aren't the ones who planned the most. They're the ones who learned the fastest.
So stop waiting until it's perfect. Perfect is a myth, and by the time you get there, someone else already shipped.
Start small. Ship early. Learn constantly.
And yes, this blog post itself could be considered an MVP. I shipped it before I had 10,000 examples, a fancy design, or a newsletter. You're reading it. That means it worked.