How to Decide What Not to Build in an MVP

Most founders start scoping an MVP by asking “what should this include?” That’s the wrong first question — or at least an incomplete one. The more useful question, and the one that actually keeps a build small enough to ship, is what should never make the list in the first place.

There’s an important difference here. Trimming a feature list you’ve already written is a budget conversation — you’re looking at ten things on paper and deciding which five survive. Deciding what not to build happens earlier than that. It’s the filter you apply before anything gets written down, so entire categories of “nice to have” never take up space on the list to begin with. Skip this step and you end up trimming a bloated list later under time pressure, which is a much harder conversation to have well.

Why This Decision Happens Too Late

Most scoping conversations start with a brainstorm. Someone lists everything the product could eventually do — admin tools, user roles, notifications, a polished onboarding flow, integrations, a settings page with a dozen toggles — and then the team works backward, cutting items until the budget or timeline fits. That process feels thorough, but it treats every idea as a legitimate candidate that has to be argued out of the plan.

Flip the order instead. Start from the assumption that almost nothing belongs in the first version, and only let a feature in once it’s earned its place. This isn’t about being stingy for its own sake — it’s about protecting the one thing an MVP actually exists to do: give you honest evidence about whether your core idea works, as fast and cheaply as possible.

Every feature you build before that evidence exists is a bet made on a guess. Some guesses turn out fine. Many don’t, and by the time you find out, the budget and the calendar are already gone.

The Exclusion Test

Before anything reaches your MVP scope document, run it through one question:

Does this feature exist to test our core hypothesis, or to make the product feel more complete?

If it’s there to test the hypothesis — the thing you genuinely don’t know yet about whether customers want this — it’s a real candidate. If it’s there because the product would otherwise feel unfinished, unprofessional, or behind competitors, it doesn’t make the first cut. That second category is enormous, and it’s where most MVP budgets quietly disappear.

This test is deliberately blunt on purpose. Early scoping conversations move fast, and a founder or stakeholder can usually justify almost any feature with enough context. A simple, repeatable question is what keeps the conversation from drifting into “well, it would be nice though” — which is true of nearly everything.

Categories That Rarely Belong in a First MVP

Some categories of features show up in almost every early scoping conversation, and almost never belong there. Here’s a practical breakdown of the usual candidates.

Feature category	Why founders want it	Why it usually doesn’t belong in v1
Full admin/settings dashboards	Feels necessary to “manage” the product properly	A handful of hardcoded values or a spreadsheet can run operations manually until you know the product is worth managing at scale
Account management beyond basic auth	Feels incomplete without password reset, profile editing, preferences	Most early users never touch these screens before you’ve learned whether they’ll use the core product at all
“Just in case a future user needs it” features	Feels safer to build flexibility in early	You’re guessing at a future user’s needs instead of testing today’s — flexibility built on guesses is rarely the flexibility you actually end up needing
Animation, transitions, visual polish	Feels more professional and trustworthy	Early users are judging whether the product solves their problem, not whether the button hover state is delightful
Competitor-matching features	Feels risky to launch “behind” a competitor	Copying a competitor’s feature list tests their hypothesis about the market, not yours
Multiple user roles/permissions	Feels like the eventual real structure of the product	One role that completes the core journey is usually enough to learn what you need to learn
Native mobile apps alongside a web build	Feels like coverage you’ll need eventually	A responsive web version validates the same demand for a fraction of the build cost and time

None of these are permanently off-limits — they’re just premature. Once your core hypothesis holds up with real users, several of them stop being guesses and start being obvious next steps.

Admin Screens and Settings: The Quiet Budget Killer

Admin and settings work deserves its own callout because it’s so easy to underestimate. A “simple” admin panel to manage users, content, or configuration can quietly consume as much engineering time as the customer-facing product itself, because it needs its own layout, permissions, and edge-case handling — for an audience of one or two internal people who could just as easily use a spreadsheet or a database query for now.

The same applies to settings screens. A dozen toggles feels like flexibility, but each one is a decision, a UI state, and a support question later. Ask which settings actually change whether your core hypothesis gets tested. Usually the honest answer is none of them.

Account Management Beyond Basic Auth

Login is often necessary — you need to know who’s using the product. But password reset flows, profile editing, notification preferences, and account deletion are a different category. They matter for a product with an established, retained user base. They matter far less for a first version whose entire job is to find out if anyone wants to come back at all.

If a user genuinely can’t complete the core journey without one of these, it earns a place. If it’s there because “a real product has this,” it belongs on the excluded list until you’ve proven there’s a real product to build around.

“Just in Case” Features

