What Did You Deliberately Leave Out of Your MVP?
Most MVP posts show what made it into version one.
I’m starting to think the more interesting list is everything that didn’t.
Because deciding what not to build is probably one of the hardest parts of making an MVP.
Especially now.
AI has made implementation so fast that adding another feature barely feels like a decision anymore.
Authentication?
Add it.
Notifications?
Sure.
Team accounts?
Why not.
Analytics?
Might as well.
And suddenly the “MVP” is carrying ten different assumptions at the same time.
More features don’t always mean a better MVP
The point of an MVP isn’t to look complete.
It’s to learn something useful.
If your first version includes too many workflows, features and user types, it becomes harder to understand what actually worked.
Let’s say you’re building a booking app.
You could easily start with:
- staff accounts
- loyalty points
- advanced analytics
- referrals
- reviews
- subscriptions
- multiple payment methods
- custom dashboards
All of those could be useful later.
But maybe version one only needs:
- availability
- booking
- confirmation
That smaller product gives you a much cleaner question:
Will people actually use this booking flow?
If they do, great.
Now you know what to build around.
If they don’t, you’ve learned something before spending time polishing features nobody asked for.
The hard part is often saying “not yet”
I think this is becoming more important as AI development gets faster.
Before, if a feature was going to take a week, you naturally stopped and asked:
Do we really need this?
Now that same feature might take an hour.
And “we might as well add it” becomes very easy.
But cheap to build doesn’t necessarily mean useful to build.
Sometimes the best product decision is:
not now.
Not because the feature is bad.
Just because it doesn’t help answer the first important question.
Smaller products create clearer signals
If you launch a focused MVP and 100 people try it, the behavior is easier to read.
You can see where they stop.
What they understand.
What they keep using.
What they ask for next.
But if version one already has 20 features, the signal gets messy very quickly.
More software can actually make learning harder.
That’s why I’m starting to think MVP quality should be judged partly by what was intentionally left out.
Not just by what got shipped.
So I’m curious
What’s one feature you were sure you needed in version one, but ended up leaving out?
And did you ever come back and build it?

Top comments (0)