I believe in general that the customer is always right, and I am biased almost always to say yes. But we're gonna find a way so that it fits within the larger product vision. I take the view that if they don't understand, it's our fault that they don't understand, not their fault. Right? So it's like our product has to be better to make them figure out the better way.

I'm joined today by Matt from BitDrift, a mobile observability startup. Matt talks about what it was like to be one of the early people at AWS and EC two specifically, and Matt shares about working at Lyft and Twitter and launching an incredibly popular open source tool at Lyft. We talk about BitDrift and how they spun out of Lyft, what that was like, And we talk about the importance of meeting people where they're at, shipping fast, and just being very customer focused. Enjoy the episode. I know you were, like, one of the key people on EC two for a while and pretty early.

What what was it like at AWS when when you were there?

Yeah. You know, it's it's hard to describe to to people because I think when people look at AWS today, you know, they see a business where, know, I don't actually know what the revenue numbers are. You know, they're in the tens or hundreds of billions now. And and they probably have I don't even know. They have, you know, tens of thousands of employees that just work within AWS.

And when I joined, this is in January 2010, there were, I think, 45 or 50 people working in e c two and then probably 200 or two fifty in all of all of AWS. So that included s three and all of those things. And for me, all I can say is it was a very formative experience. I had from prior to AWS, I had worked at a couple of small companies. But out of college, I worked at Microsoft.

And when I started working at Microsoft, this is in 2003, you know, this is back when there was very segmented engineering. Like, you were an engineer. You were a tester. You were a product manager. You know?

I mean, no one does engineering that way anymore. Like, roles are a lot more split. But I I came from a company that was born in the seventies and eighties and nineties, and things were done a certain way. And the company was used to, you know, shipping CD ROMs. I'm sure people that are listening don't even know what that is, but, you know, I mean, it's you know, people used to have a box of software that you would go and buy in a store.

Like, I'm again, I'm sure people don't.

My my cousin used to copy them and send.

Right. But, I mean, when you when you think about what it took to ship something that went into a store, you can't just fix it. Like, today, if something is broken, you go, oops. I I guess we'll fix it and put out a hot fix or something like that. Like, there's no hot fix when you're putting out a CD.

So it was a very rigorous process. And when I joined AWS or Amazon in general, it was my first real experience with, like, the modern way of doing Internet software, you know, where everything is chaos and everything is changing all the time. And I'll be honest, it was shocking to me. I mean, it was shocking to me how quickly things moved and really just how customer focused they were. I mean, obviously, it was a rocket ship.

The growth was growing at an exponential rate, but things were breaking all the time. And, you know, things that maybe based on the relatively little career experience that I had had so far, I would have said, oh, you know, this has to have a very rigorous process so we can get this right. That's not the way that it that it worked. I mean, I I can recall many instances of, you know, being on conference calls, and they would literally be trying to get the racks wired, you know, with people yelling on the phone because there isn't enough capacity where are the racks. Go find the racks and the loading docks and all of those things.

And some many crazy stories of just trying to make this thing work and cutting corners and putting Band Aids on. And, I mean, obviously, it's one of the most successful, if not most successful businesses of all time. So I think, again, I think it was a very formative experience for me because it taught me that while it's obviously important to, you know, have a lot of rigor and have a lot of quality, you also have to move fast. And you have to deal with the reality of growing a business, and sometimes it's not it's not pretty.

Scaling DevTools is sponsored by WorkOS. If things start going well, some of your customers are gonna start asking for enterprise features. Things like SSO, SCIM provisioning, role based access control. These things are hard to build and you could get stuck spending all your time doing that instead of actually making a great dev tool. That's why WorkOS exists.

They help you with all of those enterprise features and they're trusted by OpenAI, Vercel, and Perplexity. Here's what Kyle from Depot has to say about WorkOS.

We use WorkOS to effectively add all of the SSO and SCIM to Depot. So for us, we can effectively offer SSO and SCIM, and it's like two clicks of a button, and we don't ever have to think about it. It's like one of the best features that we can add to Depot, and it's super affordable, which effectively allows us to, like, break the SSO tax joke and essentially say, like, you can have SSO and SCIM as, like, an add on onto your monthly plan. So it really allows smaller startups to essentially offer, like, that enterprise feature without a huge engineering investment behind it. Like, it's literally we can just use a tool behind the scenes, and our life is exponentially easier.

