How to Scope an MVP: The Checklist That Makes Your Quote Honest

Developers and agencies quote the brief you give them. If that brief is ambiguous — and most are — each vendor fills the gaps differently. One interprets "user management" as email + password login. Another builds a full role-based access control system with org hierarchies. One includes mobile. Another assumes web only.

The result is three quotes that appear to describe the same product but don't. You pick the cheapest one — which was scoped most narrowly — and discover the gaps in week 4 when the change orders start coming in.

The antidote is a brief that leaves nothing important to interpretation. The ten items below are the ones that matter most.

The scoping checklist

Work through these ten items before you talk to any vendor. The answers should fit on two pages. If they don't, your scope isn't scoped.

1. The hypothesis (one sentence)

"We're testing whether [specific user] will [do the specific thing] to [get the specific outcome]."

Examples of a hypothesis:

• "We're testing whether Dubai-based property managers will pay AED 500/month to reduce the time they spend on maintenance request tracking."
• "We're testing whether SME finance teams will use an automated reconciliation tool if it saves 4+ hours per week."

Non-examples (aspirations, not hypotheses):

• "We want to build the best property management platform in the UAE."
• "We're disrupting how SMEs think about finance."

If you can't write the hypothesis in one sentence with a specific user, a specific action, and a specific outcome — stop. The scope conversation is premature.

The framing I find more useful: don't ask "will this work?" — identify the one reason it wouldn't, and scope the MVP to find evidence against that specific concern. It changes what you build and what you measure.

2. The specific user (one person, not a segment)

Name the first person who would use your MVP if it existed today. Not "SME finance teams." A specific description: the finance manager at a 50-person trading company in Dubai, currently doing reconciliation in Excel, no current software subscription, makes decisions independently without IT approval.

The more specific this person is, the more focused your scope becomes. Every feature decision gets easier when you ask "does this help that specific person get to the outcome?"

3. The core action (the one thing they must be able to do)

Strip your idea down to one action. Not "manage their properties" — "log a maintenance request and see its current status." Not "run their business finances" — "reconcile this month's bank statement against their invoices."

One action. If the MVP can't do that one thing end-to-end, it isn't ready to ship. If it can do that one thing end-to-end, it might be ready — even if it can't do anything else.

4. The success metric (how will you know it worked?)

Before you build anything, define what "the MVP worked" means. Quantify it.

Examples:

• 20 paying users within 60 days of launch
• 10 users complete the core flow at least 3 times in the first month
• 30% of waitlist signups convert to a paid trial

Vague success criteria ("positive feedback," "good engagement") produce vague learnings that don't tell you whether to double down or pivot.

5. The timeline constraint (when do you need feedback?)

Not "when do you want to launch" — when do you need the learning from the MVP? There's usually a real driver: a fundraise conversation in four months, a market window before a competitor ships, a co-founder's current employment ending. Name it.

This constraint is the most useful way to scope out of features. "We have 10 weeks before the investor meeting" is clearer to everyone than "we want to move fast."

6. The budget ceiling (the hard number)

The number that makes the project impossible. Not your preference — the ceiling beyond which the project doesn't happen.

If the ceiling is USD 15,000, the scope must fit in USD 15,000. If it doesn't, either the ceiling is wrong (more budget exists but wasn't disclosed) or the scope needs to be cut further. Both are fine to surface early. Neither is fine to discover in week 6.

7. Technical constraints (what already exists)

• Existing code or infrastructure to build on or integrate with
• Third-party APIs that must be included (CRM, payment processor, WhatsApp, government APIs)
• Platforms the product must run on (web only? iOS? Android? Must work offline?)
• Data sources you own and want to use (internal database, spreadsheet, document repository)
• Anything that's been started and can't be thrown away

These constraints are scope inputs, not scope additions. A vendor who doesn't know about your existing Salesforce integration — and discovers it in week 3 — will send a change order.

8. What's explicitly out of scope

List five things you might want eventually but are not building in this MVP. Write them down, agree on them with your team, and include them in the brief.

Examples:

