Most SaaS MVPs fail in week three. Not because the engineering is hard. Because the team can't say no.
Six weeks is short enough to be honest. There isn't time for the third onboarding flow or the second billing model or the email designer's preferred dark mode. Either a feature gets a user closer to paying or it gets cut. That's it.
Here's what survived the last MVP we shipped and what got deferred.
What "shipped" actually means
Before the cuts, the definition. A v1 MVP is shipped when:
- A new user can sign up without a sales call
- They can complete the core workflow the product exists to support
- They can pay, on a real billing system, with real money
- They can invite a teammate if collaboration matters
- We can debug their problems without shipping code
Anything that doesn't serve one of those five outcomes is not v1. Not "should be v1." Not "shouldn't take long." Not v1.
What made the cut
Auth — but only one path. Email and password. No social login. No SSO. No magic links. One sign-up flow, one sign-in flow, one password reset. Two days of engineering, not two weeks.
The core workflow — fully. Whatever the product fundamentally does, the v1 version does it end to end. Half-built core workflows kill MVPs faster than missing features. If the product is invoicing software, you can create, send, and get paid on a real invoice in v1.
Billing on Stripe. Two plans. Monthly only. A 14-day trial that doesn't require a credit card. Webhook handlers for the four events that matter: subscription created, subscription updated, subscription deleted, invoice paid. No annual plans, no per-seat math, no usage metering. That comes after the first 50 customers tell us what they want.
One transactional email pipeline. Resend or Postmark, doesn't matter. Templated emails for: welcome, password reset, trial ending, payment failed. Plain text with one button. No drip campaigns. No design system. The MVP doesn't need 18 email templates; it needs four that work.
A real database. Postgres, MongoDB, whatever fits the data shape. With proper indexes, foreign keys, and migration scripts. Skipping this is the most common mistake. People build the MVP on a spreadsheet-shaped JSON file and pay for it in week eight when the customer count crosses 30.
Logging and error tracking. Sentry or equivalent, wired up day one. When a paying customer hits a bug, we need to know before they email us. This isn't optional. It's the difference between a real product and a demo.
Team invitations — if the product is collaborative. One role: member. No admin/owner/billing hierarchy. The founder is the admin. Everyone else is a member. We add roles in v2.
What got cut
Onboarding flows. No interactive tour, no progress indicator, no "complete your profile" checklist. The first run is: blank state, one big button telling you what to do next. If the product needs a 12-step tour to be usable, the product is the problem, not the onboarding.
Settings pages. One settings page. Three sections: profile, password, billing. That's it. No notification preferences. No appearance settings. No team management UI beyond inviting members and removing them.
Mobile-first responsive everywhere. The marketing site is mobile-first. The dashboard is desktop-first and degrades gracefully to tablet. No phone optimization for v1. B2B SaaS users sit at desks.
Multiple subscription tiers. Two plans is the maximum. Free trial and paid. Or basic and pro. Three tiers triples the testing surface and forces decisions nobody has the data to make yet.
Internationalization. English only. USD only. No timezone selector. We'll add these when the third non-US customer asks for them.
Real-time updates. No WebSockets, no live cursors, no presence indicators. The user refreshes the page. This sounds backwards in 2026 but adds a week of work and zero customer value for most B2B tools.
Custom domains. Customers use yourapp.com/customer-slug. Not customer.yourapp.com. Not their own domain. v2 problem.
A blog with categories, an authors page, and an RSS feed. The marketing site has a landing page, a pricing page, a privacy policy, and a terms page. Four pages. The blog comes when there's something to write about.
The mid-MVP crisis
Around week four, someone always wants to add a feature. Usually a good idea. Usually the wrong time.
The rule we use: every new request gets a sticky note that says "v1.1" or "v2." Nothing gets added to the v1 backlog after week one. The list is closed. If the request is brilliant, it stays brilliant in three weeks when we're shipping v1 and starting on the next thing.
This is the hardest part. Saying yes feels productive. Saying no feels lazy. In a 6-week sprint, no is the productive answer 90% of the time.
What ships at the end
Six weeks in, you have a working product. Not polished. Not feature-complete. Working. Real users sign up, do the thing the product does, and pay for it. Some of them refund within a week. Some of them stay forever. Either signal is useful.
What you don't have: marketing automation, advanced analytics, a help center, a status page, a public API, a mobile app, integrations with Slack, integrations with anything. That's fine. You can build all of those in v2 once you know which 50 customers stayed and what they actually need.
If you're thinking about building a SaaS MVP and want a sanity check on the scope, the project cost estimator will give you a rough timeline and price. If you want to talk through the cuts before you commit, book a 15-minute call.