Thanks again, Worker West. Back to the episode. Is it the customer focus that was the biggest?

I think it's the customer focus. I think I think Amazon in general again, I, you know, I I can't say as much now. But at least at the time that I was there, I just really appreciated this general sense, you know, that the customer is always right. And that's something you know, obviously, it probably comes from the retail background, but I think that has permeated most most of what they do. And I think, you know, when you start a company or build something or do anything, it's always this balancing act of having your own vision of of what it should be and what it should do.

But you're always balancing what you think and what what the market actually wants. And I'm a big believer that, you know, you wanna lead the customers to the promised land where you want them to go. But if you lead them too far ahead, it's probably not gonna end well. So I I I think Amazon, at least historically, has just done a great job of doing really innovative things. Like, no one can argue that they haven't been an incredibly innovative company, but they've also built things that people want, and they haven't gotten too far ahead of that.

Yeah. And it was it like, I because for me, it just like because I've been researching a little bit about AWS. It's just kinda crazy how much they just changed how people worked and how things were built.

Yeah. I mean, I think the I think a great example of that that comes to mind is if you look at Facebook, Meta, you know, I don't know. They've burned tens of billions of dollars on, you know, this metaverse stuff that, like, literally no one wants. Not not a single person wants that. Right?

So you could you could argue that, you know, they have a vision, and they believe that that's where things are going, and this is the future of work and all of those things. But I think just that's a great example of what I'm talking about, which is it doesn't seem like either that vision is too far ahead of where people are at or the vision is wrong. But I don't think Amazon like, Amazon as a company would never do that. I mean, they I I just like, I don't see them investing that amount of money in something like that without a bit of a higher confidence, you know, that it would be well received, or they would fail faster. Right?

It's like, I think Amazon has always been very notorious about just figuring out if something is gonna work and then pulling the plug if it's not.

Yeah. My my understanding on it of it is that they were and correct me on this, but it's like it seemed like it was just the thing that people were struggling with the most was like knowing like the capital expense they had to put down to like even go online, so to speak, or like to expand. And it was like just all these other retailers and stuff were asking them, and everyone was struggling with it. But it just seemed like impossible, like, I I don't know, like

I think I think there are a lot of folk stories that have gone around, you know, that AWS was born out of they had extra capacity that they weren't using during Christmas or something like that. And to my knowledge, that's not true. I mean, I I think they just some group of them decided, and this is prior to my time. Obviously, I didn't join until 2010. So I think everything started in, like, the 2006, 2007 time frame.

So in in the grand scheme of time, I was there very early. But, you know, in, like, startup startup time, it was still, like, a little bit later. But for the people that started in 2006 and 2007, I think they just saw a need, and they said, let's see if this can happen. And I think you're right. I mean, I I think that in the late nineties and early two thousands, there was a lot of companies that were all repeating a lot of the same infrastructure work to to get their stuff online.

And, obviously, this is coming out of the .com bubble bursting in the late nineties and early two thousands, and now there's a lot more companies online. And they're all, you know, putting servers somewhere to have a web page or something like that. And there was, you know, during that time, obviously, there was the early social media companies like Facebook, and then you have Twitter and, you know, and other other people in that in that time frame. And they're all solving, like, similar technical concerns around, you gotta put servers here and do this and do that. And I think the Amazon folks again, I wasn't there for those conversations, but I think they said there's gotta be an opportunity here to, you know, sell some of this common infrastructure.

And, obviously, they were right. I mean, they they they have built an incredible business. And I think what's interesting is that as you go forward, you know, the the business has just been astounding. They've captured so much value. But it's interesting to see how things have evolved over the last, like, fifteen years because now it's not just them.

I mean, you have Oracle that has a huge business, Google, Microsoft. I mean, there's all these other providers. And now as a lot of the other technology has has matured, there's other people that are now saying, oh, you know, cloud's too expensive because they're charging their high markups and margins, and now we're gonna move the infrastructure back. So, you know, I mean, I think it's I think it's just a great example of being in the the right place at the right time, seeing the opportunity, and executing really well. And I think that's that's kinda what I was talking to about the craziness of that time because I think that Amazon was uniquely positioned to capture that value because Google, Microsoft, simply too slow.

