Pre-Launch QA Checklist: What to Test Before You Ship

Before you ship, test the journeys that make money or hold data, then permissions, payments, data integrity, performance, accessibility, SEO metadata, error states, and whether you can roll back. Each item below is a pass or fail check, so the list works as a launch gate: if an item fails, you either fix it or record why you are shipping anyway.

This is a reusable checklist for any web app, whoever built it. It is not a description of RAITHub's own process; that is in how RAITHub tests software. Copy the list, delete what does not apply to your product, and give every remaining line an owner and a place to record the evidence.

How should you use a pre-launch QA checklist?

As a gate with evidence, not a list of good intentions. Every line gets a name, a pass or fail, and a link to proof: a test run, a screenshot or a report.

• Run it on a production-like environment, with production settings and realistic data, not on a developer's laptop.
• Run it a week before launch, then again on launch day. The first run finds the work; the second confirms nothing regressed.
• Write down every accepted failure. "Shipping with known issue X, owner Y, fix by date Z" is a decision. Silence is a surprise waiting to happen.
• Automate the lines you will run again. Anything you check on every release belongs in CI, not in a spreadsheet.

What does the whole checklist look like on one page?

Nine areas, each with a minimum bar. If you only have an afternoon, this table is the launch gate.

Area	Minimum bar to pass	Automate or manual
Critical user journeys	Every journey that makes money or holds data completes end to end, on desktop and mobile	Automate with end-to-end tests, plus one manual run
Auth and permissions	Every role can do exactly what it should, and nothing more; protected routes refuse anonymous requests	Automate
Payments	Success, decline, refund and webhook replay all behave correctly in test mode, then one real low-value transaction in production	Automate in test mode, manual in production
Data integrity	Backups restore, migrations replay from empty, updates change only what they should	Automate migrations and update tests; rehearse the restore by hand
Performance	Core Web Vitals within Google's "good" thresholds on key pages; key endpoints hold expected load	Automate budgets in CI; load test before launch
Accessibility	Keyboard-only use works; automated scan clean; target WCAG 2.2 AA	Automated scan plus a manual keyboard and screen-reader pass
SEO and meta	Titles, descriptions and canonicals correct; no leftover noindex; sitemap live; real 404s	Automate the checks; review titles by hand
Error states	Every failure shows a clear message, and every error reaches your error tracking	Mostly manual, with a deliberate test error
Rollback plan	You have rehearsed going back to the previous release, including the database	Manual rehearsal

Which user journeys must work before launch?

The three to seven journeys that make money, create accounts or change important data. Name them explicitly; "the whole app" is not a test plan.

• List each journey as a sentence: "a new visitor signs up, verifies email, and creates their first project".
• Run every journey end to end on the production-like environment, in at least two browsers and on one real phone.
• Run it as a brand-new user with an empty account. Empty states break more often than full ones.
• Check the emails the journey sends: sign-up, password reset and receipts arrive, render correctly and do not land in spam.
• Check the journey still completes on a slow mobile connection, using the browser's network throttling.
• Automate each journey as an end-to-end test so it runs on every future release.

How do you test auth and permissions?

Build a role matrix, then try to break it. Most permission bugs are not a missing login; they are a logged-in user reaching something that belongs to someone else.

• Sign-up, login, logout, password reset and session expiry all work, and a reset link cannot be used twice.
• Write a table of roles against actions, and test each cell, including the "must be refused" cells.
• Log in as user A, copy one of A's record IDs, then request it as user B. It must be refused. This is the insecure direct object reference (IDOR) test.
• Request every admin route and admin API without a session. Pages should redirect to login; APIs should return 401 or 403.
• Try 20 wrong passwords in a minute. The limit should slow the attacker without letting anyone lock the real owner out.
• After any framework upgrade, prove the auth layer still loads. On the RAITHub website, the check after Next.js 16 renamed middleware.ts to proxy.ts was that admin pages still redirect and the admin API still returns 401, not merely that the build passed.

The API security checklist goes further on the server side.

