The Release Readiness Checklist for SaaS Teams
Most teams do not have a release process. They have a feeling. Someone asks in Slack whether it is safe to ship, a few people say it looks fine, and the deploy goes out. This checklist turns that feeling into a decision you can repeat.
1. Critical journeys passed
Every revenue-critical journey passed in a production-like environment: sign-up, sign-in, the core workflow, billing and any flow a large customer depends on. "Passed" means the failures were reviewed, not just that the dashboard is green.
2. No unreviewed failures
Every red result is classified: real bug, flaky test or environment issue. A release with unexplained failures is a release with unknown risk, even if someone reran the suite until it passed.
3. Data changes rehearsed
Any migration ran on a realistic copy, with before-and-after counts reconciled. Data bugs outlive code bugs, because rolling back code does not roll back corrupted records.
4. Contracts and integrations intact
API contract tests passed, including compatibility with mobile app versions still in use and any partner integrations. A renamed field can break clients that cannot be updated instantly.
5. Performance within budget
Key endpoints and pages are within their latency budgets compared with the last release. Slowdowns rarely arrive as outages; they creep in one release at a time.
6. Security and accessibility checked
Automated security checks found no new high-severity issues, and accessibility scanning found no new WCAG regressions. Both regress with ordinary changes, so both belong in every release, not an annual audit.
7. Rollback ready
You know how to roll back, how long it takes and who does it. Feature flags are set for anything risky so it can be switched off without a deploy.
8. One person makes the call
Someone owns the ship or hold decision and writes it down with the evidence. Shared responsibility for releases usually means nobody is responsible. At QAShift that decision arrives as a 9am report in Slack: a clear verdict, the evidence behind it, and any bugs already filed.