How to Scope a SaaS MVP Without Overbuilding

Most SaaS MVPs don't fail because the code was bad. They fail because they took eight months to build something that should have taken six weeks — and by the time it shipped, the market had moved, the budget was gone, or the founder had lost conviction.

The scoping conversation is where that goes wrong. Here are the three questions we ask before writing a single line of code.

1. What's the one workflow someone will pay for on day one?

Not the full product vision — the one thing a user does in their first session that makes them come back. A multi-tenant billing system, role-based permissions, an admin analytics dashboard — all real requirements, all things you can add in month two. None of them are the reason someone signs up on day one.

Write that single workflow down. Everything that doesn't serve it goes on a "later" list, not a "never" list — it's not being cut, it's being sequenced.

2. What can you fake before you build it?

Stripe Checkout instead of a custom billing engine. A shared inbox instead of an in-app notification system. A manually-updated spreadsheet behind an admin view instead of a full back-office. Every one of these is a legitimate v1 decision, not a shortcut you'll regret — the goal is validating demand before you invest in infrastructure that demand hasn't earned yet.

3. Who is the second customer, not the first?

The first customer is usually a friendly design partner who'll forgive rough edges. The second customer is a stranger who won't. Scoping for "will this work for someone who isn't invested in our success" catches the gaps that scoping for the first customer alone misses — onboarding without hand-holding, error states that make sense without a Slack channel to ask in.

What this looks like in practice

On a recent multi-tenant platform build, this discipline took the initial scope from "full subscription management, team roles, an analytics suite, and a public API" down to: authentication, one core workflow, Stripe Checkout for billing, and a single admin view. Everything else moved to a phase-two backlog, prioritized by what actual users asked for after using the thing — not by what we guessed they'd want beforehand.

That's the actual value of scoping well: not doing less, but doing the right things first, in an order that lets real usage — not speculation — decide what comes next.

If you're staring at a spec document that's grown past what a first version needs, tell us what you're building — we'll help you find the six-week version of it.