Your Client Is Not Your QA Team

You know this email. You've written that reply. And as you're fixing a form that wasn't connected properly, a footer you tested on desktop but not mobile, and a nav link that broke after a last-minute page rename — you're quietly calculating how much this is costing you.

Here's the thing: your client finding bugs is not a technology problem. It's a systems problem. And it's fixable.

The Hidden Cost of Client-Found Bugs

The obvious cost is the fix time. A broken form, a stray lorem ipsum, a 404 — these are individually quick to resolve. But the real cost is what surrounds the fix:

At a £75–150/hour agency rate, a single post-launch bug email costs you £300–750 in unplanned time. Multiply that by how many projects you ship per year and you have a meaningful line item that doesn't appear on any invoice because it was never planned for.

"The bug itself is cheap to fix. What's expensive is everything around the bug — the interruption, the relationship cost, the reputation repair."

Why It Keeps Happening (Even to Good Agencies)

Client-found bugs aren't a sign of incompetence. They're a predictable result of how manual QA works under real project conditions.

1. Deadline pressure compresses QA

QA lives at the end of the project. It's the thing you do after everything else is done and the client is asking where their site is. When time is tight, the QA window shrinks. You check the homepage and the key landing pages. You test on desktop. You submit the contact form once and it works. Ship it.

2. Familiarity blindness

You've looked at this site for weeks. Your brain fills in the gaps. That lorem ipsum in the blog sidebar doesn't register because your eyes have stopped seeing it. Your client, seeing the site fresh for the first time, spots it immediately.

3. QA is inconsistent between team members

If you have a team, "we QA'd it" means different things depending on who ran the check. One developer checks broken links thoroughly but skips mobile. Another focuses on the CMS but misses the static pages. There's no shared standard, no record of what was actually tested.

4. Last-minute changes break things

The client asked for one more change the day before launch. You made it in five minutes — and accidentally broke a link or reset a form setting in the process. You didn't recheck everything because it was "just a small change."

5. Staging doesn't replicate production exactly

Some integrations behave differently on staging vs live. Forms connected to Zapier or HubSpot can work on staging and fail on production because the webhook URL changes when the domain connects. These are the bugs that hurt the most because you genuinely couldn't have caught them without a proper production test.

What the Good Agencies Do Differently

The agencies that consistently ship clean sites without client-found bugs don't have magic or more time. They have a systematic QA process that runs every time, on every project, before any client sees a staging link.

The key differences:

• QA is a separate, scheduled phase — not something that happens "as we go" or in the last hour before handover
• QA happens on the published staging URL — not in the Designer, not in preview mode, not locally
• They produce a record of what was checked — a report or sign-off that protects them if the client later says "it was broken when you handed it over"
• They get client approval before going live — a shared review link that requires explicit sign-off, creating a clear moment that says "you approved this"
• They don't rely on memory — they use a consistent checklist or tool that runs the same checks every time, regardless of deadline pressure

What Clients Actually Think When They Find a Bug

Here's what your client thinks when they find the lorem ipsum, but doesn't say:

"If they missed this, what else did they miss? Should I be checking the whole site more carefully? Is this normal? Did I pay for something that wasn't properly checked? Would a bigger agency have caught this?"

One bug is a small thing. One bug, however, activates doubt — and doubt is expensive to rebuild. It shows up in slower approval on the next project, more detailed feedback requests, tighter scope negotiations, and occasionally in losing a renewal or referral that you never know you lost.
‍

Clean launches don't just save time. They compound. A client who receives a clean, well-tested site on time is a client who refers you, gives you less friction on the next project, and trusts your process enough to let you run it.

The Practical Fix: Make QA Non-Negotiable

You don't need a big team or expensive software to stop your clients finding bugs before you do. You need to do three things:

Make Frank Your First Line of QA

Frank checks every page of your staging site for placeholder copy, broken links, missing alt text and design drift before your client ever sees it. Run a scan before every handover, and the email at the top of this post stops arriving.

See plans and pricing →