The Next 10 Years Starts Now

Most people underestimate mobile testing.

There’s a saying in the mobile app testing world: the winner is the one who sucks the least. It sounds harsh, but it’s also painfully accurate. The mobile ecosystem is chaotic. Devices differ. OS updates break things. Networks wobble. Permissions change. Popups appear at the worst time. Automation flakes for reasons that have nothing to do with your code.

So “winning” in mobile device testing is rarely about perfection. It’s about reducing failure modes, removing friction, and building a system that behaves predictably in an environment that isn’t.

People often think mobile app testing is a tooling problem. Or a process problem.

If you have actually lived inside mobile testing, you know the truth: it is a systems problem. Hardware, OS quirks, flaky networks, popups, security policies, device farms, USB chaos, brittle selectors, test data, and the fact that your users live on real devices in the real world.

That is why this milestone matters.

Today marks 10 years of Kobiton. Ten years of learning, correcting, rebuilding, and trying again. Ten years of doing mobile testing the hard way, on real phones and tablets, under real constraints. Ten years of being humbled by iOS and Android more times than I can count.

And the reason I’m writing this is not to take a victory lap.

It’s to tell the story of what it actually takes to solve mobile app testing at scale, and why I believe the next chapter is the most important one.

The problem we chose was not “testing”, it was reality

The best product ideas start with a stubborn, persistent problem.

Back when Kobiton was founded, there were plenty of ways to test mobile apps “in theory.” You could run emulators. You could run simulators. You could stitch together a lab in a back room. You could outsource a chunk of it and hope the results matched production.

But mobile testing only gets serious when it becomes real. Real devices. Real hardware. Real OS versions. Real performance characteristics. Real crashes. Real interruptions. Real user flows that don’t follow your happy path.

That gap between theory and reality was the opportunity.

We didn’t start Kobiton because we thought testing was interesting. We started because we believed the industry was stuck in the wrong abstraction. Teams needed mobile device testing on real devices, but the cost and complexity kept it out of reach for too many builders.

So we decided to make real-device mobile app testing accessible.

Not as a nice-to-have. As the default.

Repeat founders, same instinct: remove friction for builders

Kobiton was founded by Josh Lieberman and Vu Lam, the same two people who founded QASymphony (qTest that merged with Tricentis) and Katalon.

That matters, not because of resume points, but because repeat founders tend to carry a pattern. They develop an intolerance for unnecessary friction. They have scar tissue around what kills adoption. And they tend to focus on leverage.

The instinct here was simple: mobile testing was becoming essential, but real-device access was still gated. If we could remove the infrastructure burden, teams could move faster, ship with confidence, and stop arguing about whether a bug “reproduces on my phone.”

That was the bet.

And like most good bets, it started with a model that made sense on paper, and then got punched in the face by reality.

The original business model was early, maybe too early

At the beginning, the plan was to use the gig economy to host devices with minimal infrastructure, and allow developers to access those devices on demand.

Think of it as “Airbnb for real phones,” but for mobile app testing.

It was a logical model. It matched the direction of marketplaces at the time. It aimed at the core constraint: device access. It tried to eliminate the heavy lift of building and maintaining labs.

Ten years later, I’m watching a brand-new startup (Vibium) propose essentially the same business model.

That is not a knock on them. It is proof that the idea is persistent.

Sometimes you are wrong. Sometimes you are early.

Being early looks a lot like being wrong, until the world catches up.

Enterprise interest forced a pivot, fast

Not a year later. Not after we had everything “ready.”

Quickly.

When serious teams do mobile device testing, they don’t just need devices. They need reliability, security, compliance, performance, governance, and support. They need predictable results, because they are shipping important software to millions of users.

So we pivoted.

In 2017, we set up a data center footprint at Digital Realty. Two months after we launched the product in August 2017, Office Depot became our first enterprise customer. Six months after that, we secured our first $100K ARR customer.

Those details matter because they explain the shape of the company.

