Release Readiness

Release Readiness

The purpose of a gate is to make a decision explicit rather than implicit. Shipping with known gaps is legitimate — shipping without knowing what they are is not.

Produce one of three verdicts, in writing:

GO              No blockers. Ship.
GO WITH RISK    Named, accepted, owned risks. Ship, with mitigations listed.
NO GO           Named blockers. Do not ship until these close.

Never soften a NO GO into "mostly ready". If a blocker is real, say so in the first line and name it.

The blockers — any one of these is NO GO

These are not judgement calls. Each one causes a breach, data loss, or a legal exposure that the launch cannot be undone from.

• A secret is in the repository or its git history. Rotate first, then purge.
• Any user can access another user's data. Test it: authenticate as A, request B's resource.
• No backups, or backups that have never been restored.
• Personal data is processed with no privacy policy, or a policy that omits a processor actually receiving data.
• No way to delete user data when the policy or the law says there is.
• Payments where amounts are computed or trusted from the client.
• A webhook that mutates state without verifying its signature.
• String-interpolated SQL on a route reachable by a user.
• Debug mode enabled, or stack traces returned to clients.
• No rollback path that anyone has ever executed.
• A migration with no tested reverse running against production data.
• A known critical vulnerability in a reachable dependency.

If any box is unticked, the verdict is NO GO and the report is short.

The gate

1 · Security

• Secret scan clean, including git history
• Object-level authorization tested — the cross-user test exists and passes
• Authentication: hashing, session invalidation, rate limits, no user enumeration
• Input validated by schema at every entry point, including webhooks and queue consumers
• Security headers set; CSP without unsafe-inline
• Dependency audit run, output read, high-severity issues resolved or accepted in writing
• Debug off; stack traces not returned; admin surfaces network-restricted
• Rate limiting on auth and all mutations
• Uploads: type verified by content, size capped, served from a separate origin

2 · Data

• Backups automated, encrypted, off-site — and restored in a drill, with the measured recovery time recorded
• Point-in-time recovery available
• Migrations tested against production-sized data, with reverses tested
• Migration ordering relative to deploy is correct for both directions
• Foreign keys indexed; the hottest queries have plans that were actually read
• statement_timeout and idle_in_transaction_session_timeout set
• Tenancy enforced in the database, not only in application code
• Retention rules defined per table and enforced by a monitored job

3 · Legal and trust

• Privacy policy published, accurate, dated, and generated from the real data inventory
• Every third party in the code appears in the policy
• Cookie consent gates scripts before consent — tested in a private window
• Self-service data export and deletion working end to end, reaching every processor
• Terms of service published
• Subprocessor list published; DPAs in force
• Breach response plan written, with a named decision-maker
• Support and security contacts published, with a stated response commitment

4 · Public surface

• Unique title and meta description on every page
• Canonical URLs correct — check that no page canonicals to the homepage
• robots.txt present and does not contain Disallow: /
• sitemap.xml generated and submitted
• Custom 404 returning a real 404 status (not a soft 404)
• Custom 500 leaking nothing
• Open Graph tags with a reachable absolute-URL image
• Structured data present and validated
• Alt text on every meaningful image
• Internal links resolve; no orphan pages
• Sticky mobile CTA does not obscure content or focus

5 · Accessibility

• Automated scan clean on the critical journeys
• Keyboard-only completion of every critical journey, with visible focus
• Screen reader pass on signup, the core action, and checkout
• Contrast passes in every state
• 400% zoom without horizontal scrolling
• Focus never obscured by sticky elements

6 · Correctness

• CI green and blocking merge
• The critical journeys are E2E tested and run before deploy
• Authorization matrix test present and passing
• No flaky tests in the blocking set
• Error paths tested, not just happy paths
• Manual smoke test of the critical journeys on staging and production after deploy

7 · Operations

• Error tracking wired, with releases and source maps
• Structured logs with a correlation id; no personal data in logs
• Health and readiness endpoints distinct; graceful shutdown implemented
• One dashboard: rate, errors, latency, plus one business metric
• At least one alert that pages a human, on a user-visible symptom
• External uptime check on a real user path
• Rollback documented and executed at least once
• On-call named; escalation path documented
• Runbooks for the three most likely failures
• Cost budget and anomaly alerts configured; autoscaling capped

8 · Performance

• Core Web Vitals measured and within budget on the key pages
• p95 latency measured against a stated budget
• Load tested at expected peak, with the first bottleneck named
• Caching configured with a stated invalidation rule
• Images optimised; LCP image preloaded and not lazy-loaded

9 · Documentation

• README gets a new engineer running in under 15 minutes
• ADRs for the one-way doors
• Runbooks current
• Changelog for this release

Launch-day sequence

T-7d   Freeze non-critical changes. Run the full gate. Publish the verdict.
T-2d   Restore drill. Rollback rehearsal. Final dependency audit.
T-1d   Staging matches production. Smoke tests green. On-call confirmed.
       Status page ready. Support briefed on the response commitment.

T-0    Deploy in a low-traffic window if you can.
       Migrate → deploy → smoke test → watch.
       Someone watches dashboards for the first hour. Not "keeps an eye on" —
       watches.

T+1h   Error rate, latency, business metric — compared against the pre-launch
       baseline you captured.
T+24h  Review. Any surprises? Any alert that should have fired and did not?
T+7d   Retrospective. What did the gate miss? Add it to the gate.

Capture a baseline before launch. Without pre-launch numbers for error rate, latency and conversion, you cannot tell whether the post-launch numbers are bad.

Verdict format

# Release Readiness — <project> v<version>
Date · Commit · Assessor

## Verdict: NO GO

Three blockers must close before launch. The largest is that any authenticated
user can read any other user's invoices, which would be a reportable data breach
on day one. Estimated time to clear all three: 2 days.

### Blockers
| # | Blocker | Owner | Estimate | Verification |
|---|---|---|---|---|
| 1 | IDOR on `/api/invoices/:id` | @a | 4h | Cross-user test passes |
| 2 | Backups never restored | @b | 1d | Drill completed, RTO recorded |
| 3 | Privacy policy omits PostHog and Intercom | @c | 2h | Policy matches code grep |

### Accepted risks (would be GO WITH RISK once blockers clear)
| Risk | Impact if it occurs | Mitigation | Accepted by |
|---|---|---|---|
| No load test above 200 concurrent | Unknown behaviour at a traffic spike | Autoscaling capped at 10; alert on p95 | @founder |

### Passed
<Named. A gate report that lists only problems misrepresents the work done.>

### Not assessed
<Explicit. Scope limits belong in the verdict, not discovered later.>

Calibration

Scale the gate to the stakes. An internal tool for five people and a fintech holding customer funds are not held to the same standard on load testing, observability or process. They are held to identical standards on: secrets in git, cross-user data access, backups, and honest privacy claims.

Do not gate on perfection. The gate exists to surface what is unknown or unacceptable, not to block until everything is ideal. GO WITH RISK is the common and correct verdict for a healthy team — the value is that the risks are named, owned and accepted deliberately.

Say no when it is no. A gate that has never produced a NO GO is not a gate.

References

• references/launch-checklist.md — the full checklist, printable, with verification commands
• templates/go-no-go.md — the verdict document
• templates/runbook.md — the operational runbook template