New here? Our first post covers the problem we’re solving — QA becoming the bottleneck AI-sped-up development can’t get past. This one’s about the solution.
Let’s get the obvious question out of the way first: no, we didn’t invent testing, CI/CD pipelines, or the idea of a server talking to a phone. Plenty of smart people solved pieces of this problem before us, and pretending otherwise would be dishonest. So here’s what we borrowed, what we didn’t, and — more usefully — what actually happens when your app runs through the platform.
What we borrowed, and who deserves the credit
Two ideas did most of the heavy lifting in shaping how we think about this problem.
The first is the CI/CD pipeline — the pattern nearly every engineering team already trusts to move code from commit to production reliably. Work gets queued, distributed, executed, and reported on, without a human babysitting every step. That shape maps almost perfectly onto testing too, so we leaned into it rather than inventing something unfamiliar.
The second is Maestro, the open-source mobile UI automation framework. Maestro proved that you could control a phone — tap it, swipe it, read what’s on screen — through a clean, simple interface that doesn’t care whether you’re holding an Android device or an iPhone. That idea, of hiding the platform underneath a single unified control layer, is directly baked into how our platform talks to devices. We’re glad it exists, and if you’re doing scripted mobile testing today, it’s worth a look regardless of what you do with us.
Where it stops looking familiar
Maestro, and tools like it, still expect a human to write the test. You decide the flow, you write the script, and the tool faithfully executes exactly what you told it to, every time, forever — until your app changes, and now someone has to go rewrite the script too. That’s fine for stable, slow-moving flows. It falls apart the moment your app is changing weekly, because AI-accelerated development means it probably is. Scripted testing was built for a world where the app changed slower than the tests. We’re not in that world anymore.
From “run exactly this” to “make sure this still works”
Instead of executing a script a human wrote, our platform is built around understanding what “correct” looks like and figuring out how to verify it — the same way a real QA tester would explore a new build without a step-by-step manual in hand. That’s the actual shift, and it’s the whole reason we’re building this instead of just using what’s already out there.
Self-healing beats “AI, please fix my tests”
Sure, you can already use AI to write those scripts for you, or ask it to patch them when they break. That helps, but it doesn’t remove the actual problem — a human still has to kick that off, and more importantly, still has to verify the result is actually right before trusting it. You’ve saved some typing, not the review burden.
That’s the part that falls away entirely on our platform. Tests self-heal when the app changes underneath them, and you can teach the system what “right” looks like along the way — mark a flow as one you trust, and that judgment persists across versions instead of evaporating the moment something shifts. If a flow you flagged as important ever needs healing, you’re told exactly that: this changed, it was healed automatically, here’s what to double-check if it matters. For anything mission-critical, that’s a five-second glance instead of a rewrite.
A day in the life of a test run
Here’s what that looks like in practice, without the jargon.
A developer pushes a change — a new checkout flow, say. Instead of someone on the QA team clearing their afternoon to manually click through it, or waiting for someone to update a brittle test script, the platform picks up the change on its own — at two different levels, each doing a different job.
Level one: catching problems the moment they’re introduced
The first pass is fast and narrow. It figures out what actually needs verifying based on what changed, not a script someone wrote three months ago that may or may not still reflect reality. It reaches out to a real device — physical or virtual, doesn’t matter — and works through the affected flow the way a person would: opening the app, finding the right buttons, filling in the right fields, noticing what’s on screen as it goes rather than blindly trusting fixed coordinates that might have moved.
This is the “shift left” idea QA teams have chased for years — find problems the moment they’re introduced, not days later — and it gets the developer a signal before they’ve even moved on to the next task.
Level two: proving the whole app still works
A handful of targeted checks based on what changed in the code can only tell you so much, though. It can’t give you real confidence in the app as a whole, because plenty of things break in ways that have nothing to do with the specific lines that changed.
So alongside it, the platform also runs a full app scan. It starts by diffing the new version against the previous one, so it knows exactly where to focus — a screen that wasn’t there before, a button that showed up out of nowhere, anything not yet covered by an existing test. From there it works through the app end to end, the way a real user would, screen by screen, button by button, not just the parts a diff happened to touch. The tests you’ve saved before are part of this too — they run every time, and results are compared version over version, so you can see not just pass or fail but whether something got better, worse, or stayed exactly as trustworthy as it was. Because this scan works entirely off the app itself, it doesn’t need your source code, your commit history, or any special access. All it needs is the app, the same way your users have it.
When something breaks
If either pass finds something wrong — a broken button, a screen that never loads, a flow that dead-ends — it doesn’t just say “test failed” and leave you to figure out the rest. Every bug report comes with:
- A screenshot of the moment things went wrong
- An annotated version of that screenshot, with the actual problem highlighted so you’re not hunting for it
- A video of the full run, so anything that isn’t obvious from a single frame — timing, a flicker, a flow that unwound in the wrong order — is still visible
- Plain-text, step-by-step reproduction instructions: click this, fill in that, in this order
Enough detail that a developer, or an AI agent working on their behalf, knows exactly what broke and how to see it happen again — no guesswork on either side.
If everything checks out instead, the team gets a clean signal that this change is safe to ship, and nobody had to spend their afternoon proving it by hand.
The result isn’t “QA got automated away.” It’s QA getting its time back — spent finding and understanding real problems, instead of burning hours either testing manually or patching test scripts that broke for reasons that had nothing to do with an actual bug.
Why this matters if you’re shipping fast
If your team has embraced AI-accelerated development, this is the piece that’s been missing. You don’t have to choose between shipping fast and shipping safely. The bottleneck was never really “testing” — it was always “keeping testing honest while everything around it keeps changing.” Solve that, and speed and quality stop being a trade-off.
That’s what we’re building. If it sounds like the gap your team is living with right now, we’d love for you to be one of the first to try it.