Why we built GazelleQA

Where this actually comes from

This is not a story I borrowed from a podcast.

I have worked full time for several companies over the years · engineering firms, safety-related products, laboratory information systems. Different domains, different stacks, similar failure mode: something important in the business logic of the app regresses, it reaches production, and the first signal is rarely a green test suite. It is support tickets, angry emails, and escalations.

I am not going to dissect individual incidents here. The specifics belong to those customers and those codebases. What matters is the shape of the problem: critical paths that should have been guarded by regression coverage were not, or the coverage had rotted into noise, and the organization only fully felt the cost after users were already blocked.

What “impact” looked like

Blocked users · not “a minor UI glitch,” but workflows that could not complete. Angry customers who had paid for reliability. SLAs breached or bent under pressure while engineering and support chased root cause.

Sometimes the gap between “shipped” and “understood” was weeks. Sometimes the damage or the underlying bug sat quietly much longer · months or years before the full picture was clear. That last part is what sticks with you: the idea that production can be telling you everything is fine while reality is not.

Why the usual playbook stalls

Teams know they need automated checks. Many have tried Cypress, Playwright, or layers of unit tests. Those tools are good when someone can own selectors, timing, and refactors across releases.

In the environments I worked in, that owner was often missing, or spread too thin. Tests flaked. Suites fell behind the UI. CI turned into something people stopped trusting. Manual verification before a release helps, but it does not scale with velocity, and it does not catch every regression class.

The hard part has always been the same: turning human intent · “this workflow must still work end to end” · into something a machine can execute reliably without becoming a second product to maintain.

Why we are building AI-first QA

Large language models are strong at that translation step: from a plain description of what should happen in the browser to a plan, execution, and evidence.

GazelleQA is not “generate Playwright code and hand it to your repo.” It is closer to running the check like a careful tester would · in a real browser, with evaluation at each step and screenshots when something fails · without checking brittle scripts into your codebase. The model re-derives the test from your description when you run it, so you are not permanently married to selectors that changed three sprints ago.

What we need from people who live this

We are early. We have a prototype, a direction, and a list of questions only real usage can answer:

• Which flows do you need confidence on first · auth, approvals, reporting, integrations?
• How do you want runs triggered · on deploy, on a schedule, on demand?
• What should a failure report look like so the right engineer acts on it in one read?
• Where does an AI-driven run misunderstand your product in ways we did not expect?

If you are on the waitlist, you will be among the first to stress this in the wild. We want direct conversations, not checkbox surveys.

If you have lived the support-ticket-first regression cycle and have opinions about what should exist instead, tell us on the feedback page.

We are building in public. Follow along on Twitter.