How to Scope an MVP for Your SaaS: What Goes In and What Can Wait

To scope an MVP, start from the one problem your first customers will pay to have solved, then cut everything that isn't needed to solve it end to end. I sort every item on the feature list into three buckets: must, should and later. Only the first bucket is your MVP.

I'm a freelance developer who builds SaaS products for clients, so I have an obvious interest in you building something. A tight first version is still in your interest: it costs less, ships sooner and teaches you more.

The short answer: three buckets and one question

The rule is simple: if a paying customer can complete the job your product exists for without a feature, that feature isn't a must. It sounds obvious, and it's exactly where most wish lists fall apart.

This is a stripped-down version of MoSCoW prioritization from the DSDM agile framework, with "could" and "won't" merged into a single later bucket. The difference rarely matters in a first version. If you're earlier in the process, my complete guide to building a SaaS covers the whole path from idea to paying customers. And if you want the definition first, start with what an MVP is, and what it isn't.

How to scope an MVP in seven steps

Order matters. Most founders start by listing features, and then they have nothing to sort them against. Start with the problem and let the list come second.

1. Write the core job in one sentence

Who is the product for, what problem does it solve, and what has the customer achieved when it works? For example: "Owners of small cleaning companies can plan the week's jobs and see what's been done without phoning their staff."

If the sentence needs one more "and", you probably have two products. Pick one. That sentence becomes the yardstick for every decision that follows.

2. Map the one path that matters

Write down the path a new customer takes: sign-up, first setup, the action that solves the problem, and the moment they see the result. It's usually 5-10 steps. Product people call this the happy path.

Anything needed to get through that path is a candidate for must. Anything outside it isn't, by default. This is also where the unglamorous parts show up, the ones nobody puts in a pitch deck: password reset, inviting a colleague, an email receipt.

3. Put every idea on one list

Write down everything you, your co-founders and your early prospects have mentioned, including the ideas you already know are unrealistic. A long list is easier to sort than a vague feeling about what the product should do.

Phrase each item as something a user does, not as a technical component. "A cleaner marks a job as done" is far easier to judge than "mobile module".

4. Sort the list into must, should and later

Go through one item at a time and ask three questions:

1. Can the customer do the core job without it? If not, it's a must.
2. Will they miss it within the first month? If so, it's a should.
3. Did a real customer ask for it, or are you imagining that someone will? If it's the latter, it goes in later.

Be ruthless with the first bucket. My rule of thumb: if more than half the list ends up as must, you haven't sorted it, you've just relabeled it.

5. Replace features with manual work

With a handful of customers, you can replace a lot of features by doing the work yourself. This is the idea behind what's often called a concierge MVP. Set up new accounts by hand instead of building self-serve onboarding. Take payment through Stripe Payment Links, which also support subscriptions, instead of building a full billing flow. Email a monthly report from a spreadsheet instead of building a dashboard.

None of this scales, and that's the point. You automate once the manual work starts to hurt, and by then you know exactly what to build.

6. Fix time and budget, then cut again

Decide how much time and money version one is allowed to cost before you see an estimate. In agile terms: fixed time, flexible scope.

If the musts take up more than about 60% of the budget, cut again. That ceiling comes from MoSCoW, and it leaves a sensible buffer for surprises and for the shoulds that matter most. For a sense of the numbers, I've broken down how much an MVP costs and what drives the price.

7. Write down the later list and share it

Everything in later gets written down and shared with everyone on the project, including early customers where it makes sense. A visible list makes "no" easier to say, because no means "not now" rather than "never".

Review it after a few weeks with real users. Often, part of the list turns out to be something nobody misses, while users ask for something you never considered.

A worked example: cutting a wish list down to size

This example is made up to show the method, but the items are the kind that often end up on a wish list for a B2B tool. Picture a founder building a scheduling tool for small cleaning companies. The first wish list has 13 items. After sorting, it looks like this:

Five musts remain, and all five serve the core job from step 1: plan the jobs and see what's done. The three shoulds are good ideas, but manual work or standard tools can cover them for the first few months. A payment link takes no code to set up, while a full billing system with trials, upgrades, proration and failed payments is a project of its own.

