PLANNING GUIDE · SAAS & WEB APPLICATIONS
Scoping a SaaS MVP
An MVP is not a small version of everything. It is one complete journey a real user can finish, with the roles, data and handover that journey needs.
Discuss your product scopeJiangmen, China. Working globally.
Start with one journey, end to end
Describe the journey in the user's words: what they arrive with, what they do, what they leave with. If a step needs a second person or a third system, it is part of the scope.
A customer portal that accepts a request, assigns it to a team member and shows progress is a complete journey. A dashboard with six half-finished modules is not.
Roles and permissions come early
Who can create, edit, approve and delete? Which data can each role see? Permissions decided after the interface exists usually mean rebuilding screens.
Write the roles down with one sentence each, then walk the main journey as every role. Gaps found here are far cheaper than gaps found in testing.
Data and integrations decide the estimate
List the systems the product must read from or write to, and what should happen when one is unavailable. Include limits: rate caps, pagination, authentication and what a failed sync tells the user.
If you have existing spreadsheets or a legacy database, describe their structure with anonymised samples. Migration effort is usually underestimated because the current data was never documented.
Leave things out on purpose
Billing, reporting suites, native mobile apps, single sign-on and advanced search are common second-phase items. Naming them as out of scope is not a weakness; it keeps the first release testable.
Agree in writing what the first release will not do, so nobody discovers the boundary during acceptance.
Acceptance criteria you can actually test
For each journey step, write the expected behaviour and the failure behaviour. Then decide who signs off and what evidence counts: a screen recording, a test account, a checklist.
Criteria written this way turn a vague "it feels finished" into a decision both sides can make in an hour.
Questions we are asked
How many features should an MVP have?
Enough to complete one journey for every role involved, and no more. If a feature serves neither that journey nor a legal requirement, it belongs in a later release.
Do we need a design system first?
Not a full one. Agree the core layout, form patterns and component states for the first journey, then extend the system as the product grows.
What happens after the MVP ships?
Plan the handover at the same time as the scope: who operates it, who fixes defects, how data is backed up and how the next phase is prioritised. Support terms are easier to agree before launch than after.
What happens next?
- Review the goals, users and essential features.
- Confirm the deliverables, USD estimate and key milestones.
- Agree responsibilities and acceptance checks before work begins.