Why Manual QA Doesn't Scale for Web Agencies

When you're a freelancer or a tiny studio taking on two or three projects at a time, manual QA works fine. You know every page of every site, you have time to click through everything properly, and when you miss something it's one client relationship you manage directly.
‍

Scale to ten, fifteen, twenty projects per quarter and the same manual process becomes an invisible structural problem. You're spending three to four hours on QA per project. That's 30–80 hours per quarter of skilled time doing something a machine could do faster and more reliably. And unlike the time you spend on design, development, or strategy, this time shows up nowhere on your invoices.
‍

This is the QA scaling problem. It's not dramatic — it doesn't cause a crisis. It just quietly taxes every project and gets worse the more clients you have.

‍

How QA Time Scales (And Why It's Non-Linear)

Here's why manual QA doesn't scale linearly with project volume:

The reason it's non-linear: as you take on more projects, the time pressure increases, which means QA gets compressed into tighter windows. Compressed QA means more things are missed. More missed issues means more post-launch fixes. Post-launch fixes create interruptions that disrupt current project work, which pushes those timelines, which compresses their QA windows. It's a compounding problem.

‍

The Four Ways Manual QA Breaks at Scale

1. Inconsistency across projects and team member

At one project with one person, the QA standard is whatever that person knows to check. At five projects with three people, you have three different standards, all called "QA." One checks links thoroughly. Another focuses on mobile. The third does a visual pass and calls it done. There's no shared record of what was actually tested on any project.

2. It gets skipped when deadlines are tight

QA is the last thing before launch. It's the thing that gets cut when a client says they need the site live tomorrow. Every experienced agency owner knows the feeling of making a calculated decision to skip the form test and just hope it works. Sometimes it does. Sometimes it absolutely does not.

"The times we got a post-launch bug report were almost always the projects where we'd had to rush the QA. It wasn't random, it was systematic."

3. Human attention is finite and degrades with repetition

The first time you QA a type of site, you catch everything. The fifteenth time you're checking the same category of checks on a similar site, your brain stops really seeing it. Familiarity blindness is a real cognitive phenomenon — your eye literally skips over things it expects to be correct. A machine that runs the same check every time doesn't get familiar with anything.

4. There's no audit trail

Manual QA leaves no record. When a client comes back two months after launch saying something was broken from day one, there's no way to prove it wasn't — because you didn't document what you checked. A QA report that shows what was tested, when, and by what method is protection. A memory of "I'm pretty sure we checked that" is not.

‍

What Scales Instead

The solution isn't to hire a dedicated QA person at 15 projects per quarter (though at 30+ that becomes reasonable). It's to automate the repetitive, consistent parts of QA that are well-defined and machine-checkable — so your human attention is reserved for judgment calls and edge cases.

Automation doesn't replace the judgment calls — the "does this feel right" review, the accessibility assessment, the cross-browser testing, the UX walkthrough. It replaces the mechanical, rule-based checks that a machine can do perfectly every time: is there placeholder text? Do all the links resolve? Does the build match the Figma spec? Is the alt text present?
‍

Once you've automated those checks, your human QA time goes from covering everything (badly) to covering only the things that need judgment (well). That's the shift that scales.

‍

The Right Division of Labour

Here's how the best-run agencies split the QA responsibility between human and machine:
‍

• Automated: Broken links, 404s, lorem ipsum and placeholder text, Figma colour/font/spacing parity, missing alt text, page-level crawl and structure
• Human: Does the design feel right? Does the copy make sense? Is the user journey intuitive? Are there any edge cases the automated scan wouldn't catch? Does the form email land in the right inbox?

The automated pass takes seconds and produces a report. The human pass focuses on quality, not coverage. Together they're faster and more thorough than either one alone.

‍

What Beta Users Get That Nobody Else Will

Frank is in beta right now, which means we're actively building with a small group of agencies who are using it on real projects. If you join during this window, you get four things that aren't available at any other point:
‍

• Free access — Frank is completely free during the beta period. No credit card, no catch.
• A founding rate — when paid plans launch, beta users lock in a price that will never be offered to anyone else. If Frank becomes part of your workflow now, you'll never pay the standard rate.
• A seat at the table — we're building Frank's feature roadmap based on what beta users tell us they need. Your feedback directly shapes what ships next. We have a private community where beta users share case studies, vote on features, and get early access to new checks before anyone else.
• The option to be a case study — if you want to be featured as a founding agency in Frank's launch story, we'd love to work with you. Real agencies, real numbers, real results.

Beta closes when it closes. Once we move to paid plans, the founding rate goes with it.