How Many Features Should an MVP Have? The Real Number

Every piece of MVP advice tells a founder to "keep the feature list small" and then refuses to say how small. That's not caution — it's the writer avoiding a number they'd have to defend. So here's the number: how many features should an MVP have is, in my experience, roughly five to twelve for a first release. Not a feeling, not "it depends" — a real range, and a single rule that decides which five to twelve survive the cut.

I get asked this question in almost every intro call, usually right after a founder shows me a feature list with thirty to fifty items pulled from every stakeholder conversation they've had in the last six months. AI tooling has made that list easier to generate than ever — a one-line idea becomes a fifty-item backlog in seconds — but generating a feature costs nothing, and building and maintaining one still costs real weeks. The temptation to keep more features has gotten worse, not better.

The Number Nobody Will Give You (And Why It's Roughly Five to Twelve)

Founders ask "how many features in an mvp" expecting a formula, and there isn't one tied to your industry or your funding stage. There is one tied to what an MVP is actually for: proving whether users will do the one thing that answers your business question. When a founder asks how many features should an mvp have, they're really asking where the ceiling sits before a first release stops being a test and starts being a bet on everything at once. In my experience, that proof rarely needs more than five to twelve features, and I've rarely seen a first release that needed more than twelve survive contact with its own timeline.

Five is thin but real — one core loop, one payment model, nothing competing for the user's attention. Twelve is full but still coherent — a handful of supporting screens around one demo flow. Past twelve, you're no longer testing a hypothesis; you're building a product roadmap and hoping the market waits for you to finish it. This is the minimum features for mvp question in its most honest form: not "what's the floor", but "what's the ceiling before the list stops being an MVP and starts being scope creep with a due date."

The mvp feature count that matters isn't a target you hit by counting — it's what falls out the other side of one rule, applied honestly to every candidate on the list.

The One Rule That Decides What's In: Does Removing It Break the Demo Flow?

Here's the rule I use, and the only one you need: a feature earns its place if removing it breaks the one demo flow that answers your MVP's core business question. Everything else gets parked, not deleted.

Picture the moment you demo the app — to an investor, your first ten users, your co-founder. Write that flow down: open app, do the first thing, do the second thing, see the result. If a feature isn't a step in that flow, or a support beam directly under one, it doesn't answer how many features should an mvp have — it answers a different, later question. Parking it is not saying no forever. It's saying "not before we know the answer to yes or no."

This rule is why the mvp feature count holds steady across products that look nothing alike. It doesn't care about industry, platform, or how big the founder's ambition is — it only cares whether the feature sits on the one path that proves the business question.

The Range Holds Across Products That Share Nothing Else

The five-to-twelve range isn't a guess — in my experience, it's roughly where the v1 feature count landed on four shipped mobile MVPs I've built, across four different industries and four different business questions: AI Music & Song Generator near the low end, MyCoach toward the higher end, Coin ID Scan and RoomFlash in between. None of the four shared a category, a target user, or a founder — and every one of them landed inside the same range, because every one of them was scoped by the same rule rather than by a feature-list length someone picked in advance.

That's the part worth sitting with: the range isn't something I aimed for going in. It's what a demo-flow-only cut produces, independent of what the product does. A prompt-to-song generator and a coach-client fitness app have nothing in common except that both teams asked "does removing this break the one flow that proves we're right" on every candidate feature, and both landed inside five to twelve. For the business question, the cut list, and what shipping each one proved, minimum viable product examples walks through all four in full.

Four products, four industries, and the same range holds every time: five to twelve features, decided by one rule, not by a founder's gut feeling about what "feels complete." Ask how many features should an mvp have on any one of these four, and the demo-flow rule gives the same kind of answer every time — a short list, defended feature by feature, not assembled by accumulation.

What Almost Always Makes the Cut List — and Why Cutting It Doesn't Mean Deleting It

Some features show up on almost every list I triage, and they almost never survive the demo-flow test — not because they're bad ideas, but because they answer a question that isn't the MVP's question yet:

• Settings and notification granularity — before there's a single user to have preferences.
• Profile customisation — avatars, bios, themes that don't touch the business question.
• Admin tooling beyond a console — a founder needs to moderate or send a push; a polished panel can wait.
• Multiple paywall variants — A/B testing a paywall only makes sense at meaningful weekly traffic.
• Multi-language at launch — validate the business question in one market first.

Every one of these is a legitimate future feature and a wrong answer to how many features should an mvp have right now. Here's the part founders resist: cutting doesn't mean deleting. Parked features go on a list that ships in v2, once the MVP has answered its question with a yes. I've watched a 47-item feature list survive a week-one kickoff completely untouched, and three weeks later the team had shipped none of them — because nobody had told them which seven actually mattered, so every feature fought every other feature for the same three weeks of engineering time. Parking is what lets you say yes to the good idea without saying yes to it this month.

The Cost of Getting the Count Wrong in Either Direction

Getting how many features should an mvp have wrong costs real money in both directions. Miss high, and you burn the runway and the launch date on features that don't move the needle on the one question that matters. Miss low, and you ship fast but prove nothing, because the one feature that would have answered the business question got cut alongside the noise along with everything else. Neither failure looks dramatic in the moment — it looks like a normal week of "let's just add one more thing" or "let's cut that too, we're behind." The demo-flow rule is what stops both, because it gives you language to push back: does removing this break the flow that proves we're right? If the answer is no, it's not an MVP feature — not yet.

That's the real value of having a number and a rule instead of "it depends": the next time an engineer, an agency, or your own excitement wants to add "just one more feature," you have something concrete to test it against, instead of a gut feeling you have to defend from scratch every time. The question of how many features should an mvp have on your specific product gets the same test every time — not a count you hit, but a rule you apply.

Where to Go From Here

If you want the structured process that turns a fifty-item wishlist into an actual demo flow and a triage list, how to scope a mobile MVP in 60 minutes is the sixty-minute exercise that runs the cut for you, phase by phase. If you want to see the full range of what a disciplined feature count looks like across more shipped products, minimum viable product examples walks through real MVPs and what got left out of each one.

How many features should an mvp have is the question you need answered before you sit down to scope one — five to twelve, decided by whether cutting it breaks the flow that proves your business question. If you're staring at a feature list right now and want a second opinion on what survives the cut, tell me about your project, or see the MVP development engagement for how the scoping conversation fits into the build.