I mean, it's like Google's engineering culture, as much as I've worked a lot with Google over the years, Some of the smartest people in the world work at Google. They're a very deliberative bunch. Right? And I don't think Google, and especially not Microsoft in that time frame, could have ever done something fast enough and at a okay enough, but not awesome quality bar and get something out because they would have always been saying, oh, this is good enough. We gotta do this, do that.

Amazon just said, we're just gonna ship it. I mean, we're just gonna put it out there, and it was rough in the beginning. And, again, over time, they've done some incredibly innovative engineering to to, like, build to that scale. But in the beginning, it was a bunch of cobbled together stuff.

Yeah. Wasn't it also like that? And and sorry. This has been my last AWS question. But like, wasn't it also that kind of like they focused on like externalizing, like everything had to be like its own concern and like, they already have that culture, AWS?

Emma yeah. Like, I I think what you're talking about is the is the everything is an API type type of thing or, like, everything is its own service. And I think they were doing that internally at a very early time. So I think that that permeated it, but I I don't I think by the time that they launched AWS, it was pretty well established. Like, that was more of a late nineties type of argument.

I think by the time that AWS was launched, you know, the fact that everything is an API or service or those kinds of things, I think that was getting on its way to be more established. I think it's more that they just saw the opportunity that these are the building blocks. Like, people need some storage Yeah. Or they need to rent some servers, or do these things, and no one most people don't wanna fuss with figuring out how to put them into data centers and all of those things. So I I I really think it's just some smart people saw the opportunity, and they were in the right place at the right time, and they executed very well.

Okay. That's amazing. That's that's that's really cool. Thanks for sharing that. Okay.

So then you you've been you were talking about, like, the social media companies. Like, you were at Twitter and you were at Lyft as at this kind of, like, building on top of, I I guess, the cloud services and just how how insane, like, the growth of the Internet was. And you launched, Envoy, an open source project at Lyft that became incredibly popular. Could you tell us a bit about that?

Yeah. So without getting too far into the weeds of the technical stuff, you know, when I when I worked in EC two so I've spent most of my career working on really low level technical things, like operating systems and computer virtualization and networking and all of that. And when I worked in Amazon, I worked more on, like, the low level operating system networking type stuff. And then I left Amazon, and I went to Twitter. And at Twitter, that was my first exposure to, like, application level computing.

So, again, for, you know, those of your listeners that that don't know just very quickly, all of the big services that you use, like, whether it be Twitter or Facebook or Google or whatever. You know? It's not just one computer. There's, like, thousands or sometimes millions of computers that are out there, you know, making your search queries or showing you your social media feed or whatever else. And those computers have to talk to each other, and it's a pretty complicated problem to do that reliably.

So when I was at Twitter, I I spent a bunch of time working on, you know, Twitter's edge system, so how Twitter would talk to the Internet and how people would talk to Twitter. There are some fantastic stories from that time. A very quick one, which is well known, is that I wrote some code, and it logged 40,000,000 people out of Twitter. So that was a that was a that was a very exciting time because, obviously, for these social media companies, when people get logged out, people are not happy. And, you know, because you can't you can't serve them ads and all of that good stuff.

But, yeah. So that was a that was a great experience, just learning, like, how these big big systems are built. And then from Twitter, went to Lyft, the ride sharing company, and that was also fairly early in Lyft's history. I think at the time that I joined Lyft, there's probably 50 or 60 engineers. The whole company was probably, like, two or 300 people.

And this was in 2015, and, obviously, this was really during the height of the gig company era. You know? There's obviously Lyft and Uber and DoorDash and Instacart and all of these companies. And during this time, you know, there like, there's a lot of people that are building all of these complex systems. So I think, you know, AWS and those types of things started in, you know, the mid two thousands, and that's when it became easier for people to get servers and start building systems.

