MVP feature scoping: how to cut 50% of scope without breaking the product

MVP feature scoping means deleting every feature where the answer to "would the product still work without this?" is yes. Sort what's left into must / should / could / won't, ship only the musts, and defer everything else to week 4 or later. Done well, this cuts your initial scope by 40 to 60% without harming the core promise.

The reason most founder MVPs ship late is not bad engineering. It is that the scope you wrote down on day one had three settings pages, two AI features, four onboarding flows, and a notifications system, and you wanted all of them in v1 because each one felt important when you wrote it down. They were not.

The one question that cuts 50% of scope in 10 minutes

Open your feature list. For each item, ask: "Would the product still work without this in week one?"

If the honest answer is yes, the feature is not v1. It is week 4. Or month 3. Or never.

This is uncomfortable because every feature on your list got there for a reason. You added it after a customer call, or because a competitor has it, or because it felt obvious. None of those reasons mean it belongs in v1.

The test is harsher than it sounds. A SaaS tool needs to take a payment and deliver the thing. That is it. Everything else (admin dashboard, settings, profile pages, notifications, role permissions, audit logs, dark mode) is a yes-we-could-cut-it. So cut it.

A useful frame: a v1 is the smallest artifact that lets a real user pay for a real outcome. If your scope contains things that don't directly serve that sentence, those things are not v1.

Must / should / could / won't: the MoSCoW sort

Once you've done the cut question, sort what survives into four buckets. The labels are old but they work:

• Must: the product doesn't function without it. A note-taking app must let you write and save a note. A scheduling tool must let you create and share a link.
• Should: important, but the product still does its core job without it. Search inside notes. Recurring availability.
• Could: nice, will delight a power user, but no one cancels without it. Themes. Export to PDF. Keyboard shortcuts.
• Won't: explicitly out of scope for v1. Write these down. The act of naming them stops them sneaking back in three weeks later.

Musts ship in weeks 1 to 3. Shoulds ship in weeks 4 to 6 based on what your first 10 users actually ask for. Coulds get a parking lot. Won'ts get a public funeral.

Most founders we work with start a planning session with 30 to 40 "features." After the cut question they have 18 to 22. After must / should / could / won't they have 6 to 9 musts. That is your v1.

Bucket	What it means	Ships in	% of typical founder list
Must	Core promise breaks without it	Weeks 1 to 3	20 to 25%
Should	Useful, not load-bearing	Weeks 4 to 6	25 to 30%
Could	Nice, parking lot	Later	30 to 40%
Won't	Explicitly cut	Never (this version)	15 to 20%

The founder feature-attachment trap

Here is the part nobody tells you: most of the features on your day-one list aren't from customers. They're from you.

You added them because you imagined a user using the product, and in that imagination the user noticed the missing thing. So you added it. Then you imagined again, this time with that feature included, and you noticed something else missing. So you added that too. Two hours of solo whiteboarding later, you have a roadmap with 34 items.

The fix is brutal: every feature that wasn't requested by a real human in a real conversation gets demoted by one bucket. Must becomes should. Should becomes could. Could becomes won't.

If you've done customer development at all, you already have an evidence file: 20 to 30 customer-development conversations as a non-technical founder typically generates maybe 8 to 12 features that come up repeatedly. Those 8 to 12 are your real must list. Everything else is your imagination, and your imagination has not paid for anything.

Scope AI features last, not first

Founders building in 2026 keep doing the same thing. They put the AI feature at the top of the v1 list because it's the cool part. Then they spend three weeks on it and ship a product where the AI works and the rest is broken.

AI features should be scoped last. Here's why:

1. The core flow has to work without AI. If your scheduling app's AI assistant breaks, the user should still be able to manually create an event. If it can't, you don't have a scheduling app, you have an AI demo.
2. AI features have unpredictable cost and latency. You don't know your OpenAI / Anthropic bill until real users hit it. Scope around it, not through it.
3. Most AI features turn out to be one well-placed button, not a full agent. The simpler version usually wins.

A clean rule: build the boring CRUD version of every must first. Then layer AI on top of the musts that benefit most. The AI layer is week 5 work, not week 1 work.

The exception is when AI is the actual product (the model output is the deliverable, like an image generator or a research assistant). Then the AI is the core promise and "would the product work without this" returns no. Even then, scope the surrounding flow ruthlessly: one input field, one output, no settings.

Defer the settings page (and the admin panel, and the profile)

Three pages eat more founder MVP time than any other:

1. The settings page. Every toggle a user might want, surfaced as a switch. Don't build it. Pick sensible defaults. If five users in week one ask for a toggle, add that one toggle. If they don't, you saved a week.
2. The admin panel. You don't need an admin UI in v1. You need a Postgres console and a psql connection. Manually adjust accounts. Refund manually via the Stripe dashboard. The admin UI becomes worth building when manual ops cost more than four hours a week.
3. The user profile page. Name and email is enough. Avatar uploads, bios, social links, all unbuilt. Until you have 50 paying users, the profile page is a vanity feature.

Each of these saves three to five engineer-days. Across all three, that's two weeks of v1 timeline back.

The "one persona only for v1" rule

Most founder MVPs try to serve two or three personas at once. The agency owner and the freelancer and the in-house team. The doctor and the patient and the clinic admin.

This roughly triples your scope, because every persona needs its own onboarding, its own permissions, its own views, and its own pricing tier.

Pick one persona for v1. The other personas exist; they get added in months 2 and 3. The single-persona v1 ships in 4 to 6 weeks. The three-persona v1 ships in 16 weeks if you're lucky, never if you're not.

Choose the persona that has the most acute pain, the cleanest budget authority, and the fastest path to paying you. For most B2B tools that's the individual contributor or small team lead, not the buyer or the admin.

