How to scope a SaaS MVP.
Scope an MVP around one user completing one valuable workflow. Include the permissions, failure handling and operations needed for that workflow to work. Postpone breadth, not the basics that make the release usable.
Use the free worksheetOne approval flow, with a real finish.
Illustrative example: an agency wants clients to approve a specific document version. The hypothesis is that one recorded decision reduces uncertainty about which version was accepted. The first release needs enough of the flow to test that hypothesis, including what happens when the document changes.
| Requirement | First-release decision | Reason and acceptance check |
|---|---|---|
| Invite the correct client | Include account access and record permissions. | A different client's account cannot read or approve the document. |
| Record a decision | Save the decision against an identified document version. | Both sides can retrieve the same decision after signing in again. |
| Change an approved document | Create a new version that requires its own decision. | The old approval never silently transfers to changed content. |
| Set up the first accounts | Allow a documented manual step if an operator can support it. | Name the operator, required access and point where this stops being practical. |
| Themes and advanced reports | Postpone unless they are essential to the tested workflow. | Clients can still complete the approval and the team can review it. |
Name the assumption the release will test.
Start with a statement you can examine after launch. For example: small agencies will use one shared approval flow instead of collecting client comments in separate messages. The first release should let a real client complete that approval.
A list of competitor features does not establish that assumption. It usually expands the build before you know which part users value. Name the audience, the current workaround and the point where your product should make the work easier.
Draw one complete slice through the product.
In the approval example, someone creates a request, the client receives access, reviews the material and records a decision. The team can see that decision. That is the useful slice.
Now check its boundaries. What if access expires, the wrong client opens the link or the request changes after approval? These are part of making the core flow trustworthy. A second dashboard theme is not.
- The user can enter the product and understand the next action.
- The core task can be completed with realistic data.
- Access checks protect the right records.
- A failed action leaves a recoverable state.
- An operator can help when the flow stops.
Keep some work manual, deliberately.
Not every internal task needs an interface in the first release. An operator may prepare a report or configure a new account manually if that is safe, documented and practical at the expected volume.
Record the manual work as a real operating cost. Say who does it, what access it requires and when it becomes a bottleneck. A hidden manual step is a dependency; a documented one can be a useful scope decision.
Decide whether billing belongs in this release.
Some first releases need subscriptions to test willingness to pay. Others can start with an agreed invoicing process. Either way, decide what a customer is entitled to and what happens when that entitlement changes.
If organisations have multiple members, test their permissions separately from the billing screen. Removing a user or cancelling a subscription must produce the intended result inside the application.
Set the review before you build.
Agree what you will observe after release: completion of the main task, the points where help is needed and whether people return to use it. Do not replace those questions with an arbitrary number of features shipped.
The estimate should list the release boundary, dependencies and unresolved decisions. At BRÈCHE, that is the basis for planning a production MVP. A throwaway prototype is a different scope and should be called one.
The checklist.
- One audience, one problem and a testable assumption.
- A complete core workflow with acceptance criteria.
- Permissions and failure states included.
- Manual operations have an owner.
- Billing and access rules are explicit.
- A review plan exists for the first real usage.
Take it into the project.
MVP scope worksheet.
Write the smallest complete release, the assumptions behind it and the evidence that would justify the next one.
Download the worksheet (.txt)Plain text, ready to edit. No account or email required.
Preview the worksheet questions
- Audience and current workaround
- Describe one user group, its current workflow and the specific problem with that workflow.
- Assumption to test
- Write an observable claim about how this group would use or pay for the product. Say what evidence could contradict it.
- Complete user flow
- List entry, permission check, main action, saved result and the way the user returns to it.
- Required failure handling
- Cover invalid input, lost access, repeated actions and unavailable dependencies. Write the recovery or explanation the user needs.
- Launch, manual, later
- Place each requirement in one of these groups. A manual step needs an operator, instructions and a capacity limit.
- Entitlements and billing
- Define who can use the product and when access changes. State whether the first release needs online billing and why.
- Dependencies and unresolved decisions
- Name external systems, content and approvals. Record an owner and a resolution step for each unknown.
- Review after real usage
- Decide when to review completed tasks, points of failure, operator work and returning users. State what would change the next release.