Most MVPs don’t fail in engineering. They fail in scoping — too many workflows, premature infrastructure, features without evidence. This is the exact 10-day process we run before writing production code.
Days 1–2: Extraction call
One 30-minute call. Goal: a single must-win workflow and 3–5 user stories that serve it. Everything else goes to a written non-goals list on the spot. If the founder can’t name the one workflow that matters, that’s day 1’s work — not day 30’s regret.
Output: must-win workflow, story list, non-goals list.
Days 3–5: Slice planning
Each story becomes 1–2 vertical slices (UI + API + data + AI, priced as a unit). Slices are ordered by risk, not convenience — auth, AI quality, third-party integrations first. A typical MVP is 3–5 slices across 4–8 weeks.
Output: ordered slice list with owners and rough sizes.
Days 6–8: Fixed proposal
Every slice gets a fixed price and ship date. The founder approves slice one to start; the rest when confident. No hourly billing, no open-ended estimates.
Output: proposal with per-slice price, date, and acceptance criteria.
Days 9–10: Review and freeze
Walk through the proposal together, adjust once, then freeze. Post-freeze changes become new slices — priced, not smuggled in.
Output: signed scope, kickoff date, staging access.
The artifacts
- MVP Scope Worksheet — the template: user, problem, must-win workflow, non-goals, risks, acceptance, launch metric.
- Slice acceptance criteria — each slice lists what “demoable” means before work starts.
- Backlog — every deferred idea, visible, so “no” feels safe.
Why this works
Small slices make failure cheap, demos make progress visible, and non-goals make “no” a decision instead of a fight. Founders never wonder what they’re paying for — they approved it slice by slice.
See it applied: Build vs Buy: Internal Tools used this process, and the CRM case study shows slices shipping to a 95% workflow reduction.
