bitdrift
PricingDocs
profile picture for Matt Klein
Matt Klein

bitdrift turns 2: a retrospective

Recently, bitdrift turned 2! It’s hard to believe that only 2 years have gone by. Startup years are odd; sometimes it feels like it’s been only 6 months. Other times it feels like it’s been 10 years! In this post I thought it would be interesting to talk about our journey so far and some of the things we have learned along the way.

bitdrift turns 2: a retrospective

A brief history

As startups go, bitdrift has a fairly unique origin story. The team that created Capture all worked together at Lyft for many years. Our time at Lyft constantly pushed the boundaries of what modern observability tooling could offer, both on server and on mobile. Towards the end of our tenure at Lyft, frustrated by the observability status quo, we began work on a concerted effort to advance the state of the art. On server, the team’s focus was always primarily around reducing overall costs. As I talked about extensively in my post on the observability cost crisis, as an industry we are producing more telemetry than ever, and only a tiny fraction of it is ever looked at by either human or machine. The team developed different methods of automating aggregation and complete disablement of telemetry sources that were never looked at. The Pulse metrics proxy is an offshoot of this effort. On mobile, effective observability is substantially less mature and in many ways substantially more difficult than on server. I talked about why at length in my post on why no one talks about mobile observability. This is doubly frustrating because if we aren’t measuring what end-users are experiencing directly in the app, what are we actually measuring? How many times does the server success rate read 99.99% but all the clients are crashing due to bad JSON? The team took a fresh look at what would make mobile observability amazing in the face of many, many challenges, and ultimately landed on real-time dynamic observability coupled with local storage. Via this effort, what is now Capture was born. By the end of 2022 it became clear that we had the kernel of an idea with legs, and the only way to see if the broader market agreed was to spin out of Lyft as an independent company. After quite a lot of work (spin outs are hard!) we were an independent company by mid-2023.

The initial hypothesis: cost is what matters

In 2023, general angst at overall observability spending was peaking. It was hard to talk to anyone about observability or go to any observability focused conference without the topic of conversation turning to the gigantic observability bills customers were facing and whether the ROI was commensurate with the size of the bill. The bitdrift Capture approach to observability is revolutionary: by coupling a real-time control plane with local storage, we are able to send 1000x the data when you need it and none when you don’t. Our original hypothesis was that with this novel approach, we could aggressively sell against cost reduction and customers would come flocking. And yet, they did not. We launched Capture publicly at the beginning of 2024. Almost immediately it became clear that the fundamental approach Capture takes (real-time control with local storage) was resonating with potential buyers, especially from very large enterprises where the cost and capability of existing mobile observability tooling was not meeting modern requirements. And yet it was still hard to get those interested over the adoption and purchase hump. As it turns out, for as much as everyone screams about observability costs, the truth is actually quite a bit more nuanced about how this plays out in the market. It turns out that almost universally, the users of observability tooling do not care one bit about cost! Users only care about cost when the people that do care about cost (engineering leadership and executives primarily) come complaining about cost to the users. Perhaps this is obvious, but I don’t think this split of concerns is discussed enough. Fundamentally, users want an awesome product that solves their problems first and foremost. A product is not going to get brought up for consideration to buyers (who do care about cost) until it passes the initial sniff test from those that will use it day to day.

The new hypothesis: cost matters, but is a secondary concern

With the realization from the previous section out of the way, we started doubling down on continuing to build what we still believe is an amazing mobile observability product that helps customers solve problems that they never thought could be solved via the use of dynamic real-time observability. 2024 was focused on adding a very long list of features that rounded out the Capture offering including: funnels, support for React Native, instant insights (out of the box fleet breakdowns), advanced charting including histograms and grouping, user journeys, alerting, tracing/spans, and much more. With each added feature we came much closer to being able to wholesale replace existing traditional mobile observability RUM tooling, but with the added twist of 1000x the data when you actually need it, which from a debugging and fleet visibility perspective is a gamechanging capability. As we have rounded out our overall feature set, and focused first and foremost on creating an exceptional product, sales conversations have progressively become easier. And when it comes to the final cost, especially for fully unsampled synthetic metrics, our platform always wins, which is extremely beneficial when it comes to getting final approval from the budgetary owner. In short, building an awesome product that wows users is priority number one for us. A product that doesn’t wow users isn’t going to get far enough along for anyone to care how much it costs. With that said, a product that wows users and has a substantially better cost profile than the competition has an obvious leg up! And while I’m certainly biased, I have high conviction that Capture is that product.

Crash/issue reporting: meeting customers where they are

While on our path to building an industry leading mobile observability/RUM solution, our next major learning has been that the great majority of mobile engineers and product owners have unfortunately come to accept that mobile observability tooling is bad. Either it costs too much, runs too slow, uses too much data, or is sampled too aggressively to be effective. For the vast majority of these engineers, tracking crashes/issues has been synonymous with mobile observability, because nothing better has been available. Our next major challenge in customer acquisition started to be less about the feature set and price point of our observability/RUM offering, but more fundamentally that Capture did not have built in crash and issue reporting, and users were, not surprisingly, hesitant to take on an additional tool when they would still have to purchase a traditional crash/issue reporting solution. By the end of 2024 it became clear that we would have to meet customers where they are and offer a holistic mobile observability offering that spans crash/issue reporting and adds all of our real-time dynamic observability goodness on top. Fast forward six months and we launched crash reporting. Crash reporting will ultimately allow us to fully replace any existing traditional crash reporting solution, a requirement for mobile engineering teams and something that every mobile engineer understands and uses often. We can then layer on top extremely powerful observability/RUM features that have the ability to uplevel engineering teams as a whole and ultimately allow those teams to provide vastly better customer experience to their end-users.

Into the future

At this point, my conviction that we are building a product that will ultimately be broadly adopted is 110%. Capture can replace traditional mobile crash/observability solutions, provide 1000x the data when teams need it to efficiently solve customer problems and understand fleetwide behavior, and all the while cost vastly less than other solutions. This is a winning combination if there ever was one. As far as we have come, I am even more excited for what comes next as we make the product even more useful on the path towards becoming the de facto mobile observability and crash/issue reporting tool within the industry. From completely independent self signup (while I love our sales folks I know some of you would prefer to not have to talk to them right away), to enterprise features such as rich APIs to automate workflows and export data, to future integration with LLM/MCP systems, Capture will only become more powerful and indispensable in the coming months. Onward! Interested in learning more? Check out the sandbox to get a hands-on feel for what working with Capture is like and then get in touch with us for a demo. Please join us in Slack as well to ask questions and give feedback!

Stay in the know, sign up to the bitdrift newsletter.

Author

profile picture for Matt Klein
Matt Klein