QA Is Boring. Until Your Client Finds a Bug at 4pm on a Friday.
I'm not building a QA platform because I'm passionate about QA. I'm building it because I'm afraid of failing clients.
During my demo, I got that sinking feeling I'd lost touch with the audience. Even on Zoom, I could see it: eyes glazed over, one person looking down at their phone, crickets when I asked about the noindex settings and H tag hierarchy checks.
And I get it. QA is boring.
QA is a line item in a proposal, an assumed part of every project, invisible until something goes wrong. It’s like auto insurance. No one wants to pay for it until there’s an accident.
It’s also the thing that’s most often shortcut under the crush of deadlines. I treated it that way too. Longer than I'd care to admit.
The Wake-Up Call
We had a rough couple of weeks last year with an agency client, whom we’ll call the ACME Group.
Incident #1: After a platform update, custom layouts for the blog “author” section broke. Ugly blue links covered the short bio. We tested the update in staging first, but testing was an unstructured clickthrough.
The client called ACME. ACME called us. Not a good look. Apologies ensued. We pushed a patch.
Incident #2: Same client. 3 days later. We stood up a new page, passed internal tests and then launched Thursday afternoon. Everything seemed fine. A day later, 4pm Friday, I get a call from the agency’s principal, as I walked into the gym.
“Hey Doug, it’s Cindy from ACME. We have a problem,” she said. The landing page we built was set to noindex. Translation: Google won’t see it. They caught the error during a routine SEO audit.
Ooof. Strike #2. My come-to-Jesus moment.
What Really Gets Broken
Shit happens. But when patterns emerge, it's a red flag.
The cost of shipping defects is not just the cost of a chaotic scramble to fix problems and smooth things over. The real cost is the trust you spend.
With the agency. With the agency’s client. And, really, with the agency’s client's clients: That person who lands on that broken bio at the end of an otherwise solid blog.
Do the math across a year. For a small team running on reputation, that's a recipe for slow-motion crash and burn.
Course Correction. Or: No More Unexpected Client Calls
With a small team and fast moving targets, I needed better QA tooling and automation to catch issues before they hit production.
I went deep. SEMrush. BrowserStack. LambdaTest. PageSpeed. GTmetrix. Screaming Frog. Grammarly. Each one solving a piece of the puzzle.
I’d need four tools and three subscriptions — including spell check — something Microsoft Word has done since 1995.
Worse: Each tool has its own mental models and scoring standards. We’d need a color-coded spreadsheet to keep track of all of it. Under deadline pressure, would we actually use it?
Ugh. There had to be a better way.
Somewhere Over the Andes
About a week later I was on a plane to Lima. On long flights, I can never sleep and rarely read or watch movies. With the sting of the QA failure still fresh in my mind, I thought: Can’t I just build what I need?
I started researching open source libraries and APIs. Link checks, spelling, grammar, performance, accessibility, SEO. And then the custom rules no one does: External links opening in a new window or finding double spaces in content. Small details, but a major pain to test.
The basics were clear: One login, all the tests, unified scoring. It seemed doable. Something I could prototype with help in a few months.
Somewhere over the Andes, I started writing.
By the time we landed, I had a rough spec and a new mantra: Move Fast, Don't Break Things. Less a promise than a core guiding principle.
Back home, I started building. I called it ReleasePass. It provides go/no-go launch guidance, and yes, one login. We started using it internally last month and it fits our needs better than anything we found on the market.
I can't imagine we're alone.
Interested in trying ReleasePass? We're looking for 4-5 agencies as "founding companies" to help guide the project. Email doug@4all.digital if you're interested.