# Release readiness checklist

Twelve questions to answer for the exact build you are about to ship. Mark each **Yes** (done, with evidence), **Partly** or **No**. A **No** on any item marked _critical_ means the release is not ready, whatever else is done.

Prefer a score? Use the free interactive version: [release readiness scorecard](https://shipperag.com/release-readiness-checklist/?utm_source=github&utm_medium=repo&utm_campaign=release-kit) (runs in your browser; nothing is sent or stored).

- [ ] **1. Scope is written down** — Is the scope of this release written down (features, fixes and content) and tied to a specific build? List what is in the release and name the build, commit or deployment it refers to. Every other answer on this list depends on knowing exactly what you are shipping.

- [ ] **2. Checked against requirements** — Has every change been checked against its requirements or acceptance criteria, not only against the code? Write acceptance criteria a non-developer could check, then test against them. Tests written from the code share its assumptions. Our [UAT sign-off template](https://shipperag.com/uat-sign-off-template/?utm_source=github&utm_medium=repo&utm_campaign=release-kit) shows how to phrase criteria an approver can sign.

- [ ] **3. Critical journeys work** _(critical)_ — Have the critical user journeys (sign-up, log-in, checkout or your equivalent) been tested end to end on this build? Walk every journey that makes or loses money on the exact build you will ship, including error and empty states. The [website QA checklist](https://shipperag.com/website-qa-checklist/?utm_source=github&utm_medium=repo&utm_campaign=release-kit) covers the journeys and forms most products need.

- [ ] **4. Regression checked** — Have the areas this change could break been re-tested, not just the new feature? Look at what the change touches (shared components, data models, pricing, permissions) and re-test those areas. Most release incidents come from what nobody thought to re-check.

- [ ] **5. Accessibility checked** — Have keyboard use, screen reader basics and colour contrast been checked on the changed screens (WCAG 2.2 AA)? Run an automated scan, then check the changed screens with a keyboard alone. Automated rules find only part of the problems, so our [AI accessibility testing guide](https://shipperag.com/ai-accessibility-testing/?utm_source=github&utm_medium=repo&utm_campaign=release-kit) explains what still needs a person.

- [ ] **6. Browsers and devices** — Has it been checked on the browsers and screen sizes your users actually use? Use your analytics to pick the browsers and devices that matter, and include at least one small phone. Emulating a phone in a desktop browser helps with layout, but it is not the same as a real device.

- [ ] **7. Integrations and data** — Are payments, emails and other integrations tested in sandbox or test mode, with no real customer data? Test each integration end to end in its test mode (payments, email, CRM, analytics) and confirm staging holds no real personal data.

- [ ] **8. Access and privacy** _(critical)_ — Have access rules been checked, so users cannot see or change each other's data, and are no secrets or personal data exposed? Try the changed pages and APIs as another user and as a signed-out visitor. Broken access control tops the [OWASP Top 10](https://top10.owasp.org/) for a reason.

- [ ] **9. Speed and errors** — Are page speed and error rates on this build within your targets? Measure the changed pages on a mid-range phone connection and check the error log on staging. Agree the numbers you ship with, before release day.

- [ ] **10. Known issues listed** — Are all open issues listed with a severity and an agreed action: fix before release, fix after, or accept? Put every open issue in one list with its severity and the action the release owner agreed. Known issues that are written down are a decision; unknown ones are a surprise.

- [ ] **11. Rollback and monitoring** _(critical)_ — Can you roll back quickly, and will monitoring tell you within minutes if something breaks after release? Write down how to roll back and who can do it, and make sure alerts cover the critical journeys. A release you cannot undo needs a much higher bar.

- [ ] **12. Sign-off with evidence** — Has a named person approved the release, with evidence of what was tested and what was not covered? Record who approved which build, on what terms, with links to the evidence and a plain "not covered" list. The [UAT sign-off template](https://shipperag.com/uat-sign-off-template/?utm_source=github&utm_medium=repo&utm_campaign=release-kit) gives you the document to sign.

## Decide and record

- **Go** — every item is Yes, or the few Partly items are accepted in writing.
- **Go with conditions** — the release owner accepts named gaps, each with an owner and a date.
- **No-go** — any critical item is No, or too much is unknown.

Record the decision with the [release readiness report template](../templates/release-readiness-report.md).