QA has an awkward problem: when it's done well, it's invisible. The client sees a site that works and assumes that's simply what websites do. All the broken links, stray filler and missing labels you caught never existed, as far as they know.
That's fine until budgets get tight and someone asks why QA takes a day. Making the work visible helps clients understand what they're paying for, and gives you a record if something comes up after launch.
Put QA in the proposal
If QA isn't a line in the proposal, it looks like overhead. Name it as a stage of the project, with what it covers. Clients rarely push back on a step they agreed to at the start.
Report on it at handover
A short summary at handover goes a long way: how many pages were checked, what kinds of issues were found and fixed, and anything still outstanding. It turns an invisible step into a visible deliverable.
Pages checked: [number] pages, including all CMS templates.
What we checked: placeholder copy, broken links, alt text and accessibility basics, forms, and every page against the approved design.
Fixed before launch: [short list of the main issues found and fixed]
Outstanding: [anything agreed for after launch, or “none”]
Checked on: [date] on staging, and [date] on the live domain.
Show before and after
Nothing makes the value clearer than a before-and-after. A first scan with a list of issues, and a final scan with them resolved, tells the story better than any explanation. Screenshots of the two are enough.
If you run QA in Frank, you can share the reports themselves. Turn on a link from any finished scan and your client opens it without logging in, with every page next to its Figma design and the issues grouped by type.
Clients don't want a forty-page audit. They want to know it was checked, what was fixed and that it's ready. Half a page is plenty.
Keep the record
The other reason to document QA is protection. If a client says something was broken at handover, a dated record of what was checked and when settles the question quickly and calmly.
Do This
- Name QA as a stage in the proposal
- Send a short summary at handover
- Show a before-and-after
- Keep a dated record of every check
Avoid This
- Leaving QA invisible until something breaks
- Sending a raw list of every minor issue
- Overselling: no QA catches everything
- Deleting records once the project closes
Explain issues in plain language
Clients don't need to know what a positive tabindex is. They need to know what the problem would have meant for their visitors. “A few links pointed to pages that no longer exist” lands better than “14 4xx errors resolved”.
Translate the technical findings into what they protect: visitors who can find what they're looking for, a site that works with a screen reader, no filler text in front of customers. That's the value, in the client's terms.
Use it to win the next project
A clear record of QA is useful long after handover. It's evidence of how you work, and it's a natural thing to mention when a client is deciding whether to come back to you, or when a new client asks how you make sure sites are launch-ready.
Agencies that can show their process, rather than just describe it, tend to have an easier time justifying their prices.
No QA process catches everything. Describe what you checked and what you found, not that the site is perfect. Clients trust a precise claim far more than a sweeping one.
Frank keeps every scan on the project, with a score for each page and every issue found, so you always have a dated before-and-after to draw on when you write up your handover. Get started with Frank →
Make Good QA Visible
Name it, summarise it and keep the record, so clients see the work behind a clean launch.
