How to scope a SaaS MVP: the one-workflow rule

The most common mistake we see in founder MVP briefs is not under-ambition — it's the opposite. A founder with a clear problem to solve arrives with a brief that contains twelve features, four user types, an admin panel, a mobile app, and an API for partners. The question isn't whether any of these are good ideas. It's whether all of them need to exist before a single user can confirm the product is solving the right problem.

They don't. Almost always, they don't.

The one-workflow rule

A SaaS MVP should contain exactly one complete workflow — the sequence of steps that takes a user from "I have a problem" to "this tool just solved it." Everything else is infrastructure or iteration.

That workflow needs three things around it to work as a real product:

Authentication — users need to sign in. This is not optional, because without it you have no user identity, no persistence, and no ability to iterate on user behaviour. But auth is also not a differentiator. It should be solved with an off-the-shelf provider (Clerk, NextAuth, Supabase Auth) in the smallest possible time.

Payments — if your product has a monetization model, it needs to work from day one. Not a fake checkout. Not "we'll add payments in v2." Real Stripe with real subscriptions or one-time payments. Two reasons: (1) users who pay behave differently than users who don't, and you need that signal early; (2) retrofitting payment infrastructure into an existing codebase is harder than building it in from the start.

One workflow — the thing that makes your product worth paying for. One workflow. Not a menu of features. Not multiple user types with different journeys. One flow, end to end, working correctly.

What to defer

Admin panel — you don't need this before you have users. You will eventually, but not in v1.

Advanced permissions — user roles and permissions become important when you have a team using the product. In week one, you probably don't.

Mobile app — unless your workflow is genuinely mobile-first (a field inspection tool, a location-aware service), build the web version first. You can validate the core workflow on desktop and add mobile later.

Integrations — every integration you add to an MVP is scope that delays launch and complexity that can break. Add integrations in v2, after you've confirmed that users want the thing being integrated.

The test

Before adding a feature to a v1 scope, ask: can a paying user complete the core workflow without this feature? If yes, it's v2. If no, it belongs in v1.

Apply this test ruthlessly. Most features pass it.

The outcome

Teams that follow the one-workflow rule ship in six weeks. Teams that don't ship in six months — if they ship at all. The product you launch with one workflow and three users who love it is more valuable than the product you're still building that has twelve features and zero users.

Scope discipline is the feature that makes everything else possible.