Most MVPs that miss their launch date don't miss because the developer was slow. They miss because the scope was never nailed down in the first place. The work expanded the way vague work always expands — a feature per conversation, an integration per standup, a "while we're at it" per week.
This is the scoping process I use with clients to ship in 12 weeks or less. It's not fancy. It's written, boring, and effective.
The one rule that makes or breaks it
Everything you want in the MVP is on one page of text, before a line of code is written. If you can't get it on one page, you don't have an MVP — you have a product.
That's not a clever framing. It's a constraint. Ten features fit on a page. Fifteen don't. The exercise of cutting to ten is where most of the good decisions happen.
The one-page brief — what goes on it
Five sections. In this order.
1. The one sentence.
"A platform where [who] can [do what] so that [outcome]."
Fill those three blanks and the rest of the brief falls into place. If you can't fill them, the product isn't clear enough yet. Spend a week on that sentence before you spend anything else.
2. Three user flows. No more.
Pick the three flows that, if missing, make the product useless. Everything else is phase 2.
Examples from a real ticketing platform:
- Organizer creates an event and sets pricing
- Buyer browses events, picks seats, pays
- Organizer scans tickets at the door
Three flows. That's the MVP. Account recovery, refund flows, invoicing, multi-organizer permissions — all important, all phase 2.
3. The single success metric.
One number. Not three. Not a dashboard.
"We'll know this worked if we have 50 paid events in the first 90 days."
The value of a single metric isn't measurement — it's decision-making during the build. Every tradeoff ("should we add X?") gets measured against that one number. If X doesn't move the metric, X is out.
4. The integrations that must work on day 1.
Stripe. Resend. Supabase. Sentry. Whatever your list is.
The discipline here: each integration on the list costs 3–8 days of real work including edge cases, webhooks, and the production failure modes nobody warns you about (I wrote about six of those for Stripe). A "small" integration doesn't exist. Every line item on the integration list pushes launch by a week.
5. The deadline and the reason.
"Launch by September 15 because we're demoing at conference X." "Launch by October 1 because funding closes and we want to show traction."
The reason is important. If the deadline has no reason, it's a wish, and wishes slip. If the reason is real (conference, funding, seasonal window), the deadline has teeth, and the scope gets cut to match.
One page. You can write it in an afternoon. If you need two afternoons, fine — but don't start the build until it exists.
The scope cuts that hurt and work
Founders come in with ten features they "need." The developer's job is to find the five that matter and cut the rest politely. Some cuts founders regret, most they don't. Here are the ones that reliably don't hurt:
- Roles and permissions beyond 1-2 levels. Ship with "owner" and "user." Add admins in phase 2.
- Email templates that look great. Ship plaintext transactional emails. Design them in phase 2.
- Onboarding flows and tutorials. Ship with a 3-step signup. Add Intercom-style tours when you know which steps people get stuck on.
- Admin dashboards. Ship with direct-to-DB access for you. Build a proper admin UI in phase 2.
- Analytics beyond the core metric. PostHog basic setup is 20 minutes. A custom analytics dashboard is two weeks. Ship basic.
- Mobile app. Ship responsive web. Add a native shell when you have 1K users, not before.
- Internationalization. Unless your market is inherently multilingual (my own E7 work is tri-lingual because it has to be), ship in one language.
The cuts founders don't want to accept but shouldn't fight:
- Custom design system. Tailwind + shadcn/ui gets you 80% of the polish for 5% of the work. You can build a design system when your brand is a brand.
- Multi-tenancy beyond what Stripe gives you for free. Real multi-tenant architecture is 4 weeks of infrastructure work. Most MVPs don't need it.
The artifacts that keep scope honest after kickoff
The brief exists. Now: how do you keep it from growing in week 3 without you noticing?
Artifact 1: A written change-request doc, per change.
Any feature not in the original brief goes through a 5-line doc: what, why, which milestone it replaces or slips, new price if any, signed by both sides. Five lines. Not a novel. But written.
Most scope creep happens because a founder says "oh and also…" in a Zoom call and the developer nods. Nothing is signed, nothing is costed, and by week 7 the "also" bucket is bigger than the original MVP.
Artifact 2: Weekly Friday demo. Non-negotiable.
Every Friday, there's a staging URL you can open. You click around, you try things, you find the thing that's broken, and we talk about what ships next week.
This does two things:
- It forces the work to be shippable every week — not someday-finished-in-a-big-bang.
- It gives the founder a moment to see what's real versus what they imagined. Nothing cures feature creep like using your own product.
Artifact 3: Milestone invoices tied to demoable work.
Every 2-week milestone has a demo and an invoice. You don't pay if the demo isn't there. The developer doesn't work ahead if the demo isn't approved. Both sides have skin in the game.
The 12-week structure that usually works
A rough template, adjusted per project:
Weeks 1–2: Foundation. Repo, CI, auth, Stripe stub, database schema, staging deploys. You click around a shell. Nothing "feature-y" yet, but every rail is laid.
Weeks 3–4: Flow 1 (the most important user flow) end-to-end. Ugly but working. You can use it on staging.
Weeks 5–6: Flow 2 end-to-end. Flow 1 gets polish.
Weeks 7–8: Flow 3 end-to-end. Integrations (Stripe webhooks, Resend, whatever) get hardened.
Weeks 9–10: Polish. Copy. Error states. Loading states. The things that make a product feel like a product instead of a prototype. SEO basics. Lighthouse pass.
Weeks 11–12: Production deploys, Sentry wired up, launch checklist, content, last pass of bugs. Soft launch.
This shape flexes. If your flow 1 is complex (Stripe Connect with split payments, custom booking calendar), it eats more weeks, and something else gets cut. But the shape — foundation → flows → polish → launch — is reliable.
What actually blows up 12-week plans
In order of frequency from my own projects and what I've heard from peers:
- Late design. Design arriving in week 5 instead of week 1 kills sprints 1–2 of productivity. Get Figma or equivalent done before dev starts. Even rough.
- "One more feature" in week 9. This is the classic. Scope is cut, dev is on track, launch is visible, founder gets ambitious: "let's also do X." Every feature added in the last third of a project costs 2–3x what it would have cost in month 1. Say no.
- Approval bottlenecks on the founder side. You sent the demo Friday. Feedback comes Thursday. That's 6 days of implicit approval that wastes half of next sprint. Founders have to respond within 48 hours or the cadence breaks. Put that in the contract.
- Integration surprises from third parties. Stripe rejects you for KYC. Apple takes 11 days to review. Google disables your OAuth app. These happen. Build a 2-week buffer into the 12 and assume you'll need at least one of them.
- "We should really rewrite the auth flow" midway. You won't. You'll ship the boring flow. Rewrite it when you have paying users.
The contract clauses that protect scope
If you're writing (or signing) a fixed-scope contract for a 12-week build, these clauses save you:
- The brief is the spec. "The brief dated [X], attached as Appendix A, is the complete scope. Anything not in the brief is a change request."
- Change requests in writing. "Scope changes require a written change request, signed by both parties, including price and timeline impact."
- Demo approval cadence. "Deliverables are reviewed within 48 hours of milestone delivery. Non-response after 5 business days constitutes approval."
- A clean exit. "If either party terminates, all code delivered to date is owned by the client, and the developer is paid for completed milestones only."
None of these are adversarial. They're the clauses that let both sides relax and focus on shipping.
The shortest scoping rule I know
If you can't describe your MVP in three user flows, one success metric, and five integrations — it's not an MVP yet. It's a dream. The work before the build is the work of turning the dream into a brief.
Most founders resist that work. Spending an afternoon writing a brief feels less productive than getting someone coding. It isn't. The afternoon writing the brief is worth 3 weeks of saved implementation. Every project I've shipped on time had a brief done before the first commit. Every project that slipped, didn't.
I offer a fixed-price discovery engagement (1 week, €2.5K) where I write this brief with you. At the end you have a one-pager, a scope document, and a fixed quote for the build. If the build doesn't happen, the brief is still yours to take to anyone else. Book the discovery call.