How Small Should an MVP Be?

Founders ask this question constantly, usually while staring at a feature list that’s grown well past what they meant to build: how small should an MVP actually be? Three screens? Five? Is a login page allowed? Can it skip settings entirely?

The honest answer is that there’s no number waiting to be discovered. Two founders can build MVPs that are both correctly sized — one at 4 screens, one at 14 — because they’re solving different problems for different users. Size isn’t the thing to minimize. It’s the thing that should fall out of one decision: what does a real user need to complete, start to finish, to get value from this product?

This is specifically about breadth — how many features, screens, and flows your MVP contains — not about how deep or capable any single feature needs to be, and not about the broader question of overall scope, which minimum scope for a software MVP: how much is enough covers in more depth. If you’re wrestling with how much a given feature should actually do rather than how many features there should be, that’s the job of a related post on how much functionality an MVP really needs. Here, the focus is narrower: what determines the right count, and why chasing a small number for its own sake usually backfires.

Why “as small as possible” is the wrong target

“Keep it small” is good instinct pointed at the wrong target. Taken literally, it turns into a subtraction exercise — start with everything you can imagine and cut until it feels lean. That approach has a predictable failure mode: it cuts based on what feels optional in isolation, not on what the user’s actual path through the product requires. A screen that looks skippable in a feature list can turn out to be the one place a user confirms a booking, uploads a required document, or sees the price before committing. Remove it to hit a smaller number, and the journey doesn’t get simpler — it gets broken, and the “simplification” just relocates the missing step onto the user, or onto someone on your team doing it manually behind the scenes.

The more useful target isn’t small. It’s complete-and-nothing-more. An MVP sized correctly contains exactly what’s needed for one person to walk through the core journey and come out the other side with the outcome they came for — no extra paths, no unrelated modules, but also no shortcuts through steps the journey actually depends on.

Size the MVP to the journey, not to a target count

Start by writing down the single journey your first users need to complete. Not every journey the finished product will eventually support — the one that proves the product works and delivers value today. For a booking platform, that might be: browse availability, pick a time, enter details, confirm, receive confirmation. For a B2B approvals tool, it might be: submit a request, route it to an approver, approve or reject, notify the requester.

Once that journey is written out step by step, the screen and feature count is mostly a consequence, not a decision. Count the steps that are genuinely load-bearing — the ones the user cannot skip and still complete the journey — and that’s roughly your MVP’s size. A journey with five unavoidable steps needs five screens (or thereabouts) regardless of what any minimalism guideline says. A journey with twelve genuinely necessary steps needs twelve, and shrinking that count for its own sake means cutting something the user will hit a wall without.

This is also why “how small should it be” and “how much functionality does it need” are different questions with different answers. Size is about how many stops are on the map. Functionality is about how well-built each individual stop is. You can have a small MVP where every screen is thin and rough, or a small MVP where every screen is genuinely solid — smallness doesn’t dictate quality, only count.

If you haven’t yet mapped out what that one journey looks like for your product, scoping an MVP around one complete user journey is the practical starting point — everything about right-sizing depends on having that map first.

Arbitrary minimalism vs. journey-driven size

The difference between the two approaches shows up clearly once you compare how each one decides what stays and what goes.

	Size driven by arbitrary minimalism	Size driven by the core journey
Starting question	“How few screens can we get away with?”	“What does one complete journey require?”
Example: booking app	Cuts the confirmation screen to save a step; users aren’t sure the booking went through	Keeps the confirmation screen because the journey isn’t complete without it
Example: B2B approvals tool	Ships without a rejection reason field to keep the form short	Keeps the rejection reason field because the requester needs it to act on the outcome
Example: marketplace MVP	Limits the MVP to browsing only, deferring checkout to “keep it lean”	Includes checkout because browsing without buying isn’t a complete journey, it’s a catalog
What gets cut	Whatever looks removable on a feature list	Only what supports a journey the first users don’t need yet
Result	A product that looks small but leaves users stuck mid-task	A product that’s genuinely no bigger than it needs to be
Risk if wrong	Confuses or blocks real users; support requests fill the gap	Occasionally includes one more screen than a stricter cut would have allowed

