
How to scope your first SaaS MVP
Choose the user, the problem, and the one complete journey your first release needs to deliver.

A useful MVP is a small product that lets someone complete a meaningful task. Scoping it starts with deciding what you need to learn from real users, then building enough of the experience to make that learning possible.
Write the job in one sentence
Describe one type of user, the situation they face, and the outcome they want. “Independent tutors need a way for students to book an available lesson without exchanging messages” is a more useful starting point than “a booking platform for everyone.”
Use that sentence to assess each proposed feature. If it serves a different audience or a future business model, keep it on a separate later-release list.
Map one journey all the way through
For the tutor example, the journey might be: open a booking link, choose an available lesson, enter contact details, and receive confirmation. The tutor also needs a way to set availability and see bookings.
Include the points where the journey can fail. What happens if two people choose the same slot? Can a tutor cancel a lesson? What should a student see when no lessons are available? A narrow scope still needs to work reliably.
- Define the starting point and successful end state.
- Identify the minimum data and permissions each step needs.
- Include the admin actions needed to operate the service.
- Write down the important failure and recovery paths.
Separate essentials from attractive extras
Availability, booking, and confirmation belong in the first-release discussion. A tutor marketplace, referral programme, native mobile app, and advanced reporting can wait unless one is essential to the question you want to answer.
Payments require a deliberate decision. If testing willingness to pay is the main goal, checkout may be essential. If you are first testing scheduling with existing customers, a simpler arrangement may be enough.
Make the scope testable
Describe what a user can do and how you will know it works. “A student cannot book an unavailable slot” is clearer than “a powerful booking engine.” Add the required integrations, supported devices, and the people who will review the work.
Keep assumptions beside the scope. Missing API access, unfinished designs, or undecided business rules can change the estimate. Resolve the consequential unknowns before treating a delivery date as a commitment.
Choose what you will learn after launch
Pick an observable outcome tied to the journey: completed bookings, active workspaces, or successful first transactions. Pair it with conversations about where users became confused or stopped.
Let the next release respond to that evidence. A focused first version makes it easier to decide what deserves further investment.
Continue reading
More ideas for the road ahead

