Launch Readiness

"Done coding" is not "ready to ship." Before a change reaches users, confirm you can release it safely, see if it breaks, undo it fast, and tell people what changed. The riskier the change, the more this matters — a silent 100% deploy with no rollback is a bet, not a release.

Launch readiness is the go/no-go gate at the Ship phase. It chains verification from Build and Review into production safely — not a substitute for [[browser-checks]], [[review-gate]], or [[pipeline-ops]], but the layer that asks "what happens when this hits real traffic?"

Pairs with [[migration-path]] for deploy order and data rollback limits, [[observability]] for signals before and after, [[git-flow]] for tags and hotfix branches, [[incident-response]] if launch degrades prod, [[hardening]] for security-sensitive launches, and [[decision-docs]] / changelog for communicated changes.

When to Use

• Before deploying a feature, fix, migration, or config change to production
• Expanding rollout — canary → 10% → 50% → 100%
• Cutting a release tag or promoting a build to users
• Anything user-visible, hard to reverse, or on a critical path (auth, payments, checkout)
• Setting up launch conventions for a team
• Go/no-go meeting before a scheduled release window

Light pass for low-risk changes (copy tweak behind flag, internal-only tool). Full pass for data migrations, payment flows, auth, and large audience flips.

Skip only for changes with zero production surface (local tooling) — rare for this skill.

Process

Work in order. Don't deploy until rollback and observability are in place for the risk level.

1. Classify risk — depth of readiness follows risk

Under-preparing a high-tier launch causes incidents; over-preparing every typo wastes time — classify first.

2. Confirm it works where it will run

Production differs from your laptop. Before go:

• [ ] CI green on the release commit ([[pipeline-ops]])
• [ ] Merged PR reviewed ([[review-gate]]); security pass if needed ([[hardening]])
• [ ] Staging / preview — same commit or artifact you'll promote, not an older build
• [ ] Production-like data where it matters — large accounts, edge locales, legacy rows
• [ ] Config & secrets — env vars, feature flags, API keys in target environment (not just code)
• [ ] Dependencies — migrations applied, third-party keys live, queues/topics exist
• [ ] UI — [[browser-checks]] on staging at prod config; critical paths exercised

Staging passed is necessary, not sufficient — scale, cache, and data shape differ in prod.

3. Plan deploy order — sequence matters

Wrong order breaks deploys mid-flight ([[migration-path]]):

Typical safe order:
1. Expand DB/schema (backward-compatible migration)
2. Deploy backend that tolerates old + new schema
3. Backfill data (batched, monitored) if needed
4. Deploy frontend / enable flag for new behavior
5. Contract phase later — remove old path when usage zero

Document dependencies: "API v2 before mobile app 2.1", "migration 0042 before app deploy."

Maintenance window only when unavoidable — document start/end and rollback trigger.

4. Plan the rollout — gradual beats instant

Prefer contained exposure over flipping everyone at once:

Define steps and pauses:

10:00 — deploy build + flag OFF (dark)
10:15 — enable internal dogfood (flag: staff)
11:00 — 5% users, watch 30 min
12:00 — 50% if metrics green
14:00 — 100% or halt

Who watches each step — name a person, not "the team."

No flag/canary available for high-tier change → smaller audience first (beta group, single tenant) or explicit risk acceptance documented.

5. Rollback — tested, documented, data-aware

Rollback is not "we'll revert git." Define exact undo for each layer:

Test rollback before launch in staging:

• Deploy new → verify → rollback → verify old behavior restored
• If migration can't roll back, forward-fix plan is mandatory — not optional hope

Document in release notes:

Rollback: flip `checkout_v2` flag OFF + redeploy v1.4.2 if needed.
Migration 0042 is expand-only — rollback does NOT remove column.

6. Observability before launch — not after

You must know if the launch broke something ([[observability]]):

Define healthy for this change:

Checkout v2 launch:
- p95 POST /orders latency < 500ms
- error rate on /orders < 0.5%
- conversion rate within 5% of baseline (business metric)

Before go-live:

• [ ] Metrics emitted for new code paths — counters, latency histograms
• [ ] Dashboard panel or saved query for launch signals
• [ ] Alerts on symptom thresholds — error spike, latency SLO, queue depth
• [ ] Logs structured with correlation id; no secrets ([[hardening]])
• [ ] Trigger test — force an error in staging; confirm alert fires (or would fire)

During launch: same dashboard open; don't discover gaps when users complain.

7. Go / no-go criteria

Explicit hold conditions — anyone can call halt:

GO if:
- CI green, staging sign-off, rollback tested
- On-call aware, dashboard ready
- No open blocker bugs