What should you test in payments?

The unhappy paths. A successful card payment is the one case everyone tests; declines, retries and duplicate webhooks are where money goes missing.

• Use the provider's test cards for success, decline, insufficient funds and 3-D Secure authentication. Stripe publishes a full set in its testing documentation.
• Close the tab in the middle of a payment. The order should end up either paid or clearly unpaid, never half-created.
• Send the same webhook twice. The second must change nothing; this is idempotency, explained in what idempotency means in API design.
• Issue a full and a partial refund, and check the order, the stock and the customer email all update.
• Check totals with tax, discounts and currency rounding against a hand calculation.
• Test every payment method separately. Each has its own failure modes: TheSkinProof, the founder's own marketplace venture built and run by RAITHub, supports four payment rails (bKash, Nagad, SSLCommerz and cash on delivery), and each needs its own success, failure and refund cases.
• After launch, make one real low-value purchase in production and refund it.

How do you check data integrity before launch?

Prove you can get data back, prove the schema can be rebuilt, and prove that updates only change what they are meant to.

• Take a backup and restore it into a separate database. Time how long it takes; that is your real recovery time.
• Replay every migration on an empty database. If the schema cannot be rebuilt from code, a hand-edited table is hiding somewhere.
• Test partial updates: change one field and confirm no other field changed. The RAITHub website found a bug of exactly this kind before launch, where zod 4's .partial() re-applied default values and would have wiped fields. The fix and regression test are in zod 4 .partial() keeps default values.
• Check unique constraints and required fields at the database level, not only in the form.
• Check dates and times across time zones, especially anything that runs at midnight.
• Test deletion: what happens to a user's orders, files and messages when the account is deleted?

What performance targets should you test against?

Google's Core Web Vitals for pages, and a latency target under load for your key endpoints. The published "good" thresholds on web.dev are a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads.

• Measure the home page, the main landing pages and the heaviest logged-in page on a throttled mid-range mobile profile, not on a fast laptop.
• Check image sizes and formats, and that below-the-fold images load lazily.
• Load test the endpoints behind the critical journeys at a realistic peak, and record the 95th-percentile (P95) latency.
• Look for slow database queries under that load; a missing index is the most common cause.
• Set the results as budgets in CI, so a later change that breaks them fails the build.

More on the page-speed side is in the Core Web Vitals optimization guide.

How much accessibility testing is enough before launch?

Enough to know a keyboard user and a screen-reader user can complete every critical journey. A common target is WCAG 2.2 level AA, the W3C's Web Content Accessibility Guidelines.

• Complete each critical journey using only the keyboard. Focus must be visible and move in a sensible order.
• Every form field has a label, and every error message says what went wrong and how to fix it.
• Images that carry meaning have alt text; decorative ones have empty alt text.
• Text contrast meets AA levels, including placeholder text and disabled buttons.
• Run an automated scanner on every page type, then do one manual pass with a screen reader. Automated tools find only part of the problems.
• Dialogs trap focus while open and return it when closed.

What SEO and meta checks belong in a launch checklist?

The ones that are easy to get wrong in a way that stays invisible for weeks. A staging noindex tag left in production can quietly keep a new site out of search.

• No leftover noindex tag or blocking robots.txt rule from staging.
• Every page has a unique title and meta description.
• Canonical URLs point at the production host, and only one host (with or without www) serves pages. RAITHub learned this one first-hand: a stale environment value once pointed canonicals at an old preview host that no longer existed, so the site now builds every canonical from one function that ignores any other host.
• The sitemap is live, lists only real pages, and is submitted to search engines.
• Unknown URLs return a real 404 status, not a 200 with an error message.
• Old URLs, if this replaces an existing site, redirect permanently to their new equivalents.
• Structured data validates, and social preview images render when a link is shared.

Which error states should you test?

Every way the app can fail in front of a user: missing pages, server errors, bad input, slow networks and third-party outages. The test is whether the user knows what to do next, and whether you find out.