Notice the last row. Journey-driven sizing isn’t risk-free — it can end up slightly larger than a hard minimalism target would. But the failure mode is minor (a bit more surface area to build and maintain) versus the failure mode on the other side, which is a product that technically shipped small but doesn’t actually work for anyone trying to use it.

A quick test for any screen or feature in question

When you’re unsure whether something belongs in the first release, ask it these three questions in order:

1. Does the core journey require this step to be completable? If a user hits a genuine dead end without it, it stays.
2. Does removing it just move the work onto the user or your team instead of eliminating it? If yes, you haven’t actually shrunk anything — you’ve hidden the cost.
3. Would a first-time user reasonably expect this step to exist, given what came before it? A confirmation after a purchase, a way to see order status, a password reset link — these are structural expectations, not add-ons.

If something fails all three, it’s very likely safe to defer. If it passes even one, cutting it usually isn’t simplification — it’s a gap dressed up as minimalism. This same three-question filter is also the fastest way to tell the difference between keeping an MVP simple and making it useless — a distinction covered in more depth in a related post on that exact line.

Where size actually shrinks in practice

Correctly sizing an MVP around the core journey usually still results in something smaller than what most founders start out imagining — just not because of an arbitrary rule. It shrinks because:

• Only one journey ships first. Secondary journeys (admin dashboards, referral flows, advanced filtering) wait until the primary journey is proven.
• Edge cases are handled manually at first, not engineered into the product. A support inbox can absorb the 5% of unusual requests while the core flow handles the other 95% automatically.
• Settings and configuration start with sensible defaults, not a settings screen full of options nobody asked for yet.
• Nice-to-have polish (animations, extra states, optional integrations) is deferred, since none of it determines whether the journey completes.

None of these cuts touch the journey itself — they touch everything around it. That’s the difference between disciplined scoping and guesswork: you’re not asking “what can we live without,” you’re asking “what does this journey actually depend on,” and everything else falls away naturally. If you’re earlier in the process and still working out how to trim a rough concept down to something buildable at all, a related post on simplifying an MVP idea before development covers that upstream step; once the journey is mapped, what comes first in MVP design — features, flows, or screens — is a useful next read.

Bringing it back to scope as a whole

Sizing by the journey is one piece of a larger scoping decision — it tells you how wide the MVP should be, but not every judgment call about what’s essential versus deferrable inside that width. For the fuller picture of how much scope is enough for a software MVP overall, see minimum scope for a software MVP: how much is enough. The short version, though, holds on its own: stop asking how small your MVP can be, and start asking what one complete journey for your first users actually requires. The size that follows from that question is the right size — whether that turns out to be three screens or twelve.

Frequently Asked Questions

How small should an MVP actually be?

As small as it can be while still letting a real user complete one full journey from start to finish. That could be 3 screens or 12 — the right number depends on what the journey genuinely requires, not on hitting a minimalism target.

Is there an ideal number of features for an MVP?

No. A booking app and a compliance platform will need very different feature counts to deliver a complete journey. Judging size by a fixed number, rather than by whether the journey is whole, is one of the most common MVP scoping mistakes.

How many screens should an MVP have?

Only as many as the core journey needs to make sense end to end. Cutting a required screen to hit a smaller number usually breaks the journey rather than simplifying it.

What is the difference between MVP size and MVP functionality?

Size is about breadth — how many features, screens, and flows exist. Functionality is about depth — how capable each individual feature is. An MVP can be small in size but still need enough depth in its core feature to be usable.

How do I know if my MVP is too big?

If it includes more than one primary user journey, or features that support edge cases rather than the main path, it is probably oversized. Ask whether each screen or flow is required to complete the core journey — if not, it can usually wait.

How do I know if my MVP is too small?

If real users cannot complete the journey without hitting a dead end, missing step, or manual workaround that undermines trust, the MVP has been cut past the point of usefulness. A journey with a gap in the middle is not smaller — it is broken.

Should every MVP aim for the fewest possible screens?

No. The goal is the fewest screens the journey actually needs, not the fewest screens in absolute terms. Removing a screen the journey depends on just moves the missing step onto the user or onto manual work behind the scenes.