From MVP to v1: scoping your first 90 days

We build a lot of first products, and we have noticed a pattern in the ones that survive: the teams treat launch day as the start of a 90-day plan they wrote before launch, not as the finish line. The ones that struggle have the same pathology in common — they planned the MVP and then improvised everything after it.

The MVP trap

An MVP is a hypothesis test, but most MVPs are actually prototypes wearing a business plan. You can tell the difference by one question: if the data comes back negative, does the product have a documented path to pivot, or does it have a folder of TODO comments? The trap is structural — the shortcuts you took to ship are now load-bearing, and every new feature compounds on them.

MVP code is not disposable by definition. It is disposable by habit. The habit is what you should be breaking, not the code.

The 90-day split: prove, harden, grow

We scope the first 90 days after launch into three phases of roughly a month each. The phases have different success criteria and — crucially — different engineering postures.

• →Days 1–30: Prove. Full speed on the core loop. You are watching activation and week-2 retention. Tech debt is allowed; the goal is signal, and every pivot you avoid is worth a month of cleanup.
• →Days 31–60: Harden. The data has spoken — usually by telling you which shortcuts users exploit daily. Now you pay down the three shortcuts with the highest traffic: auth, payments, data integrity. Tests appear on the paths users actually walk.
• →Days 61–90: Grow. With the core proven and stable, growth features get built on something that can hold them. Onboarding flows, integrations, the self-serve path.

The one-metric gate between phases

Each phase has exactly one metric that gates the next. Not a dashboard — a number. Prove is gated by week-2 retention (if nobody comes back, hardening polish is wasted polish). Harden is gated by incident count and p95 latency (stability is the gate to growth spend). Grow is gated by activation-through-conversion. When a gate fails, the plan says what happens: a pivot sprint, not a vibes discussion.

# 90-day plan template (what we write for clients)

## Phase 1 — PROVE (days 1–30)
Gate: week-2 retention ≥ 25%
Build: [core loop features]
Skip: admin tooling, edge cases, integrations

## Phase 2 — HARDEN (days 31–60)
Gate: < 1 Sev-2 incident/week, p95 < 400ms
Build: [the 3 scariest shortcuts], tests, observability
Skip: new surface area

## Phase 3 — GROW (days 61–90)
Gate: trial → paid ≥ 4%
Build: onboarding, self-serve billing, [growth bets]

What to cut, and what never to cut

The cut list is easy to write and hard to follow: admin panels (until phase 3), edge cases (log them, do not handle them), and any integration that is not on the critical path of the core loop. The never-cut list is shorter but non-negotiable: auth done properly, payments done properly, and database migrations that are reversible. Those three are exactly the shortcuts that turn a phase-2 "harden" sprint into a phase-2 rewrite.

If you are about to launch and do not have this plan, write it this week — a rough one beats an improvised one. And if you want an outside pair of eyes on scope before kickoff, that is literally the cheapest service we sell: the discovery sprint exists so that the 90-day plan is written with data, not optimism.