• Native mobile app (web only for MVP)
• Admin panel (we'll query the database directly)
• Multi-language support (English only for MVP)
• Analytics dashboard (we'll use Google Analytics)
• Email marketing integration (manual follow-ups for first 50 users)

The purpose of this list isn't to permanently exclude these things — it's to prevent them from being added "while we're at it." Every "while we're at it" addition extends timeline, adds cost, and delays the learning.

9. Launch conditions (what does "done enough to ship" look like?)

Not "what does v1 look like" — what does "ready for real users" mean? Be specific.

Examples:

• Core flow works end-to-end (sign up → onboard → do the main thing → see the result)
• No data loss bugs in production testing
• Works on current Chrome, Safari, and mobile web
• Payment flow works (users can pay)
• Basic error monitoring in place so we see crashes before users report them

This list is what the vendor is being held to at launch. If it isn't defined upfront, you and the vendor will argue about whether the product is "done" at the end of the engagement. Define it now.

10. Handoff requirements (who maintains it after launch?)

When the engagement ends, who owns the code? Who makes changes? Do you have a developer on your team who will take it over, or will you need ongoing support from the agency or developer who built it?

The answer changes the codebase significantly. A product handed off to an in-house developer needs excellent documentation and a knowledge-transfer session. A product that stays with the vendor needs ongoing support terms in the contract from day one.

Neither answer is wrong. But assuming it'll sort itself out is how you end up dependent on a vendor who knows your codebase and you don't.

Turning the checklist into a brief

Once you have answers to all ten items, write them up in a single document — not a Notion database, not a Miro board. Two pages maximum. Send it to every vendor you're evaluating and ask them to quote against it without making additional assumptions — or to flag which items they need to clarify before they can quote.

Vendors who come back with clarifying questions are usually the better ones. Vendors who quote immediately without questions made assumptions. Ask them what they assumed.

The change-order trap and how to avoid it

Most MVP overruns aren't caused by developers building slowly or incorrectly. They're caused by the scope growing after the project starts.

The mechanism is always the same: someone realizes in week 4 that a feature they assumed was included isn't in the brief. Or a stakeholder joins the weekly call and says "this is great, can we also add X?" Or the brief says "user management" but doesn't specify what happens when a user forgets their password.

Every scope gap is a change order waiting to happen.

Three ways to close gaps before they become change orders:

1. Write the "out of scope" list. A written list of what's not being built — agreed on by both sides — is the most effective change-order prevention tool that exists. When someone asks "can we add X?" you point to the document. If X is on the out-of-scope list, it's a reminder of a deliberate decision — with the reason attached. If it isn't mentioned anywhere in the brief, it's a scope addition that needs to be scoped and priced.

2. Define the change-order process upfront. In the contract: what counts as a scope addition, how it gets estimated, what the approval process is. This doesn't prevent changes — it makes them deliberate. Surprises happen when changes are made casually without a clear agreement.

3. Build in a contingency. Budget a 15–20% buffer for genuine unknowns. Every project has them. Some integrations are harder than expected. Some user flows turn out to need an extra step. A buffer lets you absorb these without a renegotiation; a fully spent budget means every unexpected item is a fight.

Scope for learning, not for launch

The instinct when scoping an MVP is to cut features until the budget fits. That's the right direction — but cut with a purpose.

The question isn't "what can we fit in the budget?" It's "what's the minimum that honestly answers our hypothesis?"

Sometimes those are the same. Sometimes cutting to the budget leaves you with a product that can't answer the hypothesis — and you've spent USD 15,000 on an experiment that can't produce a result. A USD 25,000 scope that answers the question is better than a USD 15,000 scope that doesn't.

Know what you're testing. Scope ruthlessly for that thing. Don't scope for everything else.

A two-page brief with one clear hypothesis is the most useful thing you can write before a vendor conversation. It determines what gets built, what it costs, and whether the thing you spend your budget on actually answers your question.

For how I work through scope, timelines, and pricing for MVP engagements — including the milestone payment structure — see the MVP Development service page.