• A custom 404 page and a custom error page, both with a way back.
• Validation messages next to the field, in plain words.
• Empty lists, empty search results and first-time dashboards say something useful.
• Go offline mid-action, and time out a request. The app should not freeze or lose the user's input.
• Disable one third-party key in staging, such as email or maps, and check the app degrades instead of crashing.
• Throw a deliberate test error and confirm it appears in your error tracking and alerts a real person.

What should a rollback plan include?

How to go back, who decides, and what happens to the database. A rollback plan you have never rehearsed is a guess.

• The exact steps to redeploy the previous release. Most hosts, Vercel included, let you promote an earlier deployment.
• Database changes that are backward compatible for at least one release: add columns first, remove old ones later, so the previous code still runs against the new schema.
• Feature flags for risky features, so you can switch one off without a redeploy.
• One named person who can call a rollback, and the signals that trigger it, such as error rate or failed payments.
• A message ready for customers if something user-visible breaks.
• One full rehearsal before launch day.

Which checklist items should you automate?

Anything you will check again on the next release. The checklist catches what matters once; automated tests make sure it stays caught.

For scale, these are measured test counts from platforms RAITHub built: 750+ automated tests on TheSkinProof, the founder's own venture; 1,024 on PropDesk, a property-management SaaS; and 400+ on the RAITHub website as of September 2026. Suites that size are what turn most of this checklist into gates that run on every change, leaving the manual list short: the restore rehearsal, the screen-reader pass, the real production payment and the rollback rehearsal.

Why RAITHub for pre-launch QA?

• Checks turned into gates. RAITHub's QA and Reliability work puts the repeatable parts of this list into CI: end-to-end journeys with Playwright, load and latency with k6, error tracking with Sentry, and performance budgets that fail the build.
• Review aimed at the gaps. The bugs cited in this post were found by tracing data and proving configuration loads, not by a green pipeline.
• Tests stay yours, in your repository with full IP assignment.
• A fixed written quote after a free 15-minute technical audit. RAITHub publishes no rates; what outsourced QA costs covers the market.

When do you not need RAITHub for this?

• It is a brochure site on a hosted builder, with no accounts or payments. The builder's own launch checklist is enough.
• You have a QA engineer who owns release testing. Give them this list.
• You launch in two days. Run the one-page table yourself and fix what fails; automation comes after.
• You need a certified vendor. RAITHub is not SOC 2 or ISO 27001 certified.

If you want the checklist run against your app, or turned into CI gates, pick QA / Reliability on the contact form and book the free 15-minute audit.

Last reviewed: 28 September 2026. External thresholds checked on 28 September 2026.

Frequently asked questions

What should you test before launching an app?

The critical user journeys, auth and permissions, payments, data integrity, performance, accessibility, SEO and meta tags, error states, and your rollback plan. Start with the journeys that make money or hold customer data.

How long does pre-launch QA take?

For a small web app, the one-page checklist can be run in a day or two. Fixing what it finds takes longer, which is why it should be run a week before launch and again on launch day, not only the night before.

What is the difference between a QA checklist and automated tests?

A checklist lists what must be true before launch; automated tests prove it again on every release. Most checklist items should become tests. The rest, such as restore rehearsals and screen-reader passes, stay manual.

What performance thresholds should a web app meet at launch?

Google's "good" Core Web Vitals thresholds: 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, at the 75th percentile of page loads.

Do I need a rollback plan for a first launch?

Yes. Even a first release can break sign-ups or payments. Know how to redeploy the previous version, keep database changes backward compatible, and rehearse the rollback once before launch day.

Which accessibility standard should a web app meet?

WCAG 2.2 level AA is a common target. At minimum, every critical journey should work with a keyboard alone and with a screen reader, with visible focus, labelled fields and sufficient contrast.

Can RAITHub run this checklist on an app it did not build?

Yes. RAITHub's QA and Reliability work applies to existing apps, and the result can be a one-off report or tests gated in your CI. It starts with a free 15-minute technical audit.