But then by the mid two thousand tens, tons of people are building these really complicated systems that do all these things on your phone, and they're all facing a lot of these common problems. Like, how do these servers talk to each other, and how does it all work together? Like, how do you give people a customer experience that's actually good? And as part of that, I I developed a piece of open source software to help Lyft, and that was in the computer networking application networking space. And we open sourced that software because it wasn't really Lyft's main business interest, and we open sourced that in 2016.

And much to my amazement, still to this day, it became very, very popular. I mean, like, popular to the extent that, you know I don't even know anymore, but, I mean, I I think in some form, probably almost every human on Earth that uses a computer probably interfaces with Envoy in in some form, you know, and it's used by almost every major company around the world. So the ability to to help create something like that that has impacted so many people around the world, I mean, it's, frankly, it's it's hard to imagine ever topping that from a career perspective. And it was shocking to me, you know, that the software would would become so popular. So I spent a lot of time at a lot of my time at Lyft, obviously, working on that and helping Lyft with their software needs and working with the industry, you know, to to to see that software adopted.

Why do you think it was such a popular piece of software?

You know, this will this will get into a bit of technical detail, but I'll try to keep it simple, which is that, as I mentioned before, you know, there there's been some industry shifts during times sorry, during different periods of you know, as we go back. Right? So it's like, obviously, you know, the the Internet really came about during the nineteen nineties, and that's when people first started building these large distributed systems that would serve things like Google. And then, obviously, cloud computing came along in the, you know, the early two thousands. And then as I mentioned, in the February, people started building way more of these systems, just more systems.

You think about how many companies started during that time that are now really popular. You know, there's too many companies to count. Like, how many apps do you have on your phone? Like, many of those apps were created during the February. So so many people were building these systems, and one of the technical components of these systems is they tend to be very dynamic.

And by dynamic, I mean that things are always failing. Like, you know, the computing resources are coming and going and, like, failures are always happening. And the big difference in the February versus what came before is that most computing systems, they were a lot more fixed, if that makes sense. And by fixed, I mean, you know, you had some machines that are in a data center somewhere. Those machines had some names.

You, like, set up some rules, you know, and that was what you did during that time. In the February, you started having open source projects like Kubernetes and just, like, general infrastructure that just moved around a lot. Like, things would change all the time. And a lot of the networking software that came before wasn't really built to handle a lot of that change. So Envoy was built from the ground up to really, you know, take that change as just the reality of way computing systems work.

And because of that, it really fit a need that a lot of companies were facing where these other systems, some great open source pieces of software that had come before. They weren't really they weren't really adaptable to this new world. During that time as well, you know, it's not just the fact that we built the software in this really adaptable way. But as you probably know, obviously, people started developing software on GitHub during that time. And I think with a lot of open source software, you know, the way that you build the larger community, the way that you bring people in, that's also a huge part of of whether software and and all of the stuff that happens around it becomes very popular.

So unlike a lot of other systems during the time, like, we developed Envoy on GitHub. I spent an incredible amount of effort recruiting users and other maintainers and, you know, going and giving talks at companies and conferences and all of those things. And, you know, I've said it many times, but I think that, you know, starting a very successful open source project and starting a business, they're not that different in the sense that, you know, it's not just technical. It's like you have all these concerns. You know?

There's, like, a marketing component. You gotta tell people about it. There's obviously a there's a hiring component. You gotta find maintainers and people to work on it. I mean, there's there's most of the same things.

Having started a business now, I'll say that that statement's probably a little naive, but but there there are a lot of commonalities for sure.

Yeah. Yeah. And maybe that's a good segue onto onto starting a business.

Yeah. I was gonna say that where where I I think that statement, while it's true, I think what I didn't really understand is that open source software is still free. And when you try to get money from people, the the the bar goes up even higher. Right? So yeah.

You know, I I think we we obviously developed a lot of technology while we were at Lyft. And as I got later in my Lyft time, I think one of the things that we started to realize is there's a whole area of computing, which is now called observability. Observability is basically the the the practice of how do you know what your software is doing. Right? You're building these, like, giant systems, and they're doing all these things.

Like, how do you know that your widget is actually producing widgets? And observability, as, you know, some of your listeners probably know, has become one of the biggest spending line items that most people spend on their computing infrastructure. Infrastructure. It is a very big business. I mean, companies that your listeners would have heard of, like Datadog and Splunk and all these things.

