Most MVPs Are Too Big

Most founders don't fail because they built too little. They fail because they built too much.

That sounds backwards. When founders talk about their MVP, the fear runs the other way: What if it looks too simple? What if a competitor has more features? What if we launch and nobody takes us seriously? So they add a little more. Then a dashboard. Then notifications, analytics, admin tools, team collaboration, AI. Somewhere in there the MVP quietly stops being minimal. It becomes the product they hope to have a year from now. Shipped a year too early, half-built, on day one.

On mobile, the trap is worse

I build native mobile apps for a living, and mobile is where I watch this go wrong most often, because mobile punishes overbuilding harder than the web does.

On the web, a bloated v1 is at least cheap to correct. You ship a fix in five minutes. On mobile you don't. You wait for review. You can't hotfix a bad flow the afternoon you notice it. Every extra surface you shipped is now a surface you maintain across two platforms, behind a release cycle you don't fully control.

And mobile invites the worst kind of premature feature. The first version arrives with onboarding flows, a referral system, achievements, social features, an analytics dashboard and three subscription tiers, before a single human has confirmed they'd pay for one tier. Three tiers is a pricing experiment you're running before you've earned the right to run it. Achievements and referrals need backend you haven't validated retention to justify building. None of it is technically hard. That's the trap: it's all buildable, so it all gets built. The problem was never capability. It was sequencing.

The real job of an MVP

The point of an MVP is not to impress anyone. It's to learn. Can you acquire users? Do they understand the problem you're solving? Do they come back? Do they pay? Do they tell someone else?

Those are the only questions that matter at the start. And most features don't help you answer them. They just delay the day you finally have to.

We overbuild because shipping small is uncomfortable

I think oversized MVPs come from a very human place. Building features feels productive. Shipping something small feels like exposing yourself. A bigger MVP gives you the illusion of certainty, so the finish line keeps drifting:

We just need these three features. We should probably add onboarding. We need analytics before we launch. The settings page feels unfinished.

Notice that none of those moves came from a user. They came from discomfort. The roadmap grows to soothe the founder, not to serve the customer.

One feature is never one feature

Features aren't independent. They breed. A notification system needs preferences. Preferences need a settings screen. Settings produce edge cases. Edge cases need support tooling. Support tooling needs permissions. What you scoped as one feature is now five, and the real cost isn't the engineering hours. It's the focus those five things quietly drained from the one question you were supposed to be answering.

The best MVPs are slightly embarrassing

This is the uncomfortable part. Most MVPs that actually worked made their founders wince a little. The design wasn't finished. The onboarding was rough. The feature set was thinner than the deck promised. Some edge cases weren't handled at all.

But they were alive. They were in front of real people, generating real signal. A product that's teaching you something this week beats a more complete product that's still three months from anyone touching it.

A lesson from Setgreet

When I was building Setgreet, I was certain it needed Figma-style version history before launch: every edit tracked, every past version of a flow one click away to restore. It felt non-negotiable.

So I built it.

Nobody ever asked for it.

Not one team I talked to missed it, mentioned it or used it as a reason to say yes.

The learning that actually mattered came from something far less impressive: getting onboarding flows into real apps and watching real teams react.

The moment something is used by real people, the quality of feedback changes completely.

Ideas become observations.

Assumptions become evidence.

That shift was worth more than any version history ever would have been.

A test for what stays in

When you're not sure whether a feature belongs in the MVP, ask one question:

If this feature disappeared, would I still learn the thing I'm trying to learn?

If yes, it doesn't belong yet. That single question can delete half a roadmap. Sometimes more.

Final thoughts

Founders love to ask, what should I add before launch?

The better question is, what can I remove and still learn?

The strongest MVP is almost never the one with the most features. It's the one that reaches reality fastest, because startups don't win by building. They win by learning, and you can't learn from something you haven't shipped.