How Many Features Should an MVP Have?

The honest short answer is three to five features, and sometimes fewer. But the number by itself is a trap, because two founders can both have "four features" and one has a shippable MVP while the other has a two-month project in disguise. What really determines the size of your build is what each of those features contains and how they interact, not the count on the list. This guide gives you the straight answer, then shows you how to think about features so the count actually means something: what counts as a feature, why each extra one costs far more than it looks, and how to tell whether you have too many or too few.

The short answer: three to five

Across the MVPs we see and build, the ones that ship on time and teach their founder something useful almost always land at three to five core features. That is not a magic number; it is what usually fits inside one clearly defined job done well. Fewer than three and you may not complete a whole job; more than five and you are almost certainly bundling in things that belong to a later version.

Treat five as a ceiling, not a target. If your product's core job can be done with two features, build two. The goal of an MVP is to test one thing in the market as fast as reasonably possible, and every feature past the essential set slows that down and blurs what you are testing.

Why "how many" is the wrong first question

Counting features before you have named the job is like counting ingredients before you know the dish. The right first question is: what single job does this product exist to do? Write it in one sentence, such as "a freelancer uses this to see whether they can pay themselves this month." Only then does the feature count fall out naturally, because a feature earns its place only if the core job cannot happen without it.

This is why the number is downstream of clarity, not a decision you make in the abstract. Once the job is fixed, the must-have features almost pick themselves, and the rest reveal themselves as nice-to-haves. We cover that sorting process in depth in how to prioritize MVP features, and the discipline of writing the job and the boundaries down in how to write an MVP spec.

What actually counts as a feature

Here is where feature counts mislead people. "Users can log in" sounds like one feature. In practice it can mean a signup form, a login form, password reset, email verification, session handling, and an account settings screen. That is six screens and a pile of edge cases hiding inside one innocent line on your list.

So when you count, count the real work, not the label. A feature is not a word on a sticky note; it is everything required to make that capability work for a real user, including the parts nobody demos:

• The happy path - the main screen where the feature does its job.
• The empty state - what the user sees before there is any data.
• The error states - what happens when input is wrong, a payment fails, or the network drops.
• The edge cases - the odd but real inputs that break naive versions.
• The interactions - how this feature touches every other feature you have.

Two founders with "four features" can be miles apart because one counted labels and the other counted the real work. Always count the second way.

A feature-count reality check

To make the compounding concrete, here is how a typical web MVP tends to behave as the feature list grows. The numbers below are illustrative ranges from our experience, not a quote; every product differs. Notice that the relationship is not a straight line.

The jump from the sweet spot to eight features is rarely a small step up in cost. It is often more than double, because the new features do not just add their own work, they multiply the interactions and test surface across everything already there.

The real cost of each extra feature

Founders tend to model features as addition: five features cost X, so six cost X plus a bit. The truth is closer to compounding. Every feature you add has to be designed, built, and tested on its own, and it also has to work correctly alongside every other feature, which means the testing surface grows faster than the list does. Add the sixth feature and you have not added one unit of work; you have added its own build plus its interactions with the other five.

This is the mechanism behind quotes that seem wildly high for "just a few more things." It is also why two similar-sounding products get very different prices, a pattern we unpack in why MVP quotes vary so much. Every feature you cut removes its own work and all of its interactions, which is why cutting is the highest-leverage lever you have on both cost and timeline.

How to know you have too few

Trimming is usually the problem, but it is possible to cut past the bone. You have too few features when a user cannot complete the core job without leaving your product, or when what remains is so thin that no one can tell whether the idea works. An MVP still has to be viable: it must let a real user get the real outcome, even if roughly. If removing a feature means the job simply cannot be done, that feature was never optional.

The test is the word viable. Minimum is about restraint; viable is the floor you cannot go below. If your cut leaves people unable to reach the outcome, you have built a demo, not an MVP.

A worked example: counting a booking tool

Take a simple scheduling tool for independent trainers. The core job is: a trainer sees their week and stops double-booking. Counting the real work, the honest MVP is four features. Set weekly availability. View the week as a schedule. Let a client book an open slot from a link. Send an email reminder. That is a whole job, end to end, and nothing on the list can be removed without breaking it.

Now watch the list try to grow. In-app payments, a trainer directory, group classes, recurring billing, a native mobile app, an analytics dashboard. Each is reasonable. None is needed for a trainer to stop double-booking, so none belongs in version one. Holding the line at four is what makes this buildable at a fixed price, and everything else goes on a parking lot for later. For a fuller gallery of right-sized examples, see what a good MVP looks like.

Feature count and fixed pricing

There is a direct line from a tight feature list to a single, confident price. A team can only quote one fixed number when the scope is bounded, and feature count is the biggest thing that bounds it. A five-feature MVP with clear edges can be quoted with confidence; a "we will figure it out as we go" list cannot, so it gets padded to cover the unknowns.

To see how your list maps to money, run it through the free MVP cost calculator for a market estimate, and read how much an MVP costs in 2026 for the ranges by route. At SquadPrime we build tight, three-to-five-feature MVPs at a fixed price from $4,000, with senior professionals and full code ownership for you. The tighter your list, the more confident the number we can put on it.

FAQ

How many features should an MVP have?

Usually three to five, meaning just enough to complete one core job end to end. The exact count matters less than the discipline: every feature must serve the single job your product exists to do. If your list has a dozen features, most of them belong in a later version, not the MVP.

Can an MVP have just one feature?

Yes, and some of the best ones do. If a single feature completes the core job on its own, one is the right number. The rule is not a minimum of three; it is a maximum of what is truly essential. A focused one-feature MVP usually beats a scattered five-feature one.

Does adding one more feature just add a little time?

No, and this is the most common budgeting mistake. Each feature carries hidden work: its own screens, error states, edge cases, testing, and interactions with every other feature. Features compound rather than add, so going from five to ten can far more than double the build, not just extend it slightly.

How do features affect an MVP's price?

Directly and more than proportionally. Feature count is the single biggest driver of an MVP quote, because each one adds design, build, and test time plus new edge cases. Cutting the list to the true essentials is the fastest way to bring a quote down, which is why a tight scope makes a fixed price possible at all.

All third-party names and trademarks belong to their respective owners and are used for identification only. Any figures reflect our experience building MVPs and typical ranges as of September 21, 2026, and may change at any time. Spotted something outdated or inaccurate? Email talk@squadprime.com and we'll correct it promptly.

Related: What to cut from your MVP · How to prioritize MVP features