The studio's default MVP cadence is six weeks from kickoff to a TestFlight build a partner can hand to their first real users. Six weeks is honest because the studio cuts ruthlessly to keep it.
Week 1–2 — Design sprint
Workshops, interviews, a clickable Figma prototype. The outcome of week two is a single confident spec: what's in, what's out, what the success metric is. No engineering until the spec is signed.
Week 3 — Scope freeze
Anything that surfaces after week three goes to a "next sprint" list, not into scope. This is the rule that makes six weeks honest. Every studio that misses MVP deadlines does so because scope crept after the start.
Week 3–6 — Build
Production code from sprint one — no throwaway prototypes. Each fortnight ends with a demo build the partner can install. The cadence forces ugly truths to surface early: if a flow doesn't feel right on day 10, we still have time to change it.
What we cut to keep the deadline
- Settings screens — defaults that work for 80% of users, defer the rest
- Onboarding videos — they take longer than the feature they explain
- Edge-case empty states — ship with placeholder, polish in sprint 2
- Admin tooling — Firestore console + a one-off CLI gets us through launch
- Analytics dashboards — Firebase Analytics + BigQuery for the first month, custom later
The rule that makes six weeks honest
Six weeks is not a slogan, it is a scope contract. The thing that makes it real is the week-three freeze: anything that surfaces after week three goes to a next-sprint list, not into the current build. Every studio that misses an MVP deadline misses it for the same reason — scope crept after the start. Holding the freeze is unglamorous and it is the entire trick.
What gets cut, and why that is fine
- Settings screens — sensible defaults for 80% of users now, the rest later
- Edge-case empty states — placeholder now, polish in sprint two
- Admin tooling — the database console and a CLI get you to launch
- Custom analytics dashboards — off-the-shelf analytics first, bespoke later
None of these block a user from reaching the product's core value, which is the only thing an MVP has to do. Cutting them is not lowering quality — it is refusing to spend week-one budget on week-ten problems.