Mobile apps live in a fundamentally different world than the datacenters most observability tools were designed for. Unreliable networks, devices that can crash or be killed by the OS at any moment, and release cycles that stretch into weeks rather than minutes all conspire to leave engineering teams flying blind—especially at the exact moments when customers are having their worst experiences. For Peter Morelli, CEO and Co-Founder of bitdrift, this isn’t a theoretical problem. It’s one he lived through firsthand while working on Lyft’s mobile app, where a single bad ride-hailing experience could send a customer straight to a competitor, never to return.
In this Q&A, Morelli discusses how those hard-won lessons from Lyft shaped bitdrift’s approach to mobile observability, why bolted-on “mobile solutions” from traditional, datacenter-first observability vendors fall short, and how bitdrift is positioning itself at the intersection of mobile engineering and the rapidly growing world of AI agents. With agents already generating roughly half of bitdrift’s platform usage, Morelli makes the case that mobile observability isn’t just evolving for human engineers anymore—it’s being rebuilt for a future where agents are the first line of defense against customer-facing bugs.
++
VMblog: How is mobile observability different from traditional observability tools?
Peter Morelli: Most observability tools are built with datacenters in mind. They assume you have a lot of a lot of things: a good, reliable network connection with a lot of bandwidth, a lot of cpu and storage, and that your app is constantly running. With mobile or edge devices, none of that is true; in fact, it’s usually the opposite in every way: unreliable networks that drop data randomly, an app that can crash or be shut down by the OS at any time, or simply a user just not using your app for a week.
You also have a different scale of devices recording and reporting telemetry. A large scale app in a datacenter is a couple hundred thousand servers or VMs. For mobile, that can be tens or hundreds of millions of devices. Most modern systems can’t handle that, and tell you to sample aggressively (1% or less).
Lastly, most observability is added or changed at compile time. That is fine if your deployments take minutes or hours; but on mobile, it takes 10+ days to get a mobile release out, deployed, approved, and then propagated to customer devices.
Most vendors still follow the traditional, old-school patterns of observability, which given the above, lead to a very poor view of your customers’ actual experience. Fixing this requires a radically different approach to observability, which is what bitdrift is.
VMblog: How did your experience at Lyft influence how you think about mobile observability and how you build bitdrift?
Morelli: With Lyft, 99% of its customer interactions are through the mobile app. If you have a bad experience when using the Lyft app, you leave and go to Uber and maybe never come back. So understanding the customer experience in detail and in real time was existential, and the existing solutions just didn’t work.
What we found is that when our customers were having the worst experiences on our app, that’s when we lost visibility. This was either because the data was never getting to us due to network issues, or the cost and scale considerations led to sampling, both of which caused us to miss many problems our customers were having. We found over and over again that we were fixing the wrong problems, to the detriment of our business.
bitdrift was built to be able to collect large amounts of data on mobile devices, unsampled, without affecting the customer experience. It stores data safely when it can’t be uploaded right away, surviving crashes and restarts. And it’s configurable in real time, without waiting for an app release. For the first time, you can investigate and fix all of the issues your customers have, not just a narrow slice of them. It was custom built for mobile.
VMblog: There are major players that claim to do mobile observability in addition to their cloud observability offering, all in one place. Why do enterprises need a dedicated mobile observability solution?
Morelli: Because they don’t work. We tried them all at Lyft ;o)
Most vendors were built with a datacenter in mind, and their mobile “solution” looks almost identical. They treat it as a checkbox, not a different problem space that requires a different approach. As mentioned above, this leads to engineers getting a tiny sample of only the good conditions, usually for a very high price.
bitdrift is custom built for mobile and edge devices, giving you a 100% view, in real time, of all customer devices. If you truly care about customer reliability and experience in your app, it’s the only solution that can provide that, regardless of the marketing from other vendors. It’s the right tool for the job.
bitdrift integrates cleanly and easily with existing solutions, both commercial and custom, through open standards, an extensive API, and AI skills, so it fits cleanly alongside existing observability solutions, while increasing engineering and product teams’ ability to improve the customer experience by a couple orders of magnitude.
VMblog: bitdrift AI claims to be the first mobile observability solution built for agents. Can you explain how it works and how engineers and agents alike can use bitdrift?
Morelli: We’ve built the bitdrift platform in a very layered fashion. You can use it at the API layer, which sits at the base of our platform. Every new improvement is exposed there first, and then we layer on tools on top to make it easier to use, including both our CLI and Web UX. On top of that, we expose a set of AI skills that teach agents how to use our platform. As a user or an agent, you can hook into whatever layer makes sense for your use cases, and most customers will use them in combination.
The bitdrift platform handles the scaling and unsampled telemetry collection across millions of devices, and unlike other observability solutions, allows you to modify that at run time, without having to do another weeks-long deploy process for every change. That speed and flexibility is what really sets us apart, allowing agents to investigate really hard problems. You can ask agents to investigate high level problems like, “why has my onboarding funnel suddenly dropped off” or needle in a haystack issues like the CEO’s weird bug that only happens 1 in a million times.
Those require agents (and humans!) to break those issues down into investigative steps, usually with several iterative steps where you need to go and find new information, digest it and then dig a level deeper. If you had to wait weeks between each step, and have a very tiny slice of data to work with, you just couldn’t do it.
We’ve built a lot of the traditional observability functionality on top of this platform, like charts, dashboards, alerting, and reliability metrics, but have gone way beyond that. You can track every single step every customer takes through your app, even at millions of devices through our user journeys. Watch what customers do through every screen on the app, or narrow your investigations down to specific cohorts of users for customer support or product analytics use cases. It’s an incredibly powerful tool, and the AI layer we’ve just released makes it even easier and faster to use.
VMblog: It seems like the use of agents will only continue to increase exponentially. Is bitdrift thinking about putting more engineering resources into bitdrift AI? Perhaps even more than towards the bitdrift platform built for human consumption?
Morelli: We’ve already started to see this happen. About 50% of the usage of bitdrift’s platform now comes from agents and our API, and the adoption is only increasing. We definitely think of agents as a separate and distinct user of our platform, with their own unique use cases and usage patterns.
Agents will also branch out beyond just assisting humans, to being the first line responders for issues a comprehensive observability solution can surface. We’ve already seen customers have agents triage, investigate, and propose fixes before a human takes a look.
This has enabled the forward looking teams to really scale. Not just in terms of speed, but the number of customer issues they’re able to solve. Typically, teams would have to prioritize the top 10-20% of issues, given scarce engineer resources. We have customers solving 90%+ of the issues they’re seeing with bitdrift.ai and their agents.
##
