How to QA white-label work before the client sees it

Clients find issues in the most expensive way: during a review meeting, on a phone, with their boss on the call. That is not “agile feedback.” That is you asking them to finish your job. They will remember the feeling even if you fix the bug before lunch.

Partners test what they were asked to build. They may not test the story in the proposal: CMS edit path, newsletter vendor, the 404, the password reset, the blog with one post. That gap is why agencies exist in the middle. Fill it on purpose.

We stopped sending ‘take a look when you can’ links. If I have not clicked it on my phone, the client does not get the URL.

It is not a second development team re-implementing the site. It is a structured pass: does this match the brief, the design, and the brand surfaces we promised? Can a non-developer complete the primary path? Would we be embarrassed if this URL leaked to the client’s board?

It is also brand hygiene. White label means the review environment looks like you. How to protect your agency brand covers leaks in depth. QA is where you catch them: default WordPress credits, partner emails in form notifications, “designed by” in the theme footer, staging robots that should not be indexable if that was the rule.

If partner QA and agency QA are the same person in practice, you will skip one. Name them. Even a 30-minute agency pass is a different brain than the person who just shipped the CSS.

Localhost screenshots lie. Production “just this once” creates a public mess. Staging with real-ish content, HTTPS, and the actual integrations (or clearly labeled stubs) is the only environment you should send internally, then to the client.

Write the URL rules in the brief: password protection, noindex, and who may share it. Clients forward links. Assume the CEO will open it on a train. If the build is half content, say so in the email—after you have confirmed the half that exists actually works.

Need the intake that makes this pass possible? How to brief a white label development partner and the brief template define the list you are testing against. QA without a brief is taste. Taste does not close tickets.

Do not use a 200-item enterprise script on a five-page brochure. Do not use a brochure script on a store. Match the gate to the SOW. Below is a starting set; delete what you did not sell, and do not skip what you did.

SEO, analytics, and redirects are in scope only if you sold them. If you did, check they exist before the client asks “is this like the last site.” If you did not, say so in the review email so they do not score you on a ghost promise. How agencies sell development is where those promises should have been named.

Visual QA is spacing, type, components, and “does this look like our file.” Functional QA is clicks, forms, states, and permissions. Content QA is wrong product names, lorem in a legal page, and images still named IMG_4521. Mixing them into one emotional scroll produces notes like “feels off,” which a partner cannot ship against.

Run them in that order

If the layout is still wrong, do not spend an hour on comma copies. If the form is broken, do not debate button radius. Sequence saves the partner from thrash and saves you from a client meeting about pixels on a site that cannot submit.

Designers should own visual. AMs can own content and the primary path. Someone technical enough to know a 500 from a copy issue should own integrations. If that person is always the founder, you do not have a QA process. You have a bottleneck. That is one of the outsourcing mistakes that looks like a vendor problem.

Write the matrix in the brief, then test that matrix. “Looks fine in Chrome on a 27-inch” is not a mobile site. You do not need every device. You need the phones your clients actually use and the browsers you named. If Safari was in the SOW, open Safari.

Reduced motion, keyboard focus, and form labels are not decoration. They are how you avoid a launch-week accessibility surprise from a client’s legal team. You do not need a full audit unless you sold one. You do need not to ship a menu that traps focus or a form you cannot complete without a mouse.

Click every primary conversion once with a real outcome: you receive the email, the CRM row appears, the test payment settles in the sandbox. Stubbed integrations should be labeled in the review notes so the client does not think HubSpot is live when it is a thank-you page only.

Check the from-address, the reply-to, and the footer of transactional mail. This is a brand surface. It is also how clients discover a partner. Fail it in QA, not in their inbox after launch.

1. 01

   List conversions from the brief

   Form, checkout, booking, newsletter, login. If it was sold, it is on this list.

2. 02

   Run one success and one failure

   Empty required fields, declined card, or invalid email—whatever the product has. Read the message.

3. 03

   Confirm the agency-facing artifact

   Notification, CRM record, or order. If you cannot see it, the client’s ops team will say the site is broken.

4. 04

   Note stubs in the client email

   Honesty here prevents a QA theater review of features that are not on this staging build.

Numbered items. URL. Device. Expected vs actual. Screenshot. Brief reference if it is a defect. If it is new scope, say so. “Make the hero more premium” is not a ticket. “Hero headline wraps to four lines at 390px; Figma frame Home / iPhone shows two. Please match wrapping or we change copy” is a ticket.

Batch. One round. Do not drip twelve Slacks. The partner will ship against the latest ping and miss the first eleven. Your process should match theirs: a single list per round, then they return a build, then you re-run the gate on the changed paths—not a full philosophical re-review unless the miss was structural.

Send it back if primary paths fail, brand leaks, or the build does not match the brief you both signed. Send it to the client if remaining items are copy they own, a third party they have not granted, or polish you have already logged as a dated follow-up.

Do not hold the site hostage for a pixel the designer will debate for three days if the client’s blocker is content. Do not send a store that cannot check out because the hero feels “almost.” Judgment is the job. The checklist is the floor.

Tell the client what they are looking at

Your review email should state: what is in this URL, what is stubbed, what you already found and fixed, and what you want from them (acceptance of templates, copy, IA—not a hunt for CSS). That is client communication as QA, not as a disclosure seminar.

If copy is client-owned, your QA is “no lorem on legal pages” and “headings match the sitemap,” not a proofread of their brand voice unless you sold that. If you sold technical SEO, check titles, canonicals, redirects, and sitemap.xml before they ask. If you did not, do not silently skip it and hope.

Analytics is a classic last-mile miss. A missing tag looks like “the new site doesn’t convert” two months later. If GA or the equivalent was in the brief, the gate includes a real event on staging or a documented reason it cannot fire yet.

Pass one: partner says ready. You run the gate, file the batch, they fix. Pass two: you retest changed items plus the primary path, then schedule the client. Two passes. Not twelve. If pass two is still a mess, stop and have a vendor conversation with evidence. That is why you vet before the flagship.

Time-box pass one. A five-page site should not consume a day of AM anxiety. Use the checklist. If you keep finding issues outside the brief, either the brief was wrong or the partner is guessing. Fix the document; do not expand QA into unpaid product design.

Do not forward the staging URL “so the client can see progress.” Progress that looks broken is not progress in their mind. Take the partner conversation privately. Be specific: which acceptance criteria failed. If the miss is competence, that is a partner problem. If the miss is an unwritten requirement, that is your brief.

If you need a white label development partner who expects this gate, book a partnership discovery call. Bring how your team reviews—not a wish that QA happens by magic. The useful question is who clicks the site before the client does.

Keep the evidence. Screenshots, the brief section that failed, timestamps. A messy first pass is recoverable. A messy first pass plus a client-facing URL plus a vague “they’ll fix it” Slack is how you lose the room. If it happens twice on similar work, you have a partner problem. Once, with a thin brief, you have an intake problem. Name it so you do not fire the wrong thing.

After you recover, add the miss to the gate. If it was a footer credit, it becomes a brand-surface check. If it was a form to the wrong inbox, it becomes an integration smoke item. QA processes that do not learn are just anxiety with a checklist logo.