We didn’t build Kobiton as an enterprise product because it sounded impressive. We built it that way because enterprise needs are the sharp edge of mobile app testing. If you can survive those constraints, you learn things you cannot learn in a small lab.

That pivot also set the stage for everything that followed, including our relationship with automation, and our long, occasionally painful journey with Appium.

The early signal: AI was coming, even if it wasn’t ready

In the first month, I went to Raleigh for a testing conference and met Jason Arbon, who had just started test.ai, and Moshe Milman, the founder of Applitools (a Kobiton partner now).

If you were paying attention back then, you could see it. AI was peeking its head out.

Not as hype. Not as “replace testers.” As a genuine attempt to help teams do the parts of mobile testing that humans are forced to do because tools are brittle.

The promise was simple: reduce the manual grind. Reduce the maintenance burden. Reduce the time spent chasing flaky failures that do not represent real product risk.

We didn’t leave that conference with a magic plan.

But we left with a conviction: AI would become a major force in mobile app testing. And if you were building a real-device platform, you needed to think seriously about how to use that reality stream as fuel.

Our first AI attempt failed, and it deserved to fail

By the end of 2018, we started our AI journey. It was originally titled “Appium Booster.” The purpose was to generate an Appium script from a manual test session.

The idea sounds obvious today. Back then, it was brutally hard.

We got it wrong.

To generate an Appium script, you need structure. In practice, you need the device XML (or view tree) and the screenshot, so you can understand what element the user interacted with, and how to find it again.

The catch is that collecting XML from a device is slow. It is still slow today.

We didn’t want to degrade the user experience during manual sessions, so we tried to do the extraction after the session ended. Our approach was to rerun the test session on the same device and collect the XML and screenshots during the replay.

And then reality happened.

We underestimated state changes during a session. Popups. App crashes. Network disconnects. Dialog boxes that appear once and never appear again. Timing differences. The subtle chaos that makes mobile device testing hard in the first place.

Our success rate was under 50%.

It was a failure.

But it was the right kind of failure. It taught us a hard product lesson that applies far beyond AI: you do not get to pretend your system is deterministic when it isn’t. If your platform cannot cope with the mess of real devices, it will not earn trust.

That failure forced us to rethink how we capture “device exhaust,” how we stream it, and how we build automation that respects the reality of mobile testing instead of fighting it.

The Mobile Labs acquisition: our knight in shining armor

In November 2020, Kobiton acquired Mobile Labs.

At the time, Mobile Labs had roughly 5x the revenue of Kobiton. Mobile Labs brought great device connectivity technology, and valuable IP that extracted device exhaust in milliseconds. Kobiton brought a modern UI and an AI direction we believed in.

On paper, it was a strong combination.

A year later, the technical integration was complete and deployed to the cloud. Then came the next hard requirement: package everything, including the AI models, into a Dell server and deploy it in a Fortune 100 environment.

This is not a small detail. It’s one thing to run AI in the cloud. It’s another thing to run AI inside an on-prem environment, next to hundreds of devices, under strict security constraints, with predictable performance.

We delivered that in mid-2022, months before ChatGPT 3.5 changed the public conversation about AI.

The timing matters because it highlights a truth: serious mobile app testing teams do not care about hype. They care about outcomes, security, and reliability. They want the benefits of AI, but they will not sacrifice governance to get it.

Scale is the teacher you cannot fake

By this point, we had customers deploying thousands of devices on every continent except Antarctica.

That scale changes you.

At small scale, you can treat failures as exceptions. At large scale, you learn that failures are a design constraint. You build for resilience. You build for observability. You build for operational sanity, because your customers’ release trains depend on your platform behaving like infrastructure.

Across our on-premises customers and cloud customers, Kobiton has supported over 700 million minutes of testing.

That number is not meant to impress anyone. It is meant to make a point: mobile testing at scale is not a feature. It is a capability. It is built over years through thousands of sharp-edged lessons.

We are fortunate to serve customers that include some of the largest travel and leisure companies, financial institutions, government, mobile gaming, and healthcare organizations in the world.

