Pre-Launch QA Checklist for Web Agencies (Client-Ready)

A pre-launch QA checklist for web agencies is a written pass over seven gates, run on the production build before the client ever opens the site: critical user journeys, forms and integrations, cross-browser rendering, responsive layout, performance, accessibility, and content accuracy. What separates an agency checklist from a generic testing list is the output — it produces a dated, signed record of what was verified, on which build, by whom. That record is what stands between you and an awkward conversation when a bug surfaces in week three of the warranty period.

What should a pre-launch QA checklist for web agencies include?

Seven gates, in this order. The order matters: each one is cheaper to fix than the one after it is to discover.

1. Critical user journeys

List every path where the client's business outcome happens, then walk each one start to finish as a real user would. For a marketing site that is usually two or three journeys: land on a page, read it, submit the enquiry form. For e-commerce it is browse, add to cart, checkout, receive confirmation. For a product with accounts it is sign up, verify email, log in, do the core action, log out, log back in. A page can render perfectly and still be a dead end.

2. Forms and integrations, tested live

This is the gate agencies fail most often, because forms usually work in staging and then silently break in production. Submit every form with real data and confirm the data arrived where it is supposed to: the inbox, the CRM, the spreadsheet, the webhook endpoint. Check the confirmation the user sees, the notification the client receives, and the spam folder. Then submit each form badly — empty required fields, a malformed email, an oversized file, a double-click on submit — and confirm it fails gracefully rather than losing the lead.

3. Cross-browser rendering

Check the site in Chrome, Safari, and Firefox at minimum, and specifically in Safari on iOS, which has its own rendering and scrolling behaviour and is where a large share of your client's mobile visitors will be. If the client's team runs a browser you do not use daily, check that one too — the worst bug report is the client's managing director finding a broken layout themselves.

4. Responsive layout at real breakpoints

Resizing a desktop window is a smoke test, not a check. Load the site on an actual phone and an actual tablet. Look for the failures that only appear on real devices: horizontal overflow, text overlapping at awkward intermediate widths, tap targets too small or too close together, sticky headers that eat half a small screen, and modals that cannot be dismissed without a mouse.

5. Performance on the production build

Measure the built, deployed site — not a dev server, which has no minification, no CDN, and no real network latency. Run a Lighthouse pass on a throttled mobile profile and look at the largest contentful paint and layout shift, because those are the two a client feels. The usual culprits are the same every time: unoptimised hero images, a font strategy that flashes, and a third-party script added late and never measured.

6. Accessibility basics

Run an automated scan and fix what it finds, then do the three manual checks a scanner cannot make: tab through the whole page and confirm you can reach and operate everything with the keyboard, confirm the focus ring is visible, and confirm images carry alt text that describes the image rather than repeating the filename. For clients in the public sector, education, healthcare, or finance, accessibility is often a contractual requirement rather than a nice-to-have — check the contract before you assume it is optional.

7. Content and metadata

The gate that causes the most embarrassment per unit of effort. Hunt for placeholder text, lorem ipsum, stock images that were meant to be replaced, the developer's own email address in a mailto link, and last year's copyright year. Then check the things that are invisible on the page but very visible everywhere else: page titles and meta descriptions, the Open Graph image that renders when the client shares the site on LinkedIn, the favicon, the 404 page, and whether robots.txt and the noindex tags from staging were removed.

Which checks should be automated and which stay manual?

The dividing line is stability. Automate the checks whose expected answer never changes; keep human judgement for the checks that need taste.

If the site was largely assembled with an AI coding tool, weight the manual side more heavily than you would for hand-written code. AI-generated code tends to be locally plausible and globally inconsistent — each component looks right in isolation while the seams between them do not line up. Our guide to testing AI-generated code covers where those seams usually split.

How does an agency turn the checklist into a client-facing artifact?

This is the part most checklists leave out, and it is the part that earns its keep commercially. A QA pass nobody can point to later is indistinguishable from no QA pass at all.

• Record the build, not the date. Note the commit hash or deploy ID you tested. "QA passed on the 12th" is worthless if three deploys went out that afternoon.
• Name the person who ran each gate. Accountability makes the checklist real. An unsigned checklist gets skimmed.
• List known-and-accepted issues explicitly. Every launch ships with something imperfect. Writing it down converts a future complaint into a decision the client already agreed to.
• Attach it to the handoff. Put it in the same place as the credentials and the documentation, so it is part of the deliverable rather than an internal note.
• State what was not tested. Load at scale, third-party systems you do not control, and anything behind a client-owned credential you never received. Silence on these reads as a claim you tested them.

What does a pre-launch checklist not protect you from?

Three things, and being honest about them with yourself is what keeps the checklist from becoming theatre.

Everything that happens after launch. A pre-launch pass certifies one build at one moment. The content editor who pastes a 4 MB image into the hero next Tuesday is outside its scope entirely. Most client-reported bugs arrive weeks after launch, on changes nobody tested, which is why post-launch reporting matters as much as pre-launch checking.

The paths you did not think to list. Your journey list reflects your mental model of the site. Real users take routes you never imagined — back button mid-checkout, two tabs open, a stale session, a link from an email opened six days later. This is the gap AI persona testing is built for: simulated users with different intents exercise paths a checklist author would not write down.

The report quality when a bug does appear. If the client's feedback channel is a WhatsApp message saying "the form is broken," you will lose an hour reproducing it before you can start fixing. Give them a way to report that captures the URL, the browser, the console, and the network state in one action — Snap does this from a right-click — and your first reply is a fix instead of a question. Our guide on reducing 'cannot reproduce' tickets goes through the four kinds of state you need.

Where should you start if you have no checklist today?

Do not write a hundred-item document you will abandon on the second project. Start with the two gates that cause the most client-visible damage: walk the critical journeys on the production build, and submit every form with real data and confirm it arrived. Then add one gate per project until all seven are routine, and keep the checklist in version control next to the code so it improves with every launch instead of resetting.

For the organisational side of shipping — rollback, DNS, on-call, sign-off — pair this with our release readiness checklist. For a broader view of where automated QA fits into agency delivery, start with the complete guide to AI QA.

Find the bugs before your client does

A checklist tells you what to look at. Klavity tells you what is broken: Snap turns a client's right-click into a reproducible bug report with console and network state attached, Sims runs AI personas through the journeys your checklist never listed, and AutoSim keeps your E2E tests passing as the site changes. Scan your next client site free — no credit card, no sales call.