What to cut from your MVP

Why it matters

Every feature in an MVP costs three times. Once to design, once to build, and again every time something else changes and it has to be retested. Cutting a feature before the build is the cheapest saving you will ever make on a product, and it is the one founders find hardest, because every feature sounds necessary to the person who thought of it.

The point of an MVP is to find out whether people want the thing and will pay for it. Anything that does not help answer that question is cost and delay. It also makes the answer harder to read. If a product with fifteen features gets a lukewarm response, you cannot tell which feature people wanted, which ones got in the way, or whether the core idea was ever tested. A product with three features gives you a clearer signal, good or bad. This checklist is part of my guide to how to build an MVP, and it pairs with the MVP scoping tool, which asks three questions about each feature and sorts your list into must-have, should-have and later.

The three questions are worth keeping in your head while you read the list:

• Does the first user need it to get value?
• Does it stop them paying you?
• Could you do it by hand for the first few users?

The cut list

Each item below is a common entry in first-version specs, with what to do instead. Not every cut suits every product. If one of these is the core of what you are selling, it stays.

Accounts and sign-in

Sign-in feels like it should be big because every product has it. The basic version is small and well supported by off-the-shelf providers. Everything around it, such as teams, roles and profiles, is where the days go, and almost none of it helps a first user get value.

Admin and back office

Admin is the clearest case of building for yourself instead of your users. For the first few months you are the only admin, and you already have the most powerful admin tool there is: direct access to the database. A screen for approving sign-ups can wait until approving them by hand takes more than ten minutes a day.

Payments and billing

One detail worth knowing if you lean on the customer portal: Stripe's docs say customers can cancel subscriptions that use usage-based billing, multiple products or trial offers in the portal, but cannot update them there. Another reason to keep pricing simple at the start.

Notifications and messaging

Notifications grow quietly. A welcome email becomes a notification system with preferences, digests and a bell icon. For an MVP, list the moments where a user genuinely needs to hear from you, and send a plain email for each. Most products have two or three.

Platform and integrations

Native apps deserve a special mention because they change more than the feature list. They add app store review, separate releases for each platform and, on Google Play, a closed testing period for new developer accounts. A web app that works well on a phone tests the same idea without any of that.

Polish and extras

Polish is the hardest group to cut for anyone with taste, me included. The trick is to separate polish from craft. Craft is clear layout, readable type, sensible spacing and states that tell the user what is happening. It is cheap when designed in from the start and it is what makes a short product feel considered. Polish is the extra layer on top, and it can wait until people are using the thing.

What never to cut

The list above is long on purpose. This one is short, and it does not move.

These are the features AI-built apps most often skip, because a demo works without them. They are also the first things to check before real users arrive. If you have an app that might be missing some of them, the free vibe code health check is a quick way to find out.

Common misses

A few patterns come up again and again when founders cut their own scope.

Cutting the core and keeping the extras. It is easy to cut the hard, central feature because it is hard, and keep the settings page because it is easy. Cut from the edges inward. The core job stays, even when it is the most work.

Building the admin panel first. It feels productive and it is invisible to users. The first users will not care whether you approved them with a button or a database edit.

Treating by hand as unprofessional. Paul Graham's essay on doing things that don't scale describes Wufoo sending handwritten thank-you notes and the Stripe founders asking for a new user's laptop and setting them up on the spot. Manual work at the start is how you learn what the feature should actually do.

Cutting without writing it down. A cut list that only exists in your head comes back as a mid-build change request. Write it down and share it with whoever builds the product, so it holds when a new idea arrives.

Keeping a feature because a competitor has it. Competitors with that feature also have years of users. Your first version needs one reason to switch, not parity.

Fixing the scope without fixing the time. Basecamp's Shape Up calls this the appetite: decide how much time the idea is worth first, then shape the scope to fit it. Without a time budget, cut features tend to creep back in.

Next step

Put your feature list through the MVP scoping tool. It asks the three questions for each feature and gives you a must-have list, a cut list and a one-page summary to hand to whoever builds it. Then run the must-have list through the MVP cost calculator to see what the cuts save in pounds and weeks.

If you want the step-by-step version, read how to scope an MVP in one afternoon. For a SaaS product specifically, the essentials of a SaaS MVP covers what stays in and why. And for what the remaining scope is likely to cost, see what an MVP costs in the UK. If the product is an AI tool, building an AI tool MVP covers the extra costs and testing it needs.