Yeah. It's not the

legendary $50,000,000 customer line item or something.

Right. You know? And I I think for a long time, observability was probably the number two line item behind cloud infrastructure that most companies would spend on. Today, it's probably number three behind, like, cloud and AI, you know, but then it's probably observability. So, like, observability has always been a big problem, you know, when it when it comes to figuring out whether these things are working.

But one of the frustrations that I've always had and something that I've always been involved in is that the vast majority of observability tools, they're focused on what I would call server side observability. So we've been talking a lot about, you know, you have these computers that are in a data center and all of those things, and you wanna know what those things are doing. But as you know, really, the way that 90 of people interact with computers now is through their phone. Right? It's like they're on their phone.

They're in their apps. And a lot of times, as you and your listeners know, the apps don't really work. Right? You know? And and one of my biggest personal frustrations has been that people love to talk about the reliability of their systems.

By systems, I mean their server infrastructure. They talk about their I got whatever, my four nines, my 99.99% reliability. But then, like, the phone is just breaking. I mean, it's like how many times have you been I mean, just like a personal pet peeve of mine. How many times have you been on a banking app or an airline app, and like, it just does not work?

Like, it doesn't load, it hangs. I mean, it's it's like really bad, right?

Yeah. And then and then sometimes you tell them, and they're like, oh, we're not seeing any issues. It's Wait. Like

I I didn't tell what. It's it's so frustrating to me as an end user, you know, that we've put all this effort into the server stuff, but people still don't have a great idea of what's going on on the phone, like, where people actually care. So while I was at Lyft, we started working on some internal systems to help really understand the reliability of what's going on and the observability of what's going on on the phone. And then we're a bit of an odd situation. We actually spun out of Lyft into an independent company called BitDrift, and that was in 2013.

So, you know, we had developed some of the technology while we were at Lyft, and then we decided that, you know, the only way to to really have a go and see if this is a viable company is is to do a spinout. So not the common way that people do startups. You know, we spun out with Lyft as a customer. They're also an investor. And we've been doing Bitrift, which is a mobile durability company for the last two and a half years or so.

That's really cool. Could I actually ask, like, how what was it like? Like, did you how how did that come about? Was it like just

Yeah. You know, I'll say, in all honesty, I would not do a spinout. It is a it is a it is complicated process. I think how it came about for us is, you know, I think during the early two thousand twenties and probably late two thousand tens, but especially during the during the pandemic time when, you know, tech valuations were booming and the economy was booming and all of these things, I think it wasn't uncommon, you know, that at a lot of these larger companies, there were groups of people, I'll call them doing fake startups. And by fake startups, I mean, you hear lots of stories like this.

Right? You know, there's some people that are building some stuff, and maybe they're, you know, they're gonna go and try to sell it and, like, do, like, a like a startup within a larger company. And my personal opinion, to be honest with you, is that this pretty much never works because you can't do a startup within a bigger company. It's just it's not the right culture. It's not the right incentives.

You know? It's like it it it it it's just not. And not to mention the fact that when you're trying to sell to initial customers, a lot of them are looking at you really confused and saying, sorry, like, you work at Lyft, and you're trying to sell me, you know, mobile observability software, and I get it. That doesn't really make sense. Right?

Yeah. So on on so many angles, I think we just realized that we think this idea has legs. We think there's a knee within the market. We don't we don't know. But, you know, let's see what we can do.

And then it comes down to the question of we've developed significant intellectual property while we're at Lyft. So then the question is, do we try to do do we just leave and then have to start from scratch and lose Lyft as a customer? Or do we work with Lyft and see if we can take the IP and do a spin out on all of those things? And, you know, I'll be honest. There's strong pros and cons for for both sides.

And if I had to do it again, I'd probably do the same thing, but it's it's not super cut and dry. And I think that mostly, we just said that we need to be an independent company in order to do this for real. So we have to explore how to make that happen. And it was a pretty lengthy process, not not the most pleasant one, but I don't don't think anything involving a lot of lawyers can be. And I I, you know, I think we we made it happen, and we left Lyft on good terms and all of those things, and that was fantastic.

