Matt Klein - cofounder of Bitdrift: meeting developers where they are and early days of AWS
Matt Klein joined EC2 in January 2010 when the team was 45 people. He explains why Amazon shipped a rocket ship of a business held together with band-aids and yelling on conference calls — and why he thinks Google and Microsoft simply moved too slowly to have built it.
Matt Klein was one of the early engineers on EC2, worked application-level infrastructure at Twitter and Lyft, and created Envoy — the open-source proxy that ended up running inside almost every major internet company. He's now the founder of Bitdrift, a mobile observability company that spun out of Lyft.
We go through what AWS actually looked like from the inside in its early, chaotic years, how Envoy became so widely adopted, and the messy realities of spinning a company out of Lyft with one customer and no product-market fit. He also makes a strong case for a specific philosophy — meet customers exactly where they are, even when it means building the boring feature you didn't want to build.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What was it actually like inside AWS in the early days?
I joined in January 2010, when there were maybe 45 or 50 people working on EC2, and 200 to 250 across all of AWS, including S3. Before that I'd worked at Microsoft, which was still shipping CD-ROMs — a very rigorous process, because you can't push a hotfix to a disc that's already in a store. AWS was my first real exposure to the modern way of building internet software, and honestly it was shocking how quickly things moved and how customer-focused it was. I remember conference calls where people were literally yelling because they couldn't find the racks in the loading dock and didn't have enough capacity. It taught me that rigor and quality matter, but you also have to move fast and deal with the reality of actually growing a business — and scaling is not always pretty.
Was customer focus the biggest factor in AWS succeeding?
I think so. Amazon had this deep sense that the customer is always right, probably rooted in its retail background. Building anything is a balancing act between your own vision and what the market actually wants — you want to lead customers toward where you think they should go, but if you get too far ahead of them, it doesn't end well. Amazon has done genuinely innovative things, but it hasn't gotten too far ahead of what people actually wanted. Compare that to Meta burning tens of billions on the metaverse — literally no one wants that. Amazon has always been notorious about figuring out fast whether something is going to work, and pulling the plug if it isn't.
Why do you think Amazon won cloud computing instead of Google or Microsoft?
I wasn't there for the founding conversations — I think it started around 2006-2007 — but by the late 90s and early 2000s, tons of companies coming out of the dot-com bust were all repeating the same infrastructure work just to get a website online. Amazon saw an opportunity to sell that common infrastructure, and they were uniquely positioned to capture it because Google and Microsoft were simply too slow. Google's engineering culture is full of some of the smartest people in the world, but they're a very deliberative bunch. I don't think Google, and especially not Microsoft at that time, could have shipped something fast enough at an 'okay but not awesome' quality bar. Amazon just shipped it — it was rough in the beginning, cobbled together, and they built the sophisticated engineering to support that scale over time.
How did Envoy end up becoming so widely used?
By the 2010s, way more companies were building large distributed systems, and those systems had become much more dynamic — compute resources constantly coming and going, failures happening all the time, with things like Kubernetes moving infrastructure around constantly. A lot of the networking software that came before wasn't built to handle that. Envoy was built from the ground up to treat that constant change as the reality of how computing works, so it fit a need a lot of companies had. But it wasn't only technical — I spent an enormous amount of effort recruiting users and maintainers, giving talks at companies and conferences, building the community around it on GitHub. Starting a very successful open-source project and starting a business aren't that different: there's a marketing component, a hiring component, and most of the same concerns you'd have running a company.
What was it like spinning Bitdrift out of Lyft?
I would not do a spin-out again if I could avoid it — it's a complicated process. During the pandemic boom, it wasn't uncommon for groups inside bigger companies to try 'fake startups', and my honest opinion is that almost never works, because you can't replicate startup culture and incentives inside a larger company. We'd developed real intellectual property while at Lyft, so the question became whether to leave and start from scratch, losing Lyft as a customer, or work with Lyft to spin out with the IP intact. We left on good terms, with Lyft as both a customer and an investor. But having one big customer isn't product-market fit — we spent the first six months just launching publicly, since we didn't even have a public website when we left, and then a year and a half to two years genuinely iterating on the product like any other startup.
What gap in mobile observability is Bitdrift actually solving?
Most observability tooling is server-side — companies obsess over their four-nines server uptime while their mobile app just doesn't work: it hangs, it doesn't load, and when you tell them, they say 'we're not seeing any issues.' Most mobile developers have never had real observability — all they have is crash reporting, tools like Crashlytics, Bugsnag, or Sentry. But something like 99.995% of sessions are crash-free, so crash reporting only covers a tiny fraction of what's actually frustrating users, like an app hanging or freezing. We realized about halfway through building Bitdrift that customers know crash reporting, and asking them to adopt a new tool that doesn't include it — while they still need a separate crash reporting vendor — is a very tough sell. So we added crash reporting to Bitdrift, purely to meet customers where they already are, and that's what's let us start signing much larger deals.
What's technically different about how Bitdrift approaches this?
Most observability tools send all their data to a backend for processing, which is a huge amount of data and overhead when you're dealing with tens or hundreds of millions of phones. We store the data locally on the device instead, and — drawing on what I learned building Envoy's control plane for dynamic infrastructure — we treat phones the same way: we can tell them in real time what to do. So we can say, if you're in San Francisco on this app version and you see this specific condition, dump the full trace. Companies don't have to ingest all their data, just the pieces they actually need to debug something. But that alone wouldn't have been enough — people would still say 'great, but I still need crash reporting' and not want another vendor. Nobody wants more tools; if you can show them a path to fewer tools, that's a real win, even if you can't fully replace their existing vendor on day one.
What's your advice for other founders in developer tooling?
First: make sure you enjoy pain, because starting a company is not for the faint of heart — you see the overnight success stories on LinkedIn, but very few of them are actually true. Beyond that, be relentlessly customer focused. When we built Envoy, my answer to a feature request was always 'yes, but' — figuring out how to fit what someone's asking for into the larger product vision, rather than deciding they're wrong or don't understand. If someone doesn't understand, I take the view that it's our fault, not theirs — the product has to be clearer. That only works if you're building something people actually want in the first place, but assuming you are, the day-to-day work is just hammering away at what people are asking for and why, and figuring out how to make it happen.