This is the hardest category to resist, because it’s dressed up as responsible planning. “We might need multi-currency support later, so let’s build it flexibly now.” “A future enterprise customer might want SSO, so let’s leave room for it.” The problem is that you’re speculating about a future user’s needs using no evidence, while ignoring the present user you can actually learn from today. Flexibility built to serve a guess is rarely the flexibility the real need turns out to require — you end up rebuilding it anyway once actual requirements show up.

Polish and Competitor Parity

Visual polish and matching a competitor’s feature set both come from the same place: wanting the product to feel finished and safe rather than exposed and minimal. That instinct is understandable, but an MVP’s job isn’t to feel finished — it’s to generate honest evidence quickly. If polish or parity work doesn’t change whether that evidence gets collected, it’s not an MVP task yet. It becomes an obvious, well-justified investment later, once you know the core hypothesis holds and there’s a real product worth polishing.

For more on separating what a customer’s task actually needs from what would just be nice to have, what should an MVP include beyond features covers the same discipline from the inclusion side.

Applying the Test to Authentication, a Common Edge Case

Authentication is a good example of a feature that sits right on the line, and it’s worth working through explicitly rather than lumping it in with everything else. Should authentication be included in your MVP is worth reading alongside this exclusion test — it shows how the same “does this test the hypothesis” question applies even to a feature that feels non-negotiable at first glance, and how the answer changes depending on whether your core journey actually requires knowing who the user is.

What to Do With Excluded Ideas

Excluding a feature category doesn’t mean deleting the idea. Keep a short, visible “not now” list separate from your MVP scope — a plain document with the feature and the reason it’s excluded is enough. This does two things. It makes the “no” easier to hold when the same idea resurfaces mid-development, because the idea isn’t lost, just scheduled. And it gives you a ready-made starting point once you actually have usage data to decide what earns a place in version two.

This is a different exercise from how to cut unnecessary MVP features before they increase your budget, which is for trimming what’s already in your plan — pruning a feature list you’ve already written, through a cost lens. This post is about deciding what never goes in the plan at all — the upfront exclusion call, made before a feature ever earns a line on the list. Used together, the two catch feature creep from both directions: before the list exists, and after.

A Simple Way to Run This at Scoping Stage

When you sit down to scope an MVP, try this order instead of the usual brainstorm-then-cut approach:

1. Write the one core user journey your MVP needs to prove out, in a single paragraph.
2. List only what’s strictly required to complete that journey end to end.
3. For every other idea that comes up — and they will keep coming up — run it through the exclusion test before it touches the list.
4. Park anything that fails the test on a separate “not now” document, with a one-line reason.
5. Revisit that document only after you have real usage evidence, not before.

This keeps your MVP scope built from evidence-seeking decisions rather than a list of everything that felt reasonable in the room that day.

Building a Focused MVP From the Start

Deciding what not to build isn’t about under-delivering — it’s about spending your limited build budget on the one thing an MVP is actually for: finding out, quickly and cheaply, whether your core idea holds up with real users. Every admin screen, settings toggle, or polish pass you skip at this stage is budget and time redirected toward getting a genuine answer faster.

Frequently Asked Questions

How do I decide what not to build in an MVP?

Before you write a single feature down, ask whether it exists to test your core hypothesis or to make the product feel more complete. Anything in the second category — admin polish, extra account options, competitor parity features — should be excluded by default rather than evaluated one by one later.

What features should never be included in a first MVP?

Full admin dashboards, account management beyond basic login, settings screens with more than a couple of options, animation and visual polish, and anything built purely to match a competitor's feature list rather than to test your own assumption.

Isn't it risky to leave out features users might expect?

Some risk exists, but it's usually smaller than the risk of never learning whether your core idea works because you spent the budget on features nobody asked for. You can always add expected features once you know real users want the core product enough to ask for more.

How is this different from cutting features that are already in my MVP plan?

Trimming an existing feature list is a budget conversation about features you've already committed to on paper. Deciding what not to build is an earlier, upfront step — deciding which categories of features never get written onto that list in the first place.

What's a simple test for excluding a feature at the scoping stage?

Ask: does this feature exist to test our core hypothesis, or to make the product feel more complete? If it's there to test the hypothesis, it's a candidate for inclusion. If it's there to make the product feel finished, professional, or competitive, it belongs on the 'not now' list.

Does excluding account management and settings screens make the product look unfinished?

It can look minimal, which is different from unfinished. Early users testing a real hypothesis care far more about whether the core task works than whether there's a full profile page. Polish matters once you know people want the product enough to keep using it.

Should I still write down the features I've excluded?

Yes. Keep a simple, visible list of what you're deliberately not building and why, separate from your MVP scope. It stops the same debates resurfacing mid-development and gives you a ready-made list to revisit once you have real usage data.