NO-GO if:
- Unresolved migration risk
- Rollback untested
- Missing alerts on critical path
- Key person unavailable with no backup

Scheduled release with NO-GO → postpone, don't "YOLO" because the calendar says Tuesday.

8. Communicate — internal and external

Launch owner — single name for "is this launch still go?" during the window.

External comms factual — don't promise what isn't shipped yet.

9. Watch through rollout — don't deploy and leave

Active monitoring through each rollout step:

• Error rate, latency, saturation — compare to pre-launch baseline, not zero
• Business metrics lag technical — know the delay (conversion may be T+1h)
• Soak period after 100% — 30–60+ min for high tier; watch for cache refill, retry storms
• Ready to roll back — IC or launch owner can call it ([[incident-response]])

Checklist after each ramp:

5% ramp: errors flat, p95 +12ms (acceptable), proceed
50% ramp: error spike on payment — HALT, flag OFF, incident declared

10. Post-launch — close the loop

Within 24–48 hours:

• [ ] Metrics vs success criteria — ship decision validated or learnings captured
• [ ] Flag cleanup plan — remove old path after stable ([[migration-path]])
• [ ] Docs — user docs, API docs, runbook updated ([[decision-docs]])
• [ ] Changelog / release notes published
• [ ] Retro if launch was rocky — action items tracked ([[incident-response]])
• [ ] Remove temporary launch dashboards/alerts or tune thresholds for steady state

Launch isn't done at deploy — it's done when stable and documented.

11. Scenario playbooks

Feature behind flag

Deploy dark → internal ON → staged % → full → remove old path in follow-up PR.

Database migration + code

Expand migration deploy → app deploy (dual-read) → backfill job monitored → later contract migration.

Breaking API change

New version live alongside old → migrate clients → deprecate old with metrics ([[interface-design]], [[migration-path]]).

Payment / checkout change

High tier: canary, payment test cards in prod monitor, rollback = flag + revert, finance notified.

Mobile app + server

Server backward-compatible first → app store release → force-upgrade only if unavoidable.

Config-only change

Diff config in staging → deploy → watch dependency that reads config → rollback = previous config rev.

Hotfix during incident

Branch from prod tag ([[git-flow]]); minimal fix; accelerated launch with single watcher; postmortem after ([[incident-response]]).

Low-risk copy / UI polish

CI + staging smoke + owner watches deploy — skip full canary if tier is low and flag exists.

Common Rationalizations

• "It worked in staging." — Prod data, scale, and config differ; verify and watch real traffic.
• "We can roll back if needed." — Only if rollback exists, is tested, and handles data.
• "Add monitoring after launch." — You're blind exactly when it matters most.
• "Just ship to everyone." — Canary/flag turns outage into a blip.
• "Rollback is redeploy — easy." — Migrations and cache often make it hard; test it.
• "Alerts exist somewhere." — Confirm they fire on this change's failure mode.
• "Support will figure it out." — Brief them before users hit the change.
• "We'll write release notes after." — Notes before launch clarify what you're risking.
• "Go/no-go is bureaucracy." — Five minutes prevents multi-hour incidents.

Red Flags

• Deploy straight to 100% with no flag, canary, or beta cohort (high/medium tier)
• Rollback never tested; migration with no forward-fix plan
• No metrics/alerts on the changed code path before traffic hits it
• Deploy and walk away — nobody watching dashboard during ramp
• Config/secrets differ between staging and prod untracked
• Deploy order wrong — code before backward-compatible migration
• Release notes / support brief missing for user-visible change
• "Healthy" undefined — no way to know if launch succeeded
• Forced deploy because of calendar despite open NO-GO criteria
• Rollback plan is "fix forward" only with no time estimate
• Launch owner unnamed; on-call unaware
• Post-launch flag and dead code never cleaned up

Verification

• [ ] Risk tier classified; readiness depth matches
• [ ] CI green; staging verified on release artifact; config/secrets confirmed ([[pipeline-ops]], [[browser-checks]])
• [ ] Deploy order documented; migrations expand-before-code ([[migration-path]])
• [ ] Rollout steps defined — flag/canary/%, pauses, watchers named
• [ ] Rollback tested — code, flag, config; data limits documented
• [ ] Healthy signals defined; metrics, dashboard, alerts live and tested ([[observability]])
• [ ] Go/no-go criteria explicit; launch owner assigned
• [ ] Support/stakeholders briefed; changelog/release notes ready ([[decision-docs]])
• [ ] Active watch through ramp + soak; halt criteria enforced
• [ ] Post-launch: metrics vs success criteria; docs updated; cleanup planned