Your MVP Is Too Big: Scope Discipline for 0 → 1

I've watched a lot of people build a first version, and the ones that fail almost never fail on engineering. They fail because someone spent nine months building the wrong thing, carefully, with good test coverage.

An MVP is not a small product

The most common mistake is treating an MVP as version one of the real thing with fewer features. It isn't. It's an instrument for buying information — specifically, the answer to whichever question would kill the idea if the answer were no.

Once you hold that definition, scope decisions stop being arguments about taste. A feature either helps answer the question or it doesn't. Most don't.

Find the riskiest assumption

Every idea rests on one thing that, if false, ends it. Your job before writing any code is to name it honestly. In my experience it's almost never the technical question:

Founders gravitate to the technical question because it's the one they know how to answer. That's precisely why it's the wrong one to spend nine months on.

Six months isn't an MVP

If the timeline is long enough that the answer arrives too late to act on, you've scoped a product, not an experiment. Four to eight weeks keeps the information useful. Anything quoted at six months is a bet placed before you were allowed to see the cards.

This is also why agencies and MVPs sit awkwardly together: scope is revenue. Nobody whose income depends on the feature list is going to be your best advocate for cutting it. That isn't villainy, it's just incentives — but you should know they're there. It's the main reason my product development work starts with a call about what to leave out rather than what to build.

Features are a cost

Everything you build is something you maintain, explain, support and eventually delete. The feature list you arrive with is almost always wrong — not because you're careless, but because it was assembled before real users existed. That's not a failure, it's just the nature of the exercise.

• Settings pages — you don't know what anyone wants to configure yet.
• Onboarding flows — you have no idea where people get stuck. Watch first.
• Admin dashboards — you can look at the database. There are four users.
• Integrations — build the one someone asked for. Not the grid of twelve.
• Roles and permissions — unless the whole idea is roles and permissions.

Ugly and launched beats polished and hidden

Design matters — and it matters most once you know what you're designing. Before real usage, visual polish is decoration on a guess. The exception is when the product's value *is* the experience, in which case that's your riskiest assumption and you should build exactly that.

The goal isn't to build something impressive. It's to find out whether you're wrong while it's still cheap to be wrong.

The part no MVP fixes

If you can't reach customers, no version of the product solves that. Distribution is the harder half and it's rarely an engineering problem. Before scoping anything, be sure you can get it in front of twenty people whose reaction actually means something. If you can't, that's the thing to solve first — and building software instead is a very enjoyable way to avoid it.

Got an idea and a feature list? Send it over. I'll tell you which one thing tests the assumption — and which two-thirds to cut.