What to cut from your SaaS MVP v1

The single best decision a founder makes in week zero of an MVP build is what to cut. Every feature that survives the cut adds days to the timeline; every feature cut is a feature you can add later from real user feedback rather than guessing. The canonical list of v1 cuts is short. But founders argue against every item on it, and that's the conversation that decides whether the MVP ships in six weeks or twelve.

#The bar for v1 inclusion

Before the list: the bar. Not "is it useful". The bar is does v1 fail without this feature? Failure means: a paid pilot user logs in, tries to do the thing they signed up for, and can't. If they can do the thing without the feature, the feature is v1.1.

Most founders fail at this test on the first two passes. The instinct to over-include is universal and the discipline of cutting is what separates an MVP that ships from a "we're launching next month" that's been said for nine months.

#The canonical cut list

These are the features that founders consistently fight to keep in v1 and that consistently belong in v1.1.

#Free trial

Cut it. Charge from day one with a money-back guarantee.

Free trials look free; they cost 1–2 weeks of v1 build. You need: trial-end logic, expiring-trial UI, plan-switching flow, dunning when payment fails on day 14, downgrade-to-free path, win-back emails. Each of those individually is a small thing; together they're 50–80 hours of engineering.

The money-back guarantee replaces all of it with one operational rule: if someone asks for a refund, refund them. Stripe makes this a one-click action. You ship v1 in week six instead of week eight.

The data quality is also better. Paid users who complete signup and actually use the product give you signal; trial-only users add noise.

#Native mobile

Cut it. Build responsive web that works well on mobile browsers.

The pitch for native mobile is push notifications and home-screen presence. The pitch against native mobile is +6 weeks to v1 and a duplicate codebase to maintain forever. For B2B SaaS in 2026, ~95% of use cases are well-served by responsive web. Even buyers who initially say "I'll use it on my phone" use it on desktop in practice.

The exception: products whose core value proposition is mobile (e.g. field-ops tools, location-aware utilities). For everything else, ship responsive web in v1.

#Team accounts (when the buyer is an individual)

Cut it. Ship single-user accounts with a "Coming soon: invite teammates" placeholder.

Team accounts add: shared workspaces, role-based permissions, invitation flow, billing reassignment, ownership transfer, member management UI. Easily 1–2 weeks of v1 scope.

If your buyer is an individual contributor or manager who'll later invite their team, ship the individual product first; team accounts are a fast follow once you have ten paying individual users.

If your buyer is the team (collaboration software where the unit is the workspace) then team accounts are core v1 scope and you can't cut them.

#Internationalization / localization

Cut it. Ship English-first.

i18n adds infrastructure (translation pipeline, locale routing, currency formatting, RTL support, date formats) that costs ~1 week of v1 even when you only ship one language. Every page you build now has to be translation-ready.

If your launch market is global, ship English first and add localization as a v1.5 deliverable. The cost of localizing later is roughly 80% of the cost of building it in from day one (almost no savings) and you avoid the v1 timeline hit entirely.

#Advanced search / filtering

Cut it. Ship basic substring search and one filter dimension.

Founders sketch a v1 where users can search and filter by half a dozen dimensions, sort by multiple fields, save searches, share filtered views. That sketch costs 1–2 weeks. The real-world use of search and filtering in v1 is 80% basic substring queries and 20% one-dimension filtering. Build the 80%; defer the 20% to v1.1 once you see how users actually search.

#Dashboard / reporting

Cut it. Ship the underlying data and one summary view.

A real dashboard with chart libraries, date pickers, comparison periods, exportable reports, and configurable widgets is a 1–2 week build by itself. The minimum viable dashboard is a single page showing the three numbers a user actually cares about, hard-coded.

Defer dashboard work to v1.1 especially if your users haven't told you which numbers matter to them. Building a dashboard before you know which metrics users care about is the canonical premature optimization in B2B SaaS.

#SSO (SAML / OAuth enterprise)

Cut it unless your day-one buyer is enterprise. Ship password + Google OAuth + (optionally) Microsoft OAuth.

SAML SSO costs $0 in fees if you build it yourself, but ~1 week of engineering for the IdP integration. WorkOS or similar services cut that to ~2 days of integration but cost $99–$1,000+/month. For an early-stage MVP, neither is a v1 spend.

The exception: you have a signed deal with an enterprise customer who explicitly requires SSO. In that case, SSO is a contractual scope item and goes in v1 with the cost reflected in the contract.

#Webhooks / public API

Cut it. Ship the internal API only.

Public webhooks and REST APIs require: documentation, authentication, rate limiting, versioning strategy, change-management discipline. They're a separate productization workstream. Defer to v1.1 once you know which integrations users actually want.

#Billing edge cases

Trim, don't cut entirely. Ship: credit card payments, monthly + annual plans, plan upgrades, customer-self-serve cancellation, basic invoicing.

Cut: prorated downgrades, mid-cycle plan changes, complex tax handling (use Stripe Tax for the basics), enterprise invoicing with NET-30 terms, custom contract pricing, multi-seat self-serve.

The cut items are real billing infrastructure that comes in v1.1 once you have customers who've asked for them.

#Granular permissions

Cut it. Ship admin + user roles only. No custom roles, no per-resource permissions.

Granular permissions are a multi-week feature even if it doesn't look like one. Every endpoint becomes a permission check, every UI element becomes a conditional render, every test multiplies. Defer until you have a customer who specifically asks for it.

#"Coming soon" placeholders

These are the most underrated thing to keep. A v1 with three "coming soon" placeholders for v1.1 features signals roadmap maturity to buyers without costing build time. Use them aggressively. They buy you scope discipline AND product credibility.

#What survives the cut

What's left after the canonical cuts is the actual MVP:

• Auth (email + Google OAuth)
• Stripe billing (monthly + annual, basic upgrade/cancel)
• Six core user flows (the actual product)
• Custom design system
• Basic admin panel (operations only)
• Single-tenant accounts
• Responsive web
• English-only
• Basic search (one substring field)
• Sentry + PostHog
• Production deploy + 30-day fix coverage

That's a six-week build. Anything else is v1.1.

#How to defend the cut list

Founders agree with cut decisions in the abstract and fight them feature by feature when scoping. The pattern is consistent enough that experienced agencies have stock responses.

The argument for adding feature X to v1: "But what if a customer asks for X?" The response: "Then they ask for X, and you build X in v1.1 once you have proof they actually wanted it. Right now you're building X based on a guess that they will."

The argument: "X is so small, it'll only take a day." The response: "Every ‘one day’ thing turns into a week. Add five ‘one day’ things to scope and the build slips by a month."

The argument: "If we don't ship X, no one will buy." The response: "Then ship the smallest version of X. The cut list isn't cut everything. It's cut to the minimum that proves the value prop."

#Bottom line

The version of your MVP that actually ships in six weeks is smaller than the version you sketched in week zero. That's not a failure of vision. It's how MVPs work. The features cut from v1 don't go into a graveyard; they go into a v1.1 list driven by real user feedback. Founders who can't cut ship in twelve weeks. Founders who can ship in six.