TouchrockAIYour developers are still your testers.
- A story is “done,” then comes back from staging.
- Your users find bugs your team should have caught.
- Acceptance criteria get written, but nobody checks them one by one.
- You know you need a QA engineer, but hiring one is a project of its own.
These aren’t separate problems. They’re what happens when testing has no owner.
Every story your developers check by hand is time they aren’t building.
How it will work for your team
No new tool to run. We’ll adapt to your web product, starting with the first story your team finishes. You move a story to testing, as you do today. Writing the tests, running them, and reviewing the bugs will be on us. Our goal: serious bugs in new stories never reach your users.
Connect
We’ll connect to your tracker with an account you can revoke.
Move a story to testing
Ready for QA, or whatever your board calls it. That’s the trigger.
Two filters
The AI covers more than a person has time to. A QA engineer with 7 years of experience makes sure what reaches you is worth your time.
You get it where you work
Reviewed bugs reach your tool with steps to reproduce and evidence. Unclear criteria come back as a written note.
The AI can’t publish. The AI that designs the tests can’t publish, approve, or change anything in the tracker.
What working together would look like
You’d bring
- A test environment with synthetic data. Never production.
- Test logins and a tracker account your team can revoke. No source code.
- Stories with acceptance criteria.
- A kickoff call.
You’d get
- Each new story tested when it moves to testing, with its test cases and results.
- Reviewed bugs in your tool, with steps to reproduce and evidence.
- Unclear criteria flagged in writing.
- A written weekly summary, and written answers within 2 business days.
- A 30-minute monthly review.
- What we build stays with you: test cases, results, and approved bugs.
We’d start with one team and one web app, up to 8 developers. Bigger company? Start with one squad. Before anything runs, we agree in writing on the scope, monthly story volume, what success means for you, and how fast results come back. Month to month, no long-term contract. The first month is your real test of it: you can stop at the end of any month.
- You apply
- Short call
- Written agreement
- You share test logins and a tracker account
- Kickoff
- First story tested
You’re not buying hours. You’re buying answers.
A person on a deadline has to choose what to test. The AI doesn’t. It works through every acceptance criterion, then a long list of known ways software breaks: empty fields, limits, odd formats. Same rigor on story 100 as on story 1.
Then a QA engineer decides what’s real and what to fix first. What reaches your team is already checked and in order.
Keep your ceremonies. We don’t need a seat in them. We read the story, ask in writing, and answer on the ticket.
Why become a founding member
Founding members are the first teams we work with. We onboard a few teams at a time, because every result gets human review. If we’re full, you join the waitlist while we grow the team.
Built around your team
The work we do with you guides what we build next. Your tools and your stories come first.
First in line
You’d be among the first teams we work with.
The founder reads your bugs
No sales team in between. You talk to the person building it, and he reviews your results himself.
First step: a short call about how testing works on your team.
A good fit if you build a web app and testing has no clear owner yet, even if you’re trying to hire one.
Not a fit yet if you need native mobile, load, or dedicated security testing, a full regression pass on every release, or you have no test environment. Same for teams that decide things out loud and never write them on the story.
Who’s behind it
I’ve worked in QA for 7 years.
On many web teams, testing gets pushed to the end of the sprint, then to the developers, then to your users. So I’m building a service where an AI agent does the repetitive part and I do the part that needs judgment: deciding which failures are real bugs.
Because I review everything myself, I’d rather work with a few teams and do it well. The next step is real teams, so I’m looking for a few to build it with.
QA Engineer, founder of TouchrockAI
Questions
What does it cost?
We’re not publishing pricing yet. It would be a monthly price per team, not per hour. If it looks like a fit, we’ll talk it through with you.
Should we just hire a QA engineer?
If you want someone in your standups who owns regression and releases every day, hire one. This is for teams that can’t fill that seat yet: each new story would get tested when it’s finished, and a QA engineer would review every result. It would work while you’re still hiring, too.
How fast would results come back?
The agent starts when a story moves to testing. Then a person reviews it. Our starting target for a reviewed result is 2 business days, and the agreement can tighten it to what your team needs and what we can keep.
Is it really one person?
Today, yes. The founder reviews every result, which is why we’ll take a few teams at a time and would grow the team if demand calls for it. If he’s away, bugs wait as drafts and we’d tell you ahead of time. Nothing reaches your board unreviewed. Human review stays while we build; if that ever changes, it’ll be with numbers behind it, and we’d tell you first.
Can’t we build this ourselves with an agent and Playwright?
You can. Then someone on your team owns it: keeping it running and reading every failure it raises. That’s the job we’d take on.
Does it cover regression?
Each story will be tested when it moves to testing. A full regression on every release isn’t covered today, so keep your pre-release check for now. By release, new stories have already been tested, so that check can focus on what already worked. An automated test base that grows with every story is the goal, not something delivered today.
What would the AI see?
The pages and network traffic of your test environment, the stories and documents you share, and the test logins you give us. Those go to a third-party AI model, so keep real personal data out of your test environment. The written agreement names the AI provider and sets how that data is handled, before any test runs.
Won’t an AI flood our board with false alarms?
The AI does raise false alarms. That’s exactly why no draft goes straight to your board. A QA engineer reads the evidence and decides if it’s real. What isn’t approved doesn’t reach you.
Which tools will it work with?
We’d connect to the tools your team uses, one at a time. Tell us yours in your application and we’ll tell you where it stands.
Who is behind TouchrockAI?
Merex Tech LLC, a Florida company. TouchrockAI is its brand, and Franco Colombo is building it from Argentina.
Become a founding member
A short application. The founder reads every one and replies personally. If it looks like a fit, he proposes a short call. No commitment.