So I think that when we left Lyft, what was interesting, I think most startups, you know, they start with no customers. And they're they're desperately trying to find initial customers and find product market fit. And I think what's interesting about our company is that we left with a big customer, but one customer is not product market fit. So you're so you're you're you're kinda like in this weird situation where you have a big customer, but one customer having worked there and done all those things is not product market fit. So, you know, we spent the first six months of the company just launching publicly because, obviously, we didn't have, like, a public website website when we left.

So you had to do do all those things, do public launching and all of that. And then, you know, the last year and a half to to two years has been obviously iterating on the product like any other startup would and figure out, you know, does this thing have product market fit? And it's been a journey for sure. You know? I mean, it's like, I think anyone that tells you that starting a company is easy is absolutely lying to you, because it is a it is a difficult journey for sure.

Yeah. Actually, like, curious. What what was it? Like, how do you kinda go from, like, I guess something that you know has got well, I don't know what the right word is, but like, you've got some sort of product fit with product lift fit, where, like Right. You've built something that they love or or that you loved, I guess, when you were there as well.

And, like, how how different is it to, like, get that to a point where other people

I mean, it's it's frankly, it's super it's super different. I mean, part of it is Lyft, at the time that we left Lyft, Lyft was is a very sophisticated company. Right? And by sophisticated, I I mean, it had over the years a lot of great engineers that built a lot of great technologies. Like, its mobile app wasn't is very good.

Right? I mean, it's like a lot of people had put a lot of effort in. They're a mobile first business. So so, like, Lyft, in some ways, is not the best customer for for, like, what we're trying to do, just in the sense that their app already is very good. Right?

So it's whereas like what you're trying to do is you're trying to help uplevel all the other apps, the ones that shall not be named, but maybe we alluded to before. Right? Where where the apps tons of people use them. They generate lots of revenue for these companies, but the app quality is is not that great. And I think that, you know, figuring out how do we reach developers and build a business where developers are.

Right? Meaning, it's like this actually comes back beginning of our conversation, where I can have a vision all day of how I, you know, want mobile's ability to be, and how I want app development to be, and all of those things. But if I'm too far ahead of the average developer, they're gonna look at me like I'm crazy, and they're gonna tell me to go away. Right? And I think what what what what we realized, a very concrete thing, is, you know, most mobile developers, partly because mobile observability, without getting into a lot of technical details unless you want, is very difficult.

Like, it's just hard, and it's hard because the phones have sporadic connectivity. They have low resources. The apps are, like, turning on, turning off all the time, or they're getting background or, like, whatever else. It's very complicated. Most mobile developers, they don't know observability.

They never had observability. All they have is crash reporting. Crashlytics. Yeah. Yeah.

It's like they they have Crashlytics. They have Bugsnag. They have Sentry. And those are great products, great tools. Right?

But all they tell you is, did the app crash? And what almost every company will tell you, every, you know, established company, is that crashes are they 99.995% of sessions, user sessions are crash free. So only point o 1% of sessions are crashing. Right? So that means and, yes, like, crashing is a problem.

Obviously, if you have a big crashing event, that's bad. But most of the problems that you and I are talking about, like the app hanging or like, you know, how many times do you rage quit some app because it's frozen or, you know, it just doesn't load or, like, it loads too slow and you get frustrated and leave. None of that's covered by crashes. Right? And for most apps, we would argue that spending your time on crashes is not actually the best use of time for your customers.

It's fixing all the other problems. But as a company for BitDrift, we realized probably halfway into the last two years that customers know crash reporting. And asking them to adopt this new tool when it doesn't have crash reporting and they still have to have a Crashlytics for all of those things, that's that's that's a pretty tough sell. Right? Because they're gonna say, well, I still need crash reporting, and that's true.

I mean, it's like if you have a bad crashing event, that's bad. So we ended up adding crash reporting to BitDrift, and that's because we need to meet customers where they are, and then we need to lead them to this promised place. And, you know, knock on table, I feel very optimistic about where the company is going at this point. You know, we're on the verge of, I am, I think, gonna sign some very big deals with some very large companies. And we never would have done those deals if we hadn't added crash reporting.

