Why We Built DeviceLab: From Enterprise to SaaS

For the past decade, we've been building enterprise device testing infrastructure. Our solution deploys on-premise in company data centers - financial data companies, e-commerce giants, telecom behemoths - all have used use it to create their own secure device labs. We built this because we understood that these organizations could never put their sensitive applications on public cloud testing services. Banking apps contain financial data, healthcare apps handle patient information, unreleased apps contain years of R&D. These companies needed complete control over their testing infrastructure.

Our enterprise solution gives them exactly that: complete control, absolute privacy, unlimited testing. Each company runs their own instance, on their own servers, with their own devices. Their data never leaves their premises. They can even connect devices from different locations - as long as those devices follow their network policies, they become part of the lab.

But here's what bothered us: While enterprises were deploying our solution in their data centers, we'd regularly hear from startups and small teams with the exact same concerns. They'd say things like "We're handling medical records" or "This app has our entire business logic" or "Our investors would kill us if this leaked." They understood the risks just as well as the enterprises did.

The difference? They couldn't find it financial feasible to create and manage an on-premise deployment for relatively fewer devices.

So these security-conscious founders would do something that made no sense. They'd architect their entire backend to be secure, keep their staging servers completely private, implement end-to-end encryption... and then, wait for it, upload their app to a public device lab. They'd literally tunnel their "secure" staging environment to public cloud devices, defeating the entire purpose of keeping it private in the first place.

When I asked why, the answer was always a shrug. "What choice do we have? We need to test somehow."

The tragedy was that these teams actually had devices. I'd visit their offices and see iPhones and Android phones scattered on desks, sitting in drawers, forgotten in laptop bags. They were paying monthly fees to rent someone else's devices while their own collected dust. The reason was simple: connecting those devices to their CI/CD pipeline meant days/weeks of DevOps work they couldn't afford. Setting up device labs isn't their core business - they want to build their product, not solve infrastructure problems. They shouldn't have to become device lab experts just to test their apps securely.

This paradox ate at me. Privacy and security had become a function of company size. Enterprises got privacy because they could deploy our solution. Everyone else compromised their security not because they wanted to, but because they had no alternative.

We decided to bridge this gap with a SaaS offering. We had two options: adapt our existing enterprise solution into a SaaS, or build something completely new.

The obvious choice seemed to be adapting what we had. Our enterprise solution was battle-tested, feature-complete, and proven over 10 years. We could host it ourselves, let customers connect their devices to our cloud, and handle all the complexity for them. Users would upload their APKs to our servers, we'd manage the orchestration, and they'd get enterprise-grade testing without the deployment overhead.

But when we mapped out this architecture, a fundamental problem emerged: customers' apps and test data would still flow through our infrastructure. Yes, we were trustworthy. Yes, we'd been handling enterprise customers for a decade. But we'd just be creating another version of a public device lab - maybe using their own devices, maybe cheaper, but still asking customers to trust us with their unreleased apps and test data.

That's when we asked ourselves: If you had the option to never send your unreleased app through a third party, wouldn't you take it? Your API keys, test credentials, customer data, staging environment access - none of it leaving your network. It's just common sense. Why expose your intellectual property if you don't have to?

Every solution in the market assumed data had to flow through some central infrastructure. Our own enterprise solution, despite being on-premises, still routed everything through a central server. But what if teams didn't need us to manage their data? They already had devices. They already had networks. They already had CI/CD pipelines. Maybe they just needed something to connect it all together without touching their data.

This realisation led us to build DeviceLab from scratch with a radical constraint: we would never touch customer data. Not "we promise not to look at it" but "we physically can't access it."

We built DeviceLab without an upload mechanism - your app literally cannot be uploaded to our servers even if you wanted to. We used peer-to-peer connections between test nodes and device nodes, so data flows directly between your devices without passing through us. From the developer's perspective, there's no difference from running tests locally - no code changes needed. If DeviceLab disappeared tomorrow, your tests would still run. Logs stay on your devices by default.

The architecture was so different from our enterprise solution that we couldn't reuse anything. Where our enterprise product had central servers for orchestration, DeviceLab had peer-to-peer connections. Where our enterprise product stored test artifacts, DeviceLab stored nothing. Where our enterprise product required IT teams to configure, DeviceLab worked with one curl command.

We also made a conscious decision: no different treatment based on financial status. Whether you're a two-person startup or a Fortune 500 company, you get the same data privacy. Your app stays on your network. Your test data flows between your devices. You maintain complete control. The only difference is how many devices you connect.

Looking back at the journey from our enterprise solution to DeviceLab, the biggest lesson wasn't technical. It was philosophical. For years, we assumed that complexity was the price of privacy. But that was a false trade-off. Privacy doesn't require complexity. It requires the right architecture.

By starting from scratch and refusing to touch customer data, we found a simpler path. No central servers to manage. No databases to secure. No infrastructure to deploy. Just devices connecting directly to each other, keeping data where it belongs - with the customer.

Today, DeviceLab serves everyone from two-person startups to Fortune 500 companies. They all use the same product, pay the same price, and get the same privacy. That's how it should be. Privacy shouldn't depend on your budget. Security shouldn't be a luxury. And choosing between simplicity and sovereignty shouldn't be a choice at all.

That's why we built DeviceLab. Not to make testing cheaper, though we did. Not to make it easier, though we did. We built it to make privacy accessible to everyone. Because your data should stay your data, whether you're a Fortune 500 bank or two founders in a garage.

The enterprise testing infrastructure market we've served for a decade will continue to thrive. Many companies need the full control and customization that our enterprise solution provides. But for the thousands of teams who've been forced to choose between privacy and simplicity - there's finally another option.

Because privacy shouldn't be a luxury only enterprises can afford. 

check out DeviceLab - where we built a zero-trust distributed device testing platform. We don't promise not to look at your data; we architecturally can't. Everything runs on your devices, connected peer-to-peer. Your tests, your data, your security.

*AI was used to help structure this post