The MVP Misunderstanding
Everyone talks about MVPs. Minimum Viable Product. But most people get it wrong.
They focus on "Minimum" and forget "Viable."
If your app's core function is broken, it delivers no value. That's not an MVP, that's just a broken product.
A real MVP is the simplest version that actually delivers value.
The Two Most Common Mistakes
Mistake 1: Packing in Too Much
"We still need social login. And push notifications. And dark mode. And..."
Three months later, the app still isn't live. Competition has shipped long ago. And you still don't know if anyone even wants your product.
Mistake 2: Delivering Too Little
"Let's just launch with the absolute minimum."
The result: An app nobody understands, that constantly crashes, and delivers zero user value. Negative reviews, frustrated early adopters, burned trust.
The Right Question
Instead of "What can we still add?" or "What can we cut?", the better question:
What's the one assumption we need to validate first?
If that assumption is wrong, everything else is irrelevant.
Example: You're building a fitness app with personalized training. Your assumption: People want AI-generated workouts instead of fixed plans.
Your MVP doesn't need to be perfect. But it needs to test this assumption. That means:
- Personalized workout ✓
- Push reminders ✗ (nice-to-have)
- Social features ✗ (later phase)
- Polished onboarding ✗ (keep it simple for now)
The 4-8-24 Method
For quick validation, I like these timeframes:
4 hours: Proof of concept, just for yourself. Does the core idea work technically? Can you build it?
8 hours: Showable to others. Can be "fake" (Wizard of Oz). The point is people can react.
24 hours (spread over 3 days): Polish and release. Fix bugs, basic UX, App Store ready.
This isn't dogma. Some projects need more time. But it's a useful reality check against feature creep.
What Belongs in an MVP
Must include:
- The core function (working, not perfect)
- Basic error handling
- A way for users to give you feedback
- Enough polish that it's not embarrassing
Can wait:
- Social login (email is fine for now)
- Push notifications (email reminders work too)
- Complex onboarding flows
- Admin analytics dashboard
- Multi-language support
- Dark mode
Should definitely wait:
- Features based on unvalidated assumptions
- Automation for problems nobody has yet
- Scaling optimizations for millions of users
The Wizard-of-Oz Trick
Your MVP doesn't need to automate everything. It just needs to work.
Example: You're building an app for personalized meal plans. The "AI" behind the plans? That's you, at first. By hand.
Users don't care. They get their plan, and you learn:
- What questions do they ask?
- Where do they get stuck?
- What's missing?
Once you know the idea works, you automate. Not before.
The "Embarrassment Rule"
Reid Hoffman (LinkedIn founder):
"If you're not embarrassed by the first version of your product, you've launched too late."
This doesn't mean: Ship bad quality. It means: Accept that version 1 won't be perfect. And that's okay.
The alternative (perfecting for months) is riskier. You're investing time and money in assumptions that might be wrong.
Signs Your MVP Is Too Big
- The project drags on for months
- You're building features "for later"
- You're optimizing things nobody has used yet
- You're discussing edge cases for users who don't exist
- You're building infrastructure for millions of users when you have zero
Signs Your MVP Is Too Small
- Users don't understand what the app does
- The core function is broken or unusable
- There's no single "aha moment"
- You're getting feedback about things that shouldn't even be there
- Users bounce before they can do anything
Practical Example
Idea: An app for dog owners that tracks walks and connects with other dog owners nearby.
Too-big MVP:
- GPS tracking with heatmaps
- Social features with chat
- Dog profiles with photos
- Gamification with achievements
- Notification system
- Premium subscription with extra features
Too-small MVP:
- A map showing your location
- Nothing else
Right-sized MVP:
- GPS tracking of walks (core function)
- Simple list of people nearby (social proof without complex chat)
- Way to send feedback
- No login at first (or just email)
You're testing: Do dog owners want to track walks AND meet others? If yes: expand. If no: pivot.
Conclusion
An MVP isn't a finished product. It's a test.
The question isn't "What would be nice?" but "What do we need to know before we continue?"
And if you're just starting out: Why your first app doesn't need perfect architecture.
Less is often more. Especially at the beginning.
