How to scope a SaaS MVP.
A minimum viable product is the smallest thing that lets real users do the one job you are betting on — and that lets you learn whether they will pay for it. Scoping it is mostly a list of things you decide not to build yet.
- Published
- 14 October 2026
- From
- Kramiva
01
Start from one user doing one job
Write down who the first user is and the single job they hire the product for, in one sentence. Not "small businesses manage operations" but "a clinic receptionist confirms tomorrow's appointments without phoning each patient." If the sentence needs an "and", there are two products in it, and the first version should pick one.
This sentence is the test for everything that follows. A feature that does not help that user do that job is a feature for a later version.
02
Find the core loop
Most products have a loop the user repeats: create something, act on it, see the result, come back. For the receptionist it might be: open today's list, send confirmations, see who replied, follow up with the rest. The first version exists to make that loop work well, end to end, for real data.
Draw the loop as four or five screens before any code is written. Screens are cheap to change; a data model built around the wrong loop is not.
03
What a first version usually needs
The core loop needs some infrastructure around it to be usable by real people. Keep this list honest — each item should be the simplest version that works.
- Sign-in, using an established provider rather than a hand-built password system
- The core loop, working end to end with real data
- A data model designed properly, with migrations, because it is the hardest thing to change later
- Separation between customers' data, if more than one organisation will use it
- Basic roles only if the first customers genuinely have more than one kind of user
- Transactional email for the moments the loop depends on
- An admin view so you can support users without editing the database
- Error monitoring and backups, so problems are seen and data can be recovered
04
What can wait
Everything below is reasonable to want, and almost all of it can be added once you know users stay. Each one also adds testing, support and maintenance to every release after it.
- Native mobile apps, if a responsive web app lets the user do the job
- Self-serve billing, if your first customers can be invoiced manually
- Integrations, except the one without which users cannot adopt the product at all
- Fine-grained permissions, custom roles and audit trails
- Dashboards and reports beyond the few numbers the user actually checks
- Settings pages, themes, and multiple languages
- AI features — unless AI is the job itself
05
What never to cut
Scoping small is not the same as building carelessly. Some shortcuts are cheap now and very expensive later, because they put customer data or the whole codebase at risk.
- Security: authentication, access checks on every request, and isolation between customers
- Automated tests on the paths that touch money and permissions
- Ownership: the code, the accounts and the data in your company's name from day one
- Documentation of how to deploy and restore, so the product does not depend on one person
06
Write acceptance criteria before the build
For each milestone, write down what a user must be able to do for it to count as done — in plain sentences, agreed before work starts. "A receptionist can send confirmations for tomorrow's appointments and see who replied" is testable. "Messaging module" is not.
Acceptance criteria are what make a fixed scope work: they turn "is it finished?" from an opinion into a check, and they make it obvious when a new idea is a change to the scope rather than part of it.
07
Decide what you will learn
An MVP is also an experiment, so decide before launch what would count as evidence. Usually that is a handful of questions: do users complete the core loop, do they come back without being reminded, and will they pay. Instrument those few things and talk to every early user; a dozen honest conversations teach more than a dashboard.
A useful warning sign while scoping: if you cannot describe the first release in a short paragraph, or if the list of screens keeps growing, the scope has drifted from one user and one job.
Related services
Tell us what you are building.
A short brief gets you a real reply from a founder within one business day — an honest read on fit, scope, and budget.