The hard call is the native app. It feels essential because cleaners work on site. But all they need is to open a list and tap "done". A mobile-friendly web app handles that, and you build and maintain one product instead of three.

Look at the languages row too. If you plan to sell across Europe, launching in four or five languages at once is tempting. Start with one market, get it working, then add the next. Roles follow the same logic: owner and cleaner are enough to begin with, and team leads or per-client permissions can come once you see how customers actually organize their work.

What you should never cut

A lean MVP isn't a sloppy MVP. Some items look like features on a list but are really preconditions for having customers in the system at all:

• Separation of customer data. In a SaaS, many customers share one system, and one customer must never see another's data. That has to work from customer number one, and I cover the options in my guide to multi-tenant SaaS architecture.
• Secure login and access control. Passwords stored properly, sessions that expire, and permissions checked on the server, not just hidden in the interface.
• Backups you've actually restored. Until you've tried, you don't know they work.
• Error tracking, so you hear about problems before your customers email you.
• GDPR basics. If your customers are EU businesses, they'll expect a privacy policy, a data processing agreement (DPA) and a way to delete their data, wherever you're based.
• A way to support customers. You need to look things up and fix mistakes without editing the database by hand every time. It doesn't have to be a polished admin panel.

The data model belongs on this list too. Customers never see it, but it's expensive to change once real data lives in it. Spend an extra day thinking through accounts, users and roles rather than migrating everything six months in.

Keeping scope under control during the build

Scope rarely blows up in one jump. It creeps, one reasonable-sounding request at a time:

• "While you're in there, could it also ..."
• One promising prospect wants a specific feature before they'll sign.
• A competitor ships something, and suddenly it feels mandatory.
• Edge cases: what if a job runs past midnight, or one person has two roles?

My rule is to swap, not add. If a new item enters must, something of similar size has to leave. That forces the right question: is this more important than what you've already committed to?

Handle edge cases manually at first. Let the system reject the unusual case with a clear message, and deal with it yourself when it happens. For concrete examples of what can safely wait, see my list of 12 features your SaaS doesn't need at launch.

When you shouldn't build an MVP yet

Sharp scoping won't help if nobody wants to pay. If you haven't talked to potential customers about the problem yet, start there. My guide on how to validate a SaaS idea shows how to test demand before anyone writes code.

There are also cases where you don't need a developer like me yet:

• When a spreadsheet, a form and a payment link can test the idea. If ten customers pay for a manual version, you've learned more than an MVP would teach you.
• When the musts still don't fit the budget after two rounds of cutting. The problem is then the product definition, not the development, and it needs solving first.
• When nobody on your side has time to make decisions. An MVP means lots of small calls every week, and without one person making them, the project stalls.

Next steps

After the seven steps, you have what a developer needs to give you a meaningful quote: a core job, a path and a sorted list. Run through this checklist before you send anything out.

On my SaaS development page, you can see how I run SaaS projects, including the paid fixed-price discovery phase that comes before larger builds. I'm based in Denmark, so my working day overlaps with UK and EU business hours.

Frequently asked questions

How long does it take to build a SaaS MVP?+

It depends on what's in must, but a focused MVP built by one developer often takes a few months. If your estimate points to six months or more, that's a sign the list needs another round of cutting. The timeframe is a useful control in itself: set it first and let the scope adjust to fit.

Should my MVP include payments?+

Yes, in some form. Customers should pay from the start, or you won't learn whether the product is worth anything to them. Payments don't have to be automated, though. An invoice or a payment link can handle your first customers, while self-serve subscriptions with trials and upgrades can wait until your pricing has settled. If you sell across EU borders, check with your accountant how VAT applies.

Can I change the scope during development?+

Yes, and you should expect to. You'll learn something new every week, especially once the first users arrive. What matters is that a change swaps places with something else rather than piling on top. On a fixed-price contract, changes have to be agreed and priced, so raise them early and in batches rather than one at a time.

Does an MVP need to scale from day one?+

No, but it needs to be built so it can grow. That means a mainstream, well-documented framework, a carefully designed data model and separated customer data from the start. Optimizing for thousands of concurrent users can wait until you have them. An MVP rarely struggles with load early on, but it can easily struggle with a data model that was rushed.