How to scope a SaaS MVP you can actually finish
Solo SaaS projects rarely fail at the idea. They fail at 80% built, when the list of things left to do is longer than it was on day one.
The short version
- An MVP is one workflow, end to end. One buyer walks in with a problem and walks out with it solved. Everything else is version two.
- Freeze the scope in writing before you build. A list that lives in your head grows every time you open the editor.
- Cut settings, teams, integrations and admin panels by default. They are the four places a solo project goes to die.
- Six weeks of evenings is the budget. If the scope does not fit, the scope is wrong, not the calendar.
- Write the scope as a one-page spec. It is what you will hand to an AI builder, and what you will read when you are tempted to add something.
What is a SaaS MVP, really?
The smallest product a specific person will pay for. Not the smallest thing you can build, and not a demo of what the full product will one day be: the smallest complete path from a real problem to a real result, with a price on it.
The word has been stretched until it means nothing. People call a landing page an MVP, and they call a product with forty screens and no customers an MVP. Neither is. The test is whether one person, with the problem you validated, can sit down, do the thing, and be done. If they can, you have a product. If they can complete nine tenths of it, you have nothing, because nobody pays for nine tenths.
That is why the correct unit of scope is a workflow, not a feature. Features are things the product has. A workflow is something the customer finishes.
A feature is what you built. A workflow is what they paid for.
How do you find the one workflow?
Start from the moment the customer would open the product and write down every step until the moment they close it satisfied. Then delete every step that is not strictly on that path. What survives is the MVP.
For an invoicing tool the path is: create a client, create an invoice, send it, get paid, see that it was paid. Five steps. Not recurring invoices, not multi-currency, not a client portal, not a dashboard of revenue over time. A freelancer with one client who can send one invoice and see it paid has received the value. Everything else can be asked for.
Two things tend to expand this list. The first is imagining a second buyer: the agency as well as the freelancer, the team as well as the individual. Serve one. The second is imagining the customer's second month, when they might want reports and history and exports. They are not in their second month. Build the first one.
What should you cut by default?
Anything that exists to manage the product rather than to do the job. Settings pages, team and role systems, third-party integrations and admin panels are the four biggest: each is a product in itself, and none of them is the reason anyone signs up.
| Feature | Verdict | Why |
|---|---|---|
| The core workflow, start to finish | Keep | It is the product |
| Sign-up, login, password reset | Keep | Nobody can pay without an account |
| Stripe checkout and a plan | Keep | Billing is the validation |
| Settings page | Cut | Hard-code sensible defaults; change them by hand on request |
| Teams, roles, invites | Cut | Doubles the data model; one account per customer |
| Integrations (Slack, Zapier, API) | Later | Build the one a paying customer asks for, not the six you imagine |
| Admin panel | Cut | Use the database console; you are the only admin |
| Dashboard and reports | Later | Nothing to report on until there is history |
| Onboarding tour | Cut | A product with one workflow does not need a tour |
| Dark mode, themes, custom branding | Cut | Polish on a thing nobody has bought yet |
"Later" is not a polite word for "cut". It is a list you keep, and the order of that list is set by paying customers asking for things. The feature that three customers ask for in the first month is the next thing you build. The feature none of them mention was never real, however obvious it seemed in the planning stage.
How do you tell a must-have from a nice-to-have?
Remove it in your head and ask whether the customer can still finish the workflow and still be willing to pay. If yes to both, it is a nice-to-have, no matter how much you want to build it.
- Can the workflow complete without it? If yes, it is not part of the MVP.
- Would a customer refuse to pay without it? Not "prefer". Refuse. Most things you are sure of here are wrong, which is what the first ten customers are for.
- Does it exist to serve you rather than them? Analytics, admin tools and automation for your own convenience come after revenue.
- Is it there because a competitor has it? Competitors have ten years and a team. You have six weeks and yourself.
The scope is frozen the moment you write it down. Not "frozen unless something good comes up". Frozen. Anything that comes up goes on the later list, and you look at the later list on launch day, not before. This is the single habit that separates solo founders who ship from those who have been "nearly done" for a year.
Why six weeks?
Because it is long enough to build one real workflow with billing and short enough that you cannot lose the plot. Beyond six weeks, motivation, the market and your own taste all drift, and the thing you finish is no longer the thing you scoped.
Six weeks of evenings and weekends is roughly a hundred hours. With an AI coding assistant doing most of the typing, a hundred hours is enough for auth, a database, one workflow, Stripe and a deploy, if the scope is small and the stack is boring. It is not enough for two workflows, and it is nowhere near enough for one workflow plus a settings page plus teams.
The number is also a diagnostic. When you plan the build and it comes out at fourteen weeks, you have not discovered that your idea is bigger than most. You have discovered that you have not finished scoping. Go back to the workflow and cut until it fits.
How do you write the scope down?
As a one-page spec: the buyer in one sentence, the workflow as a numbered list of steps, the data each step touches, the plan and its price, and an explicit "not in v1" list. Plain language, no mockups. This is the page you hand to your AI tools and reread when you are tempted.
The page has five sections and should fit on one screen:
- Who it is for. One sentence, one buyer. "Freelance designers who invoice fewer than ten clients a month."
- The workflow. Numbered steps, each one a screen or an action. If a step needs a sub-list, it is probably two steps.
- The data. The handful of things the product stores. Client, invoice, payment. If the list passes six, something is out of scope.
- The plan. One price, monthly, decided using the arithmetic that survives one person.
- Not in v1. Everything you cut, written down so it stops occupying your head.
The reason for plain language is that this page becomes the brief. AI builders produce what they are told with a precision that is embarrassing when the telling was vague. A spec that says "users manage their invoices" produces a generic CRUD screen. A spec that says "step 3: the user picks a client, enters line items, and sees a total; step 4: they press send and the client receives an email with a payment link" produces the product.
What does a finished MVP look like?
A stranger can sign up, pay, complete the workflow and get the result without you in the room. That is the whole definition. If any of those four things needs you, it is not finished, whatever the feature list says.
It will look thin. That is correct. The founders who get to recurring revenue alone are almost always embarrassed by the first version, and the ones who were proud of it usually took a year to ship it. Thin and finished beats rich and nearly done, every time, because only one of them can be sold.
Frequently asked questions
How small is too small for an MVP?
It is too small when a paying customer cannot complete the workflow they are paying for. That is the only floor.
Should the MVP have billing from day one?
Yes. Billing is the feature that tells you whether you have a business, and adding it later is always harder than it looks.
What if customers ask for the features I cut?
Good, write them down. A cut feature that a paying customer asks for is a validated feature, which is the cheapest kind.
Six weeks is not enough for my idea.
Then the idea is not scoped yet. Every real product can be reduced to one workflow that ships in six weeks; the reduction is the work.
Do I need a design before I scope?
No. Scope first, design second, code third. A design made before the scope is frozen grows the scope, because every empty corner of a mockup invites a feature to fill it.
The system behind this, written down
Everything above is the map. The Income Loop is the work inside it: modules 0–6 from the problem you solve to the offer that pays for it, plus ten traffic paths: the deeper post banks, the content sales systems and the full software build sequence, in one place.
Get The Income LoopNot ready to pay for anything? The Basic Income Loop is free and includes a complete seven-day starter for Threads, Instagram or software, enough to find out which one suits you before spending anything.