Web Design

The Pre-Launch Website QA Checklist for Operators

Imagine paying for a billboard and not noticing the phone number on it is disconnected. That is what launching a website without QA means: you are about to aim ad spend, email lists, and sales conversations at an asset nobody has actually used, only admired in design reviews. The defects that kill conversion are rarely dramatic. They are quiet: a form that submits to nowhere, a tracking script that never fired, a page that takes six seconds on a phone. This guide gives operators the five-layer pre-launch QA pass, the severity system that prevents debates, and the mechanical go/no-go rule that protects launch day.

Joshua Agonya Pi'Rwot

By Joshua Agonya Pi'Rwot

Founder, Business Growth Accelerator

Executive summary

A website that launches with a broken form is a billboard with a disconnected phone number. Pre-launch QA is one structured pass over forms, speed, mobile, tracking, and content before traffic arrives. Here is the checklist.

Section 1

Launch day is the worst time to find out

Most launch disasters are mundane: a form that posts to nowhere, a phone number that was a placeholder, a booking calendar connected to a departed employee, analytics that never fired. None of these are visible in a design review, because design reviews look at the site while QA uses it. The financial logic is brutal. You are about to point paid traffic, email lists, and sales conversations at this asset; every defect is multiplied by every visitor. Speed alone moves real money, web.dev's performance research documents the BBC losing an additional 10 percent of users for every extra second of load time, and Nielsen Norman Group's response-time work shows delays measurably erode perceived quality of the brand itself. QA is one to two days of structured testing against weeks of silently leaking leads. No phase of the project has a better ratio of effort to protected revenue. For a deeper look at this, see [How to Run a Website Project Without Being a Designer: The Operator's Process](/blog/how-to-run-a-website-project-without-being-a-designer).

Section 2

The five-layer QA pass

Run QA in layers, in order of business damage. Conversion paths come first because a broken form costs you every lead it touches; cosmetics come last because a typo costs you a wince. For each layer, the table gives the test method and the pass bar, note that 'pass' is defined by evidence, not by a vendor saying 'should be fine.' Submit the forms yourself and confirm the lead lands in your CRM and triggers the notification. Load pages on your own phone over cellular, not office wifi. Check Core Web Vitals against the published thresholds: LCP within 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. Verify tracking by performing a conversion and watching it appear in analytics. Two focused half-days cover all five layers for a typical marketing site.

Section 3

Test like a skeptical customer, not a proud owner

The person who built the site cannot QA it; familiarity blinds them to the path a stranger takes. So assign at least one tester who has never seen the project, an assistant, a friendly client, a spouse, and give them tasks, not a tour: 'find out what this company charges and book a call.' Watch where they hesitate. This is a scrappy version of what Nielsen Norman Group formalizes as usability testing, and their research finding that around five users surface most usability problems means you do not need a lab, you need three to five honest strangers and an hour. Capture everything in one shared list with severity labels: blocker (broken conversion path), major (wrong content, slow page), minor (cosmetic). Blockers stop launch. Majors get fixed within the first week. Minors get batched. Without severity labels, every finding becomes a debate. If you are turning this into practice, [Who Owns Your Website? Domains, Hosting, and Backups for Operators](/blog/website-ownership-domains-hosting-backups) maps the adjacent system.

Section 4

The go/no-go decision and the checklist's afterlife

QA ends with a decision, and the operator makes it: launch, or hold and fix. Make the criteria mechanical before testing starts, zero open blockers, tracking verified, performance within thresholds on the money pages, so the decision is read off the list rather than negotiated under deadline pressure. Resist both failure modes: launching with a known broken form because 'we announced the date,' and holding launch for minor polish that iteration will handle anyway. The checklist is the asset here, not the heroics; keep the process serving the outcome rather than becoming the outcome. Then keep the checklist alive, every new landing page, campaign, and template change runs the same five layers in miniature. Inside ConvertOS, the QA checklist is versioned alongside the site itself, because a checklist that lives in someone's memory is not a system, it is a hope. The thinking here builds on [AI Automation in Product Development: From Idea to Launch](/blog/ai-automation-in-product-development-from-idea-to-launch).

FAQ

Direct answers for operators.

Who should run pre-launch QA, the agency or the client?

Both, with different jobs. The vendor runs technical QA, cross-browser checks, performance optimization, code validation, because they have the tooling. The operator owns acceptance QA: submitting every form, verifying leads reach the CRM, checking content accuracy, and making the go/no-go call. Never outsource the final pass entirely; the vendor is grading their own homework, and your business absorbs whatever they miss.

What performance numbers should a website hit before launch?

Use Google's published Core Web Vitals thresholds as the floor: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift below 0.1, measured at the 75th percentile and tested on a real phone over cellular. Speed is revenue protection, web.dev documents the BBC losing 10 percent of users for every additional second of load time.

How long does proper pre-launch QA take?

One to two days for a typical service-business marketing site: a half-day for conversion paths and tracking, a half-day for performance and mobile testing, and a half-day for a full content read by someone who didn't write it. Add a buffer day for fixing blockers. Teams that 'test as they go' without a final structured pass are the ones who discover the broken contact form from a prospect's complaint.

Joshua Agonya Pi'Rwot

Written by

Joshua Agonya Pi'Rwot

Founder, Business Growth Accelerator · Country Director, AVODA Group Uganda · EMBA

Joshua helps service-business operators turn scattered marketing into a clear path from first attention to booked call. He is Founder of Business Growth Accelerator and Country Director of AVODA Group Uganda.