Sample scope cut: typical SaaS MVP

Here's a real-shaped example. Founder builds a project management tool for design agencies. Day-one feature list, 31 items:

Auth, social login, password reset, 2FA, profile page, settings page, team management, role permissions, project creation, project templates, task creation, task assignment, due dates, recurring tasks, time tracking, comments, mentions, file uploads, file versioning, notifications email, notifications in-app, notifications Slack, AI auto-summary, AI auto-tagging, AI smart-assign, billing, invoicing, Stripe integration, admin dashboard, analytics, dark mode.

After the "would it still work without this?" cut, 17 survive:

Auth, password reset, project creation, task creation, task assignment, due dates, comments, file uploads, notifications email, billing, Stripe integration.

After must / should / could / won't:

• Must (9): Auth, password reset, project creation, task creation, task assignment, due dates, comments, notifications email, Stripe integration.
• Should (week 4 to 6): File uploads, mentions, billing dashboard, team management.
• Could (parking lot): Time tracking, recurring tasks, project templates, file versioning, in-app notifications, Slack notifications, dark mode, profile page, analytics, admin dashboard.
• Won't (v1): Social login, 2FA, role permissions, AI auto-summary, AI auto-tagging, AI smart-assign, invoicing, settings page.

Nine musts. That's a 4-week build with a senior, or 6 weeks with a mid. The original 31-item list was a 4-month build that nobody would finish.

Comparison: scope-cut techniques by founder situation

Technique	Best for	What it cuts	Risk if overused
"Would the product work without this?"	First-pass cull of any list	30 to 50% of items	Cuts features that matter for retention if used too late
MoSCoW sort (must / should / could / won't)	Sequencing what survives	Reorders 60 to 70% of remaining list	Becomes a planning theater if shoulds never ship
Founder-attachment demotion	Lists generated solo at a whiteboard	Imagination-driven features	Demotes legitimate UX details by accident; balance with customer evidence
Defer AI to last	Any v1 that includes "smart" anything	1 to 2 weeks of AI-first plumbing	None, unless AI is the actual product
One persona only	Multi-sided marketplaces, two-sided tools	50 to 70% of scope	You will need persona 2 in month 3; don't burn the bridge
Defer settings / admin / profile	Almost every B2B SaaS v1	2 to 3 weeks	Manual ops cost adds up around the 50-user mark; rebuild then

Who should do the scoping

Founders. Not engineers. Engineers will ship whatever you put on the spec; they don't know which features are emotional attachments and which are core promises. That's your job.

But once the scope is cut, hand it to an engineer for a 30-minute sanity pass. They will spot the two musts that take three weeks each (auth done from scratch, real-time sync, multi-tenant database design) and tell you to rethink them. Listen. Often the answer is to swap "real-time sync" for "manual refresh button" and recover a full week.

The Cadence engineers we work with do this scope review in the first 60 minutes of a booking, before they write a line of code. The 48-hour free trial is enough to surface every scope problem your spec is hiding, which is why most founders use the trial as a scope review even when they intend to do the build themselves.

What to do this week

1. Open your feature list. Write down every item, no judgment.
2. Run the cut question on each: "Would the product work without this in week one?" Delete every yes.
3. Sort what's left into must / should / could / won't.
4. Pick one persona. Mark anything serving a different persona as won't.
5. Move AI features to should or could. Build the boring version first.
6. Defer the settings page, admin panel, and profile page to month 2.
7. Get a sanity pass from an engineer before you start building. A clear engineering job spec with a tight must list is what gets you a real estimate, not a 31-item wishlist.

If your must list still feels too long after this, you haven't cut enough. The discipline is to keep cutting until the answer to "can a single senior ship this in 4 weeks?" is yes. The math: a senior on Cadence at $1,500/week ships roughly 8 to 12 medium-complexity features per month, real-world, with AI tooling in the loop.

If you want a second opinion on whether your v1 scope is buildable in your budget, a bootstrap startup engineering playbook walks through the realistic stack and timeline trade-offs before you commit to anything.

When you're ready to book the build, Cadence shortlists vetted engineers in 2 minutes and the 48-hour free trial gives you a free scope review before you spend a dollar. Every engineer on the platform is AI-native by default, vetted on Cursor, Claude Code, and Copilot fluency, which is why the per-feature throughput math works at all.

If your scope is still 20+ features and you want an honest second opinion before you hire, book a 48-hour Cadence trial and use the first day as a scope review. Worst case you cut another five features for free.

FAQ

How many features should an MVP have?

Six to nine "must" features for most B2B SaaS v1s. If you have more than 10 musts, the list is wrong, not the product. Sort again with the cut question and you'll find another 30% to delete.

How long should it take to ship an MVP?

Four to eight weeks of real engineering time for a properly-scoped v1. If your estimate is 16 weeks or more, you have a scope problem, not a velocity problem. Cut features until 4 to 8 weeks is realistic.

Should I include AI features in my MVP?

Only if AI is the actual product. Otherwise scope AI last, after the core flow works. Most AI features turn out to be one button that calls an API, which is week 5 work, not week 1.

What if customers ask for the features I cut?

That's the goal. Cut features that get requested in week 2 are real shoulds and you ship them in week 4. Cut features that never get requested were imagination, and you saved the engineer-weeks.

Who should do MVP scope cutting, founder or engineer?

Founder cuts the scope; engineer sanity-checks it. Engineers don't know which features are emotional attachments. Founders don't know which features take three weeks instead of three days. Both passes matter, in that order.

How do I evaluate an engineer's scope review if I'm non-technical?

A good engineer will name 2 to 3 features and tell you they're more expensive than you think, and suggest a simpler alternative for each. A bad engineer will accept the spec and start coding. The common founder mistakes when hiring developers post covers what to watch for.