How Lyft's VP of Engineering Built Bitdrift to Fix Mobile Observability at Scale
The Problem Nobody Wanted to Solve
When you’re running a ridesharing app with tens of millions of daily active users, observability isn’t just nice to have—it’s existential. If a customer can’t see their car, if the app freezes, if the map won’t load, they don’t sit around troubleshooting. They open Uber.
This is the problem Peter Morelli and his team faced at Lyft. But here’s the thing: the observability tools available at the time were built for data centers, not mobile devices. They assumed reliable networks, consistent power, and unlimited storage. None of those assumptions hold true when you’re dealing with millions of phones.
“A lot of the time your network isn’t good,” Peter explains. “You walk from inside to outside or into a tunnel and suddenly your network connection drops. We were seeing that data being dropped on the ground.”
For a company like Lyft, this wasn’t an academic problem. When you lose visibility into what’s happening on a customer’s device right at the moment they’re having a bad experience, you’ve lost the ability to fix it. And your competitor gains a customer.
Building the MVP: Local Storage Changes Everything
The first version of what would become Bitdrift started with a deceptively simple idea: what if you collected telemetry data on the device itself instead of trying to push it immediately to the cloud?
Simple, yes. Easy? Absolutely not.
“Sounds very simple,” Peter says. “It’s actually really hard to do.”
The constraints were brutal. You can’t just dump unlimited amounts of data onto a phone because you’ll run out of storage. You can’t do heavy processing because you have about 16 milliseconds before users start noticing lag and freezes. And you need to handle every possible network condition—from full bars to a tunnel with zero signal.
The solution required deep technical work in performance and memory safety. Peter’s team wrapped native libraries in Swift and Kotlin, making sure everything was asynchronous and non-blocking. They built network detection to understand when connectivity was actually available. And they created a system that could reliably store telemetry locally and upload it when conditions improved.
This wasn’t theoretical work. This was battle-tested on the Lyft app with tens of millions of concurrent users. And it had to work without degrading the user experience.
The Breakthrough: Dynamic, Runtime Control
After solving the local storage problem, Peter’s team made a discovery that would become the core of Bitdrift’s platform: most observability data is never actually looked at.
“90% of the data is never looked at,” Peter notes. “It’s only the bad conditions.”
This is the insight that separates Bitdrift from traditional observability tools. Why waste bandwidth, storage, and money ingesting and storing data you’ll never use?
The next evolution added edge processing. Instead of uploading megabytes of logs, the system could summarize and metricize data right on the device, sending back tiny counters instead. This unlocked the ability to create metrics on the fly based on what was actually happening.
But the real breakthrough was making all of this runtime configurable.
Most observability systems make decisions at compile time. You add a log line, you add a metric, and that’s locked in until you rebuild and redeploy. On the server side at Lyft, where they were doing 500-600 releases per day, this was manageable—just a few minutes of delay.
On mobile? A typical release cycle takes 10-15 days. You’ve got weekly trains, alphas, betas, app store review, and propagation time. By the time a customer reports a problem and you add a log line to investigate, weeks have passed.
“Observability has not become runtime for mobile,” Peter explains. “You can say I have this problem, get more information. I don’t even need to be more turned off. And that’s something that used to take you weeks or months and now you can do it in a few minutes.”
This combination—local storage, edge processing, and runtime control—became the foundation of everything Bitdrift built next.
Building the Team for Startup Chaos
When you’re spinning out from a larger company like Lyft to start a venture-backed startup, you’re not just changing companies. You’re changing the entire operating model.
Peter knew the team he needed wasn’t just smart engineers—they needed to be comfortable with ambiguity, chaos, and autonomy. They needed to be self-starters who could identify problems and solve them without someone micromanaging every decision.
“You’re looking for people who are self-starters who understand that not someone’s not going to be sitting there telling you exactly what to do every single second of the day,” Peter says.
He also made a deliberate choice to skew toward senior engineers. Remote work was part of the plan from day one, and without a central office, you can’t have junior engineers learning through osmosis from more experienced teammates. You need people who’ve already proven they can operate independently.
The team that came from Lyft brought something invaluable: they’d already solved these problems at scale. They understood the constraints. They knew what worked and what didn’t. And they had the context to make good decisions quickly.
Customer-Driven Product Development
Three years after spinning out of Lyft, Bitdrift has grown to serve very large customers. And that’s shaped how Peter thinks about building the roadmap.
“We’re very customer focused,” he says. “We try not to build point solutions for just one offshore work customer. What are the ways that we can extend our platform in a way that benefits lots of customers?”
This is a healthy constraint. It prevents you from building custom features that only one customer needs while ignoring problems that affect many. It keeps the product focused and the complexity manageable.
Early on, they were their own customer—the problems they were solving were the problems they lived with every day at Lyft. Now, with a growing customer base, they listen carefully to what’s being asked for and prioritize based on what unlocks value for many customers, not just one.
The Lesson: Start With a Real Problem
Here’s what stands out about Bitdrift’s origin story: it didn’t start with a product idea or a market opportunity. It started with a genuine, painful problem that Peter and his team faced every single day at Lyft.
They tried existing solutions. They didn’t work. So they built their own. And after six or seven years of refinement inside Lyft, when they spun out, they had a mature, battle-tested product that solved a problem the market desperately needed solved.
That’s the kind of foundation that turns a startup into a real company.
Want to hear the full story? Listen to Peter Morelli’s complete conversation on Code Story as he dives deeper into the technical decisions, the scaling challenges, and what it takes to build a platform that works at the edge. You’ll get insights into building remote teams, navigating the shift from a large company to a startup, and how to know when you’ve found something worth building a company around.