How to Scope an MVP Before You Build (a Working Checklist)

Scope an MVP by defining one job-to-be-done, six or fewer features, a one-page data model, integrations you already pay for, and a written OUT list before anyone writes code. If you cannot fill that checklist, you are not ready for a fixed quote—you are ready for more customer interviews.

Builders who skip this bleed money in change orders. Lab Twelve scores clarity in the scope chat before pricing because vague scope is the main reason fixed-price projects fail.

Why MVPs balloon

MVPs fail scope when founders bundle:

• "Nice to have" features that are actually v2
• Admin dashboards nobody asked for
• Auth roles for a user base that does not exist
• AI features that are demos, not workflows

Each addition looks small. Together they move a $1,950 Micro App toward a $6,950 MVP Sprint—or beyond. See the 2026 cost guide for tier boundaries.

The pattern is always the same: founders describe a "simple" app, then add admin, then add roles, then add analytics, then add AI. Each layer is defensible in isolation. Together they are a different product than the one priced at kickoff.

One job-to-be-done, defined tightly

A job-to-be-done is not a feature list. It is a sentence:

"When [situation], I want to [motivation], so I can [outcome]."

Bad: "We need a project management app." Good: "When I onboard a freelance designer, I want to share briefs and collect deliverables in one place, so I can stop chasing email attachments."

If you cannot write the good version, talk to five users before /start. The scope chat will ask anyway. Arrive with a draft.

| Vague job | Scoped job | |-----------|------------| | "CRM for real estate" | "Agent logs a lead, assigns follow-up, sees status in one list" | | "Marketplace" | "Seller lists one SKU; buyer pays with Stripe; seller gets email" | | "AI assistant" | "User uploads PDF; app returns three bullet summary" |

One job. Not three personas with three jobs unless you are buying MVP Sprint and mean it.

The clarity score idea

Clarity is measurable. Can you answer every checklist item without "probably" or "we might need"?

Lab Twelve's scope chat computes clarity from filled fields: screens named, auth defined, integrations listed, exclusions written. Low clarity triggers more questions or manual review—not a fake low price that grows at kickoff.

Rough clarity bands:

| Score signal | What it means | |--------------|---------------| | High | Every checklist row filled; OUT list has ≥3 items | | Medium | Job-to-be-done clear; features fuzzy on edges | | Low | "Platform" language, no OUT list, unknown auth | | Too low | Manual review or more discovery before quote |

Clarity is not pedantry. It is how fixed-price development survives contact with reality. A quote without clarity is a loan.

Scope-lock and why skipping it bleeds money

Scope-lock means the quote matches a written spec at checkout. After lock, new work is additive.

Without lock, every sprint becomes negotiation. "I thought analytics was included" is a $75k agency sentence. Fixed-price studios die on that sentence unless scope was explicit.

Read the founder's fixed-price guide for contract red flags. For founder MVPs specifically, see our MVP development lander.

Printable checklist

Copy this block into your notes. Fill it before /start.

MVP SCOPE CHECKLIST — Lab Twelve

[ ] ONE JOB-TO-BE-DONE
    User type: _______________________
    Job: When ____________, I want to ____________, so I can ____________.

[ ] FEATURES (≤6 — name each screen or capability)
    1. _______________________
    2. _______________________
    3. _______________________
    4. _______________________
    5. _______________________
    6. _______________________

[ ] DATA MODEL (one page — list entities and key fields)
    Entity: ____________  Fields: _______________________
    Entity: ____________  Fields: _______________________
    Entity: ____________  Fields: _______________________

[ ] INTEGRATIONS (only what you already pay for)
    [ ] Stripe  [ ] Email (Resend/SendGrid)  [ ] Storage (S3/R2)
    [ ] Auth (Google/OAuth)  [ ] Other: _______________________

[ ] EXPLICITLY OUT (write "no" items — this section saves money)
    [ ] Native mobile apps
    [ ] Multi-tenant / white-label
    [ ] Advanced admin analytics
    [ ] AI chat / LLM features
    [ ] Custom: _______________________

