Every founder tells me their MVP is "already minimal." Almost none of them are right. Good MVP scoping for software isn't about cutting evenly across a feature list, it's about knowing which pieces are cosmetic and which pieces are load-bearing, and never confusing the two under deadline pressure.

I've scoped MVPs for a retail chain's inventory system and for internal tools at a multifinance company, and the same argument happens every time: someone wants to cut the thing that's actually structural because it "feels" like a nice-to-have, while defending a settings screen nobody will touch in month one. The fix isn't a longer meeting, it's a cut-order hierarchy you apply the same way every time.

Here's the hierarchy I actually use, in the order things should come off the launch list.

Cut First: Anything an Admin Can Do Manually

The first casualties should always be screens that exist to make an internal person's life more convenient, not to serve the actual product experience. Admin dashboards, reporting views, bulk-edit tools, CSV exports with five filter options. These are real features. They are not MVP features, because a human with database access or a spreadsheet can substitute for all of them for the first few weeks of usage.

Concretely, this means:

  • No admin UI for changing user roles, do it with a database update.
  • No analytics dashboard, pull numbers with a SQL query when someone asks.
  • No bulk import tool, load initial data by hand or with a one-off script.

None of this is laziness. It's recognizing that these tools only earn their build cost once usage volume makes manual work painful, and you don't know that volume yet.

Cut Second: Configuration and Customization

The second layer to cut is anything that lets users or admins customize behavior: settings screens, permission matrices, theming, notification preferences. Configurability is expensive to build well and almost always premature, because you don't yet know which settings your actual users will want. Hardcode one sensible default, ship it, and let real usage tell you what needs to become a setting later.

I've seen teams spend two of their eight launch weeks on a notification-preferences screen with granular toggles, for a product that hadn't proven anyone wanted notifications at all yet. That's not scoping discipline, that's building for a hypothetical power user before you've met your first real one.

Cut Third: Automation, Replace With a Manual Workaround

This is the layer people resist cutting the most, because "automation" sounds like the whole point of the product. But automation is a multiplier on a working process, not the process itself. If your MVP's job is to prove that a workflow has value, you can often fake the automated part with a person and a checklist for the first cohort of users, and only build the automation once the workflow itself is validated.

A concrete example: a logistics feature that auto-assigns drivers by zone and load can launch with manual assignment by a dispatcher looking at a simple list. The list needs to exist. The auto-assignment algorithm can wait.

Never Cut: The One Core Loop

Here's the line that should never move, regardless of deadline pressure: the single core loop that makes the product the product. For a marketplace, that's list an item, browse, buy. For a fleet system, that's log a trip, see its status, close it out. Whatever that loop is for your business, it has to work end to end, reliably, on day one, or you don't have an MVP, you have a prototype with a good pitch deck.

The test I use: if you removed this loop, would there be any reason for a user to open the app? If the answer is no, it's core, and it doesn't get scoped down, it gets built properly even if that means the launch date moves.

Never Cut: Data Model Integrity

The second thing that never gets cut is the correctness of your underlying data model, specifically the relationships and constraints that prevent bad data from entering the system in the first place. This is invisible to users and painfully visible to you six months later when you're migrating a database full of orphaned records and duplicate entities because someone decided foreign key constraints were "backend polish" that could wait.

Cutting UI is reversible. Cutting data integrity is not, because every record created under a broken model has to be cleaned or discarded later, often by hand, often under worse time pressure than you're under now. If you're facing that cleanup already, Rewrite or Refactor? Deciding the Fate of a Legacy App walks through how to judge whether a fix is still salvageable or whether you're past that point.

A Simple Way to Run This With Your Team

When your team disagrees about what's in scope, don't debate feature by feature from a flat list. Instead, ask each proposed feature two questions in order:

  1. Can a human substitute for this manually for four weeks without the product failing?
  2. If we cut this, does it corrupt data or break the one thing users came here to do?

If the answer to question one is yes, cut it. If the answer to question two is yes, it stays no matter what else has to go. Everything else is a genuine trade-off worth a real conversation, but these two questions resolve about 80% of scoping arguments before they start.

The Takeaway

MVP scoping for software isn't a smaller version of the full product, it's a bet on which parts of the product are structural and which are convenience. Cut convenience aggressively. Protect the core loop and the data model like they're the only two things that matter, because for the first version, they are.