How to Scope an MVP: A Founder's Pre-Build Checklist
A practical way to turn a promising SaaS idea into one buildable customer loop—without hiding launch work or letting every reasonable feature into version one.
Api AlamThe short answer
Scope an MVP around one customer, one painful moment and one complete path to a useful result. Include the work that makes that path trustworthy. Put everything else on a written not-now list.
A scope is not a pile of features with the word “MVP” above it. It is a boundary around what you need to learn next. If you are testing whether agency owners will pay for a better client handoff, team permissions, an iOS app and advanced reporting do not make the first answer more honest. They make it slower and more expensive.
Y Combinator’s MVP spec guidance makes a useful distinction: an MVP must tell a complete product story for a real user, even when that story is deliberately narrow. Small is not the same as half-finished.
If you cannot yet name the customer or recurring problem, stop here and use the SaaS validation guide. Scoping cannot rescue an idea whose riskiest assumptions still live only in the founder’s head.
Six answers before you discuss screens
- First customer
- Who feels this problem often enough to try an unfinished first version?
- Trigger
- What happens immediately before they reach for this product?
- Core job
- What useful result must they complete from start to finish?
- Current alternative
- How do they get that result today, and what is painful about it?
- Learning signal
- What real behaviour would justify another build cycle?
- Boundary
- Which users, platforms and workflows are explicitly outside version one?
Find the first useful loop
The easiest way to shrink scope without losing the product is to map one loop: what triggers the customer, what they bring, what they do, what the product returns and what happens next. If the path stops before the result, you have scoped a demo. If it keeps going into every future possibility, you have scoped a roadmap.
Write it from the customer’s perspective. Atlassian’s user-story guidance uses the familiar user, goal and reason structure. I add the trigger and observable result because they expose where the workflow actually begins and ends.
01
Trigger
The customer reaches the painful moment.
02
Input
They provide the minimum information or asset.
03
Action
They complete the essential task.
04
Result
The product returns something useful.
05
Signal
You observe use, return, referral or payment.
Cut features without cutting the promise
Feature prioritisation gets difficult because most proposed features are reasonable. The question is not whether a feature would help someday. The question is whether version one fails to deliver or test its promise without it.
Basecamp’s appetite and fixed-time, variable-scope approach starts with how much time a problem deserves, then shapes a solution inside that boundary. That is more useful than estimating an unlimited wish list and acting surprised by the result.
Does the core user still reach the promised result without it?
If yes, defer it.
Is it for a second user type or a second main workflow?
Move it to the later list.
Does it make the result possible, or only more convenient?
Convenience usually waits.
Can you deliver this part manually for the first ten customers?
Keep the outcome; defer the automation.
Does it solve a scale problem you do not have yet?
Design a migration path, not the full system.
Would removing it damage safety, trust, payment or the core promise?
Keep it and test it properly.
Define done before someone prices the work
“Build file sharing” is an idea. “A signed-in owner can upload a supported file, create a link, open it in a logged-out browser and see the delivery event” is something a founder can inspect. Acceptance criteria turn a conversation into observable behaviour.
Atlassian separates story-specific acceptance criteria from a broader definition of done. For a small SaaS build, use both: criteria for the important flows and one launch standard that applies across the release.
Launch-ready belongs inside the scope
- The primary workflow works on the supported desktop and mobile sizes.
- Authentication and permissions allow the right actions and deny the wrong ones.
- Empty, loading, error and recovery states are understandable.
- Production payments, receipts and failed-payment behaviour are tested when billing is in scope.
- Analytics record the one behaviour the MVP is meant to test.
- The production domain, email, database and deployment use founder-controlled accounts.
- Basic security, backups, logs and abuse limits match the data and risk involved.
- A real customer can complete the job without the founder narrating every step.
The exact standard depends on the product. Supabase’s production checklist, Stripe’s go-live checklist and the OWASP ASVS are useful prompts for database, payment and application-security responsibilities that feature lists often forget.
Turn unknowns into small tests
A scope becomes fragile when uncertainty is written as certainty. Name what you do not know, how it could affect the build and the cheapest way to learn before the whole product depends on it.
Technical unknown
Can the external API support the required rate, data or approval flow?
Response: Run a short technical spike before promising the full date.
Product unknown
Will the customer understand or trust the workflow?
Response: Test a prototype or manual pilot before production polish.
Operational unknown
Who handles exceptions, refunds, moderation or customer data requests?
Response: Write the manual owner and response path into the first release.
Commercial unknown
Will the buyer pay, and who can approve the purchase?
Response: Return to validation before funding a broad build.
Use this one-page MVP scope template
Keep the brief short enough that the founder, builder and reviewer can hold the same product boundary in their heads. Each field below should fit in a few lines. If one turns into a strategy document, the decision probably is not ready.
- Customer
- One specific first user or buyer.
- Problem
- A recent, costly situation—not a broad market category.
- Core outcome
- The result version one must deliver.
- Primary flow
- The steps from trigger to useful result.
- Success signal
- The behaviour or payment you will measure after launch.
- Included
- Only the capabilities required to complete and trust the primary flow.
- Not now
- Named users, platforms, automations and reports that are excluded.
- Acceptance
- Observable pass/fail conditions for the important workflows.
- Constraints
- Budget, appetite, deadline, integrations, data and compliance needs.
MVP SCOPE — [PRODUCT NAME] CUSTOMER [One specific first user or buyer] PROBLEM [The recent situation and current workaround] CORE OUTCOME [The useful result this release must deliver] PRIMARY FLOW 1. [Trigger or entry] 2. [Essential action] 3. [Useful result] SUCCESS SIGNAL [The behaviour, commitment or payment to measure] INCLUDED - [Capability required for the primary flow] - [Trust, safety or payment requirement] - [Launch requirement] NOT NOW - [Second user or workflow] - [Convenience feature] - [Future platform, report or automation] ACCEPTANCE - Given [starting state], when [action], then [observable result] - Failure and permission cases are named and tested - The core flow works on supported screen sizes CONSTRAINTS AND UNKNOWNS - Budget/appetite: [amount or time] - Required integration: [service] - Riskiest unknown: [question and test] HANDOVER - Founder-controlled repository and production accounts - Deployment notes, access inventory and post-launch fix window
A worked SaaS scope: client file delivery
Here is how I would shape a focused first release based on what I learned building BulkShare. This is a teaching example, not a claim that the real product arrived in one perfect pass.
- Product
- A branded client file-delivery portal for small agencies
- First user
- An agency owner sending final files to a client
- Core outcome
- Upload a file, share one professional link and know whether the client opened it
The first useful loop
Owner creates an account and workspace
Owner uploads a supported file
Product creates a branded share link
Client opens or downloads without an account
Owner sees the delivery event
Included in version one
- Single-owner authentication
- File upload with progress and failure recovery
- Branded public delivery page
- Link expiry and basic access control
- Open/download event
- Simple subscription and production deployment
Deliberately deferred
- Team roles and client accounts
- Native mobile applications
- Folders, comments and approvals
- Advanced analytics and custom reports
- Slack, Drive and Zapier integrations
- Custom email-template builder
Founder checklist before the build starts
A clean yes to each line means a developer can challenge and estimate the same product you believe you are buying.
- I can name the first customer without using ‘everyone’, ‘businesses’ or ‘creators’.
- The scope contains one leading outcome and one primary end-to-end flow.
- Each included feature is required for capability, trust, safety or payment.
- The not-now list is written beside the included list.
- The riskiest integration or assumption has a cheap test and an owner.
- Important workflows have observable acceptance criteria.
- Launch work includes permissions, errors, analytics and supported mobile states.
- The budget and deadline are constraints used to shape the product—not wishes added afterward.
- The repository and production services will live in accounts the company controls.
- I know what customer behaviour will decide whether to continue, change or stop.
Once the brief holds still, compare the MVP budget, choose a realistic delivery window, then use the developer hiring checklist to judge who should build it.
The Lean Startup’s validated-learning principle is the final test: the first release should earn a decision, not simply create more software to maintain.
MVP scoping FAQ
- How small should an MVP scope be?
- Small enough for one customer type to complete one valuable job from start to finish. If the release needs several equal workflows, several user types or several platforms, choose the most important learning goal and reduce it again.
- How many features should an MVP include?
- There is no useful universal number. Count capabilities against the primary flow instead: keep what makes the outcome possible and trustworthy, then defer convenience, secondary users and future-scale tooling.
- What is the difference between an MVP scope and a roadmap?
- The MVP scope is a commitment for the first learning cycle. A roadmap is a set of possibilities after that cycle. Mixing them makes optional future ideas look like current requirements.
- Should security and error states be cut from an MVP?
- No. Reduce the data, roles and integrations to lower risk, but do not pretend access control, secrets, payment failures or recovery states are optional when the product depends on them.
- Who should write the MVP scope?
- The founder owns the customer problem and business constraints. A strong product builder should challenge assumptions, expose technical risk and turn the brief into testable delivery boundaries before quoting it.
- What if the idea changes during development?
- Keep the learning goal and deadline visible. Swap an equivalent item, defer the new request or agree to change the date and price. Quietly adding it is how a focused build turns into an unfinished one.
- Can one developer build a scoped SaaS MVP?
- Often, yes. One focused web workflow using a conventional stack can suit a senior product-minded developer. Multiple native apps, regulated data or several complex roles may require a broader team or a smaller first release.
Research sources
The framework combines my experience building SaaS products and scoping founder work with the primary product, delivery and production references below.
about the author
Api Alam
Indie maker and bootstrap founder. I build SaaS products, ship in public and help founders turn a focused scope into a working MVP.
How I build MVPs