[ ] DONE DEFINITION
    Deployed URL: _______________________
    Test user can: _______________________

If OUT is empty, you have not scoped. You have wished.

Data model on one page

You do not need ERD software. You need entities and fields a builder can implement without guessing.

Example for a consultant booking tool:

| Entity | Key fields | |--------|------------| | User | email, name, role (client/admin) | | Booking | userId, slot, status, notes | | Availability | adminId, weekday, startTime, endTime |

If you cannot list entities, you are still in discovery. That is fine. Do not lock a quote yet.

Relations matter: one-to-many, who owns what row, what gets deleted on cascade. Ambiguity here becomes migration bugs later.

Integrations: only what you already pay for

Every integration is a scope line item. Stripe, email provider, object storage, OAuth: each needs credentials, test mode, error handling, and often webhooks.

Rule: if you do not have an account and API key today, v1 probably should not depend on it. Manual CSV export beats half-wired Salesforce.

| Integration | v1 default | v2 candidate | |-------------|------------|----------------| | Payments | Stripe Checkout if revenue day one | Subscriptions, invoicing | | Email | Resend/SendGrid transactional | Marketing automation | | Auth | Email magic link | Google OAuth, SAML | | Storage | S3/R2 for uploads | CDN transforms |

Write custom integrations in OUT unless you have budget for add-ons. See AI-native scoping for how structured fields map to price.

Walk through with the scope chat

The chat at /start asks these questions in order. You do not need perfect answers—you need honest ones. "No payments in v1" is a valid answer. Silence is not.

When the checklist is complete, you get a tier mapping and fixed price from pricing. Read how the scope chat works for the pipeline.

After the checklist: tier mapping

| Signal | Likely tier | |--------|-------------| | Single page, form, deploy | Launch Page ($995) | | ≤5 screens, basic auth, CRUD | Micro App ($1,950) | | ≤12 screens, roles, uploads, email | Business App ($3,950) | | Full-stack, jobs, Redis, prod deploy | MVP Sprint ($6,950) |

If your checklist has eight features and three integrations, you are not negotiating down—you are descoping or accepting a higher tier.

Common scope lies founders tell themselves

"We need admin analytics for launch." No—you need one CSV export or a SQL query.

"Everyone will use Google login." Maybe. If v1 is five beta users, email magic links might suffice.

"We'll add payments later." Fine—write it in OUT so nobody wires Stripe prematurely.

"AI chat is core." Prove it. If the job-to-be-done works without LLM spend, v1 probably should too.

Feature count discipline

Six features is a ceiling, not a goal. Many good MVPs ship with three screens and email notifications. One active request thinking applies after launch too: small tickets clear faster.

Scope review with stakeholders

Send the checklist to co-founders before /start. Misalignment discovered at quote lock is cheaper than misalignment discovered at deploy.

One decision-maker should own scope sign-off. Committees add features; they rarely remove them.

Send the filled checklist as a single doc. Disagreement before quote lock costs an hour. Disagreement after deploy costs a sprint.

Descoping without shame

Cutting scope is not failure. Shipping a three-screen tool that one customer pays for beats shipping twelve screens nobody uses.

Tactics that work:

• Move admin to a SQL query or Retool for month one
• Replace roles with a single admin flag
• Ship email notifications before in-app notification center
• Defer AI to v2 when the job-to-be-done works manually

One active request discipline after launch helps you ship cuts incrementally instead of debating a monolith.

Post-launch: scope for lane tickets

After v1, each dev lane request should repeat a micro-checklist: acceptance criteria, OUT for this ticket, deploy definition.

The honest take

A tight MVP feels embarrassing to show investors. That is a feature. If you are embarrassed because it is unclear, not because it is small, cut scope harder.

Investor demos can wait. Paying customers cannot be faked with admin charts.