The background
Four industries with almost nothing in common. Fintech, where a failed verification is a compliance problem. Food delivery, where traffic spikes are the normal state. OTT streaming, where the device matrix is the test plan. And before any of it, five years running a web hosting and development business I founded single-handed — the sites, the servers under them, and the testing.
Different products, different stakes, different decades of tooling. The same bottleneck in every one of them.
And in those years I built the thing Trq replaces, repeatedly: test environments in Docker, workflows orchestrated through Netflix Conductor, Selenium and JMeter suites maintained by hand. I am not an outsider with an opinion about automation frameworks. I have carried them.
Why Trq exists
Two years ago the shape of a release was predictable. A feature took days — code written by hand, PR review, dev testing — and that window was the window. While developers built, testers read the spec, wrote cases, built the automation. By the time the build landed, the suite was ready for it.
Then features started arriving in hours.
The build side got dramatically faster. The test side didn't, because writing cases by hand, reviewing them, and standing up an automation framework takes exactly as long as it always did. So the queue moved. Development finishes in an afternoon and waits three days for QA.
AI didn't remove the bottleneck.
It moved it.
Across every one of those teams the timeline only ever got shorter, and I kept watching good engineers get squeezed into a corner where starting automation was never worth it. Not because they couldn't code; most of them can. Because the payback window had disappeared. A framework you spend two weeks standing up assumes you'll get two weeks back. That assumption quietly stopped being true.
So the question became: what would testing look like if it had to match the speed of an AI-assisted build? Not a faster way to write framework code — no framework at all.
What that turned into
One tool, three targets
Web, native Android and API in a single desktop app — and a single journey, so a value captured on a page can be spent in an API call and asserted on a device.
Nothing to stand up
No project, no build file, no runner, no report plugin. Record or build a case, run it, share the report.
Still a real engineering tool
Variables, environments, conditions, reusable flows, a CLI for CI. No-code where it helps; escape hatches where it doesn't.