That diversity matters too. Every industry stresses the platform differently. Security and compliance in finance. Performance and churn sensitivity in gaming. Device sprawl in travel and consumer apps. Reliability expectations everywhere.

If you want to build a platform for mobile device testing, you don’t get to pick one comfortable environment. You earn trust across the full spectrum of messy reality.

The double moat is real, and it was expensive to build

I see browser-based competitors trying to build AI “on top of mobile,” and I smile.

Not because I think they’re foolish. Because I know the road they are about to walk.

AI for mobile app testing is only as good as the data you can extract from the device, and the speed and fidelity with which you can deliver that data to an inference engine.

This is where we have what I think of as a double moat.

First moat: we have unique technology that extracts device exhaust efficiently. XML, screenshots, logs, video, and the surrounding metadata that makes it useful.

Second moat: we stream that exhaust in near real time to AI inference engines, so we can generate an Appium script and run no-code automation within seconds after a test session finishes.

That is not “AI added to a dashboard.” That is AI integrated into the core reality stream of mobile device testing.

And yes, we are still working through kinks. Some days, AI plus mobile feels like death by a thousand cuts, or a thousand iOS bugs. The mobile ecosystem does not sit still. OS updates break things. Vendor stacks change. New devices behave differently. Permissions shift. Popups evolve. App frameworks change how elements are exposed.

But the direction is clear.

We have learned how to take reality, convert it into structured signals, and turn those signals into automation outcomes. That’s the key to making Appium and modern automation usable at enterprise scale without drowning teams in maintenance.

This is also why we are seeing more of our competitors’ customers coming over to Kobiton. They are not just buying device access. They are buying the ability to run mobile testing with speed and confidence, without building an internal platform team to keep the lab alive.

Profitability changed the company, and 2026 is about growth

Almost a year ago, we turned cash flow positive.

That was difficult.

Not in the abstract. In the day-to-day, grinding way. Prioritization. Tradeoffs. Saying no to good ideas to protect the critical ones. Tightening operations. Reducing waste. Raising the bar on execution.

I’m grateful to Erin Bailey, Stu Hume, and David Hand for pushing through the hard work to make the company profitable. It is not glamorous work, but it creates the conditions for everything else.

Profitability also brings clarity. You stop confusing activity with progress. You focus on outcomes. You start thinking more like a long-term product company again, not a company trying to survive its next quarter.

And that is exactly what 2026 represents for us.

2026 is a year of growth.

Not growth for vanity. Growth because the market is finally aligning with the thing we have been building toward for years: AI-assisted, real-device, enterprise-grade mobile app testing.

What we believe now, after ten years

Let me end with the lessons I think matter most.

1. You need an integrated system that earns trust.
2. Real devices are non-negotiable. Simulators and emulators are helpful, but they are not reality.
3. Automation is not the goal. Release confidence is the goal.
4. AI only works when it is fed high-quality reality signals. If you can’t extract and stream the data, you don’t have a foundation.
5. Scale is the truth serum. It exposes every shortcut.
6. The hardest problems are the ones worth solving. If it was easy, it would already be solved.

Thank you

I’m grateful for our customers, partners, employees, and investors who have supported us through this journey.

Ten years is a long time in tech. In mobile app testing, it is a lifetime.

But I’ll tell you what I actually feel most strongly: we are early again.

The industry is just waking up to what it means to combine AI with real-device mobile testing. Many teams are about to learn the hard lessons we’ve already learned. Some will try to bolt AI onto old models. Some will try to pretend that browser-based abstractions are enough. Some will get frustrated and conclude that AI “doesn’t work for mobile.”

We know it can work. We also know it requires doing the hard parts, the unglamorous parts, the infrastructure parts, and the data parts.

We’ve spent ten years earning that capability.

Now we get to use it.

Here’s to the next chapter of mobile device testing, and to making Appium and AI agentic-based automation feel less like a fragile science project and more like a reliable partner for the teams building the apps we all depend on.