SaaS MVP Scope: What to Build First and What to Deliberately Cut

An MVP that does not ship is not an MVP. It is a specification with a burn rate. The usual cause is not engineering speed, and it is not the budget. It is that the scope was never actually decided, only listed, so every feature stayed provisionally in and the release date moved by whichever one was least finished that week.

Scoping a first release well is mostly the discipline of saying no in writing, early, to things you genuinely want. Here is how we do it on SaaS product engagements, and what we have learned about which cuts are safe.

Start from one workflow, not one persona

The most common scoping error is defining the MVP by who it is for. "Version one is for small clinics." A clinic does perhaps thirty distinct things, and that definition quietly includes all of them.

Define it by a single end-to-end workflow instead. One user, one starting condition, one finishing condition, and everything required to get from the first to the second. "A receptionist takes a phone booking and the patient receives a confirmation." That sentence has an edge to it. Anything not on the path between those two points is out, and you can tell immediately whether a proposed feature is on the path.

The test of a good workflow choice is whether completing it once is genuinely useful to the customer. If they still have to open a spreadsheet afterwards to finish the job, the workflow was cut in the wrong place and you have built half a bridge.

The four things you cannot cut

Almost everything is negotiable in a first release. Four things are not, because retrofitting them costs several times what building them cost, and because two of them can end the company.

• Authentication and a tenant boundary. Even with one customer, get the tenant identifier into every table and every query from the first migration. Adding isolation to a schema that assumed a single customer is one of the most expensive refactors in software, and the failure mode is one customer seeing another customer's data.
• An audit trail of who changed what and when. Append-only, from day one. You will need it for a support question in month two and for a compliance question in year two, and it cannot be reconstructed later.
• Backups you have restored at least once. An untested backup is a belief, not a backup. Restore into a scratch environment before launch and write down how long it took.
• Basic product analytics on the core workflow. If you cannot see how many people started the workflow and how many finished it, you will spend the months after launch arguing about opinions instead of reading a funnel.

Everything on that list is unglamorous and none of it demonstrates well. All four are cheap now and painful later, which is the definition of the work worth doing early.

The cuts that are almost always safe

These are the features that consume a disproportionate share of a first build and are rarely what decides whether a customer stays.

• Self-service signup. With fewer than fifty customers, create accounts yourself. You learn more from the onboarding conversation than the flow would have told you, and you save a fortnight of work on email verification and edge cases.
• Granular permissions. Two roles, admin and member. Fine-grained role design without real customers is guesswork, and it is guesswork that shapes your data model.
• Billing inside the product. Invoice manually until the volume genuinely hurts. Subscription billing is deceptively deep once proration, plan changes, tax and failed payments arrive.
• A settings page. Every configurable option is a branch you must support forever. Pick a sensible default and change it when a customer asks twice.
• Native mobile applications. A responsive web application answers the question of whether people want the workflow. Two store submissions do not.
• Integrations you have not been asked for by name. Build the one a paying customer named. Not the other four.
• An internal admin panel with a full interface. Database access plus a handful of scripts is fine for a while, and the scripts tell you which admin screens are actually needed.

Size it against a real date

Pick a launch date before you finish the scope, then cut the scope until it fits. This is the opposite of how most teams work and it is the reason most teams slip. A scope sized against a date gets decided. A date estimated from a scope gets negotiated, repeatedly.

Ten to twelve working weeks is a realistic first release for a single workflow with a small team. Under six weeks usually means the workflow was cut short of being useful. Over sixteen means more than one workflow is hiding in the scope, and it is worth finding out which one before you start rather than in week eleven.

Reserve a fifth of the schedule for the things that are not features: environment setup, deployment, the first real data migration, and the fortnight of small corrections that follow the first customer touching it. That reserve is not contingency and should not be spent on scope. It is the cost of shipping, and it is real every time.

Decide in advance what the launch is meant to prove

Before the build starts, write one sentence describing what you will know after launch that you do not know now, and the observation that would tell you. "Do receptionists complete the booking flow without calling us?" is answerable. "Do customers like it?" is not.

Then agree what happens if the answer is no. Teams that skip this step tend to respond to a disappointing launch by adding features, which is the most expensive available way to avoid the finding. Deciding beforehand that a poor result means a workflow change rather than a feature sprint is much easier while nobody is defending anything yet.

A short checklist

• One workflow, written as a sentence with a start and an end.
• A cut list with reasons, agreed by whoever will ask for those features later.
• Tenant boundary, audit trail, tested restore and funnel analytics in scope from the first sprint.
• A launch date chosen first, with a fifth of the time reserved for shipping work.
• One written question the launch will answer, and an agreed response to a negative answer.

Get those five right and the build is mostly execution. Get the first two wrong and no amount of engineering speed recovers it. Our SaaS product development service page sets out how we run a scoping week, what comes out of it, and how the first release is structured so the parts you deliberately cut can be added later without a rewrite.