Founders · October 8, 2026 · 4 min read

How to scope an MVP: cut it until it hurts

Most MVPs aren't minimal. They start as a sharp idea and grow a settings page, a dashboard, three user roles and a referral program before a single customer has used them. Each addition feels reasonable. Together they double the timeline.

Good scoping is mostly subtraction. Here's a process that works whether you're briefing a developer, prompting an AI builder or building it yourself.

Start with the question, not the features

An MVP exists to answer a question about your business. Write it down in one sentence before anything else. For example: "Will busy clinic managers pay to have no-shows rebooked automatically?"

That sentence becomes your filter. A feature stays only if, without it, you couldn't answer the question. Everything else is a guess about a future you haven't earned yet.

Map one core flow, end to end

Describe the single path a user takes from arriving to getting value. Keep it to a short list of steps. If you can't, the product is probably trying to do too much.

  1. The user signs up with an email.
  2. They connect their calendar.
  3. The app finds cancelled appointments.
  4. It offers the slot to people on a waitlist.
  5. The manager sees which slots were filled.

Build that flow and nothing else first. Every screen that isn't on the path is a candidate for cutting.

Sort every feature into three buckets

List every feature you've imagined, then put each one into a bucket. Be honest. The goal is to make the first bucket uncomfortably small.

  • Must have: the core flow breaks without it.
  • Fake it: needed, but a person can do it by hand for now.
  • Later: nice, but it doesn't help answer the question.

If your must-have list still feels comfortable, cut again. The right scope should make you slightly nervous about how little is in it.

Replace code with manual work

Many features exist to save time at scale. You don't have scale yet. Doing things by hand for your first users is cheaper, faster and teaches you what to automate later.

  • Instead of an admin panel, edit records directly in your database dashboard or a spreadsheet.
  • Instead of automated onboarding, book a short call with each new user.
  • Instead of a billing system, send invoices manually or use a hosted payment link.
  • Instead of a recommendation engine, pick matches yourself.
  • Instead of in-app reports, email a summary each week.

The trick is to keep the manual part invisible to users where it matters, and honest where it doesn't. Customers rarely mind a human in the loop if the result is good.

Features that are almost always "later"

These come up in nearly every early scope, and they almost never decide whether the product works:

  • Social login with several providers, when email login works fine.
  • Native mobile apps, when a responsive web app reaches the same people.
  • Detailed user settings and preferences.
  • Team accounts, invitations and granular permissions.
  • Dark mode, animations and custom illustrations.
  • Analytics dashboards for users, as opposed to simple analytics for you.

Each can be the right call later. Building them now spends time you need for learning.

What you should not cut

Cutting features is healthy. Cutting foundations isn't. Some things are cheap to do right at the start and painful to fix once real users depend on the app.

  • Basic security: access rules on your data and no secret keys in the browser.
  • Backups, so one mistake doesn't erase your early customers.
  • Error tracking, so you know when the core flow fails.
  • A way to contact users, such as a verified email list.
  • Ownership of your code, domain and accounts.

Small and solid beats big and fragile. An MVP that loses data teaches you nothing about demand.

Write it down and freeze it

Put the scope on one page: the question, the core flow, the must-have list, what's being faked, and what's explicitly out. Share it with whoever is building.

Then freeze it. New ideas go on the later list, not into the current build. You can revisit the list once the MVP is in front of users and you have real evidence about what to add.

Deeraf's Build Sprint starts with this exact exercise, turning a long wish list into a fixed scope and a fixed price that ships in weeks, not months.

Keep reading

Want a second pair of eyes on your app?

Book a Tech Check