So that's just, like, a really great example of where I I really believe that, you know, you have to lead, but you can't lead too far. It's like, well, like, we have to build the products that people understand, and they want to use, and then we can take them further.

Yeah. Because then I see what else they get from Bitrix.

Yeah. Exactly. Come for that. Yeah. I mean, they might they might come for crash reporting, or some people might come for what in the industry we would call rum, like real user monitoring or, like, observability or those kinds of things.

You know? There might be a there might be a segment. There's typically a segment of the company that wants to look at performance traces and session replays and all of those things.

Mhmm.

And, you know, our our big innovation at Bittriff, like, where where we thought that we could provide the most value since we didn't really talk about that yet, is we take a pretty different approach. Most observability tools, they send all their data to some back end service, which which, you know, does the processing and shows you all those nice things. When you're dealing with 50 or hundreds of millions of phones, this is a very large amount of data. Like, not to mention the performance overhead that it has on the phone itself for taking more data that could be used for other things and processing power and all those all that. And what we do at at Bittriff, which is very different, is we store the data locally on the device, and then partly from the learnings that we had building Envoy of building this control plane, I I talked to you a bit about, like, dynamic infrastructure.

We treat these phones as kinda dynamic pieces, and in real time, we can tell the phones what to do. So, basically, we can say, you are in San Francisco on this app version, and if you see this, this, this, and this, dump all the data and get me a full trace and, like, do all of those things. And this is incredibly powerful, and it really appeals to large companies because now they don't have to ingest all their data. They can just ingest the pieces that they need to get their performance data, to debug certain things. So it's a very different way of doing things, but still, it's a different way of thinking.

It's a different way of capturing the data. And if we only had that, I don't think that we would be as far along as we are now, mostly because people would still come to us and say, that's fantastic, but I still need crash reporting. And, like, are you telling me that I still have to have this other vendor and I don't want multiple vendors? Right? I mean, it's like all the typical stories of how you purchase software.

So it it it's just it's the best example that I can give of where you can build amazing technology all day long, but if you're not meeting customers where they are, I I just think it's almost hopeless. And I think that even for what we're building, even if customers are not immediately gonna replace some of our competitors who are doing the crash reporting piece, if they can see a path to where in the future they could, and they can because as you know, I mean, people always they want less tools, not more. No one wants more tools. You know? So if they can see a path to having less tools, you know, that that's a positive for sure.

Yeah. This is it's I really like the way you put it about meeting people where they are. Because I I always even just like, I always like to put tools in boxes of like, okay, this is because it just helps you as well, I think, like, to just think about things and you and then you can think of like, extend the definition and stuff like that.

Yeah. I I think too. I mean, everyone in our industry for as as long as I can remember, especially in the observability space, but not just there. You know, they're always talking about the, quote, single pane of glass. Right?

It's like you're gonna go to you're gonna go to one tool. That's the one tool that's gonna rule them all. You know? And in that tool, you're gonna get, like, all the other stuff because people don't wanna click to different tabs and do all of those things. Yeah.

And, I mean, again, people have been talking about that for as long as I've been in the computing industry. It's it's long, long time. And, you know, I've come to realize that it's a it's a noble goal, but it's not necessarily realistic. But I think using that as a north star around, you know, can we help people maybe go from five tools to four? I think most people would say that that that is a great thing.

And I think especially in the mobile space, what we see is there's almost this this, like, Venn diagram of tools that started in different areas. Right? So there's, like, the error reporting crash reporting tools. That would be like a Crashlytics, Sentry Bugsnag, those those types of things. Then there's, you know, the tools that started more on, like, the RUM or observability side.

So that'd be, like, Datadog, RUM, New Relic, like, those those kinds of things. Then there are people on the analytics side, companies like Amplitude or Mixpanel. And over time, not surprisingly, a lot of these tools have you know, they've started to, like, morph into the same thing. Yeah. But you don't talk to any customer who's like, yeah.

I really like having an analytics tool, a RUM tool, and a crash reporting tool. Like, no one says that. So I think it's I think it's more what is the what is the path that we can get to a place where, as I mentioned before, we can really help people debug a lot of those usability issues that are at the core of most computing experiences today. But they still need those other Venn diagram pieces. So we do ultimately have to have a path, hopefully, like a a compelling story of how we can get to one tool.

