Pre-Launch Software QA Checklist: What to Check Before Release Day

Launch day goes wrong in predictable ways. A payment form works in staging but not with production keys. A database migration takes 40 minutes instead of 4. An alert nobody configured means the first sign of trouble is an angry customer email. None of these are exotic bugs. They’re gaps in the checklist.

This is a practical pre-launch QA checklist you can copy into your release ticket. It covers 6 areas: scope and builds, functional testing, performance, security, monitoring and rollback. Use all of it for a major launch, and a trimmed version for routine releases.

Why a written checklist beats “we tested it”

Testing is ongoing. A launch checklist is different: it’s a final, explicit check that the specific build going live is ready, and that the team can recover if it isn’t. Writing it down does 3 things:

• It makes readiness visible. Everyone can see what is done and what isn’t.
• It removes memory from the process. People forget steps under deadline pressure.
• It creates a record. If something breaks, you know what was and wasn’t checked.

Key takeaway: The goal of pre-launch QA isn’t zero risk. It’s making sure that if something fails, it fails small, gets noticed fast and can be undone quickly.

The checklist at a glance

1. Scope, builds and environments

• [ ] Scope is frozen. Late changes need explicit approval from the release owner.
• [ ] The exact build or commit going to production is tagged, and that same artifact was tested.
• [ ] All automated tests pass on that build: unit, integration and end-to-end. If you’re unsure how those layers differ, see unit vs integration vs end-to-end testing.
• [ ] Staging matches production for configuration, feature flags, third-party integrations and data shape as closely as you can manage.
• [ ] Environment variables and production keys are set and checked, without exposing secret values in tickets or chat.
• [ ] Known issues are listed with a decision: fix now, ship with workaround, or block.
• [ ] Release notes and support notes are written so customer-facing teams know what changed.

2. Functional checks

• [ ] Every critical journey passes in staging: sign-up, login, password reset, core task, checkout or payment, account deletion.
• [ ] Payments are tested end to end in the provider’s test mode, including declines, refunds and webhooks.
• [ ] Emails, SMS and push notifications send, render correctly and link to the right environment.
• [ ] Permission levels behave correctly: a regular user can’t reach admin pages or another customer’s data.
• [ ] Error states are handled: empty states, invalid input, expired sessions, network failures.
• [ ] Integrations with partner systems, webhooks and APIs are verified against their production endpoints where safe.
• [ ] Regression check: features that weren’t supposed to change still work.

Compatibility and accessibility

• [ ] Tested on the browsers and devices your analytics show customers actually use.
• [ ] Mobile layouts work at common screen widths with no horizontal scrolling.
• [ ] Keyboard navigation, visible focus, form labels and color contrast pass basic checks. Our WCAG 2.2 checklist lists the common failures and fixes.

3. Performance checks

• [ ] A load test at expected peak traffic, plus a margin, passes without errors or runaway latency.
• [ ] Database queries on the busiest pages use indexes and avoid “N+1” query patterns.
• [ ] Key pages meet speed targets. Google’s Core Web Vitals guidance sets “good” at Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads.
• [ ] Caching and CDN rules are configured and tested. See what a CDN is if you’re setting one up.
• [ ] Autoscaling, rate limits and timeouts are set and won’t fail under a traffic spike from launch announcements.
• [ ] Background jobs and queues can keep up with expected volume.

4. Security checks

The OWASP Top 10:2025 is a good frame for a pre-launch security pass. It lists Broken Access Control first, followed by Security Misconfiguration and Software Supply Chain Failures. A practical launch-day version:

• [ ] Access control: every endpoint checks that the user is allowed to do the action, not just that they’re logged in.
• [ ] Configuration: debug mode is off, default accounts are removed, error pages don’t leak stack traces, admin panels aren’t public.
• [ ] Dependencies: known-vulnerable packages are updated or have an accepted risk decision. Lockfiles are committed.
• [ ] Secrets: no API keys or passwords in code, logs or the front-end bundle. Production secrets live in a secrets manager.
• [ ] Authentication: rate limiting on login, secure session cookies, multi-factor authentication for admin accounts.
• [ ] Input handling: queries are parameterized and user input is validated and encoded.
• [ ] HTTPS everywhere, with security headers such as Content-Security-Policy configured.
• [ ] Privacy: personal data collection matches your privacy policy, and data retention is defined.

For a broader view, see what DevSecOps is and zero trust security explained. If your product handles health or payment data, compliance checks such as HIPAA for software apply too.

5. Data, monitoring and support readiness

Data

• [ ] Database migrations have been rehearsed on a production-sized copy, with timing recorded.
• [ ] Migrations are backward compatible, so the old version of the app still runs if you roll back.
• [ ] A fresh backup exists and a restore has been tested recently. A backup you’ve never restored is a hope, not a plan.

Monitoring

• [ ] Dashboards show error rate, latency, traffic and saturation for the new release.
• [ ] Alerts are configured with clear thresholds and route to a named on-call person.
• [ ] Logs are searchable and don’t contain passwords, tokens or full card numbers.
• [ ] Business metrics, such as sign-ups or orders per hour, are visible so you can spot silent failures.
• [ ] Uptime checks run from outside your network.

Our guide to observability vs monitoring explains what to track.

Support

• [ ] Support has a FAQ for the release and knows how to escalate.
• [ ] A status page or customer communication template is ready in case of an incident.

6. Rollback readiness

This is the section teams skip and regret. The Google SRE Workbook chapter on canarying recommends rolling changes out to a small subset first, comparing it against the rest of the fleet and keeping rollback cheap and possible.

• [ ] Rollback steps are written down and have been tested, not just discussed.
• [ ] Risky features sit behind feature flags that can be switched off without a redeploy.
• [ ] A gradual rollout is planned: internal users, then a small percentage of traffic, then everyone.
• [ ] Go/no-go criteria are agreed in advance. For example: “roll back if error rate doubles or checkout success drops by a set amount for 10 minutes.”
• [ ] The release owner has authority to call a rollback without a meeting.
• [ ] The release is timed when the team is available, not late on a Friday before a holiday.

Where to start: running launch day

1. 2 weeks out: Freeze scope, assign a release owner and copy this checklist into your release ticket.
2. 1 week out: Run load and security checks, rehearse migrations and test rollback in staging.
3. 2 days out: Final regression on the release build. Confirm monitoring, alerts and on-call.
4. Launch day: Hold a short go/no-go check, deploy gradually, watch dashboards and run smoke tests after each stage.
5. After launch: Monitor closely for 24 to 72 hours, then hold a short review of what went well and what the checklist missed.

Automating the repeatable parts in your pipeline saves time on every release. Our guide to building a CI/CD pipeline shows how, and continuous delivery vs continuous deployment explains how far to automate.

Conclusion

A pre-launch QA checklist turns launch day from a gamble into a routine. Check the journeys that matter, prove the system holds under load, close the obvious security gaps, make problems visible and keep a tested way back. Then update the checklist after every release, because each launch teaches you something the last one didn’t.

Sources

• OWASP Top 10:2025 — current list of top web application security risk categories
• Web Vitals, web.dev (Google) — Core Web Vitals metrics, thresholds and 75th percentile measurement
• Canarying Releases, Google SRE Workbook — gradual rollouts, canary evaluation, feature flags and rollback guidance