SaaS MVP scope: what to build first, and what to leave out

Every founder's first feature list is too long. That's normal: you can see the whole product in your head. The job of MVP scoping is to find the smallest version that a real user would choose to use — and to get it in front of them before your budget or patience runs out.

Start from one user and one job

Name the first user precisely — not "small businesses" but "the operations manager at a 20-person distributor". Then name the single job they'd hire your product for. Everything in the MVP should exist to get that person through that job, start to finish.

If you can't pick one user and one job yet, you're not ready to build. A week of conversations with potential users will save more money than any engineering decision.

The must-haves that aren't optional

Some foundations are expensive to retrofit, so they belong in version one even though users never ask for them: accounts and authentication, a sensible data model, roles if more than one kind of person will use the product, and basic analytics so you can see what people actually do.

If your business model depends on payments, decide early whether the MVP takes money. Charging from day one is the strongest validation you can get — but it adds billing to the scope.

Things to cut (for now)

Admin features you could do by hand for the first twenty customers. Integrations nobody has asked for yet. Settings pages, themes and customisation. A mobile app when a responsive web app works on phones. Edge cases that affect a handful of users — handle them manually and write them down.

Cutting isn't saying no forever. Keep a written list of everything that didn't make it, ranked by how often users ask for it after launch.

Design the architecture for version two

Scope small, but don't build a dead end. Agree the data model, roles and integration points with the next few releases in mind, so new features extend the product instead of forcing a rewrite. This is where an experienced engineering partner earns their fee: not in typing faster, but in knowing which decisions are cheap to change later and which aren't.

Ship in weekly increments

Ask for working software on a staging link every week, not a big reveal at the end. You'll catch misunderstandings while they're cheap, and you'll have something to show early users and investors long before launch day.

A quick self-check

Can you describe the MVP in two sentences? Could a user get value from it without you on a call? Is every feature traceable to the one job you named? Do you know what you'll measure after launch to decide what comes next? If all four answers are yes, your scope is probably right.