Not not to mention all the other complexity of purchasing software where people might say, great. You do mobile, but do you do web since, you know, 10% of my traffic is on web, but then I have this whole other set of tools for that. So I think, again, it's I have I've really opened my eyes to the fact that, you know, amazing technology only gets you so far. There is a lot of realities of just selling software, you know, that have to be there before people will purchase.

Amazing. Amazing. So would your your big takeaways for other founders listening would be meet people where they're where they are? Feels like the theme or

I mean, I think my first thing would be make sure you enjoy pain if you're going to start a company. It's definitely not for the not for the faint of heart. And, you know, you you can you can see the overnight success stories on LinkedIn all day, but I think very few of them are actually true. And, you know, it is a it is a it it is a hard path. It is very rewarding, but it's a hard path.

And I think, you know, especially when we talk about, like I I can't talk about all startups, but I think in the developer tooling space, whether it be observability or any other tool, you know, that that we're talking about. And and we saw this when we did Envoy as well, just in terms of you can do all these things. And I I think one of the reasons that Envoy became so popular is I am also very customer focused, and maybe that came from Amazon. Maybe it's just in my own personality. I just I believe in general that the customer is always right, and I am biased almost always to say yes.

And when we did Envoy, you know, I would phrase it in a way of saying, yes, but. Right? I mean, like, the answer is always yes, but we're gonna find a way so that it fits within the larger product vision. Right? And and and I think that so many people can get stuck in saying that, no.

That's not right. This is not the way that it's supposed to work. Like, what, you know, he or she is asking is stupid or something like that. And I I take a very different view, which is that people are not gonna like, they're not asking. Like, they're they're asking because they want something.

Right? Like, it might be that they don't understand or maybe there's a better way or whatever, but I take the view that if they don't understand, it's our fault that they don't understand, not not their fault. Right? So it's like our product has to be better to make them figure out the better way. So that's a that's a long way of saying that I always take that approach of they're asking for a reason.

We have to figure out a way to help them, whether that be improving documentation, adding a feature, like making the feature more clear or something like that. And I I I just believe that over time, again, it's like you can you can be customer focused all day. And if you're building something that, like, absolutely no one wants, it's obviously not gonna work. But assuming that you have something that people generally want, and and at Bitriff or with Envoy, I think that is true, I think that a lot of the nuts and bolts the day to day is just hammering away And what are they asking? Why?

Let's figure out how to make that happen. And with so much software, you know, again, I'm not going to name names, but I think some of the customers that we're working with, I think they're just thrilled with the fact that we're responsive. We listen to them. Like, we're figuring out ways to help them and other companies. You know, okay.

Yeah. Hi. It's on the road map. Well, they don't talk to you in 2027 or something like that. And and I get it.

We're a small start up. We can be more nimble. But I think that Amazon is actually, at least historically, is an example of where I mean, they they do iterate on customer requests. Right? And they they have done it at a very large scale.

Again, maybe not as much as they used to. But I think for a giant mega corp, they maintain that culture for a very long time, which is which is fairly impressive to me.

Yeah. Yeah. That's this is this is amazing. And I really enjoyed hearing this, Matt. And I think you explained things really well, by the way.

No. Thank you. Thank you very much. Yep.

Where can people learn more about BitDrift and about you?

You know, in the old days, I would have said Twitter, but that doesn't really exist anymore. So, you know, it it it's a it's a totally separate conversation, but one of my I I miss the old Twitter. Like, I I actually miss having that space where people can just talk and have these conversations. And like, I thought that maybe it was gonna be blue sky, but it's not really. And and it seems like it's LinkedIn, I guess.

I don't know, which seems bizarre to me, but I I guess LinkedIn. Anyway, you know, you can you can would love to talk to you, you know, and you can shoot me an email. I actually have a I have a website, mattclan123.dev. There's bitriff.the website. I'm on blue sky, LinkedIn.

Obviously, would would love to talk to anyone.

Amazing. Yeah. Well, thank you so much, Matt, and thanks everyone for listening.

Yep. Thank you for having me.