Transcript: How Chronosphere Solved Observability in Containerized Environments to Build $1.6B Company | Uber spin-out, 5x Cheap & Impact of AI in Observability | CEO Martin Mao | Startup Project #101

the first thing we notice is um a lot of companies are not, like even if you incorporate LLM technologies into your application, you still have application logic as well, you still have CPU based workloads. So it didn't displace those use cases, which is good for us, but not just that, it added new use cases, right? Like now you have GPUs you're potentially monitoring for inferencing or or or whatever, and you do need to it it it did create new use cases to observe for sure. One thing we notice is, you can imagine at the, like let's say monitoring a GPU cluster, is not too different from monitoring a CPU cluster at the infrastructure level. Yes, there's different metrics, different things you're you're carrying about, but you know, like it's still like in our tool, it's just as effective to use our tool to monitor a GPU cluster versus a CPU cluster there. Hello everyone, you're listening to Startup Project. I'm your host, Natraj. Uh my guest today is Martin. He's the co-founder and CEO of Chronosphere, an observability platform for modern containerized world. He was previously engineering manager at Uber, technical lead at AWS. In this conversation we'll cover building scalable and reliable observability platforms, the challenges in managing large-scale distributed systems, and future of observability. If this is your first time listening to Startup Project podcast, don't forget to subscribe to us. It helps us reach more audience. Martin, welcome to the show. Thank you for having me. Looking forward to our conversation today. So how did uh Chronosphere start? Uh when did you decide that, you know, I have to stop working at other companies and start my own company? Yeah, actually, the the story goes back to when myself and my co-founder worked at Uber. Uh we actually drove the led the observability team there. So we faced a lot of the challenges that uh we're currently solving for our customers here at Chronosphere inside Uber internally. And what we end up doing was creating a bunch of new technologies in that in that solution. We open source a lot of those, and it sort of showed us that these problems uh that we're solving for Uber inside observability were also being seen by the rest of the market as they started to containerize their environments. And that ultimately led us to say, hey, we should probably create a company here so that, you know, we could bring the benefits of these pieces of technology to the rest of the market as well. And uh what what is the type of the problem that you specifically face, you know, faced for Uber and that was not available outside at that point of time? Yeah, it's a great question. I I would say if you think about observability, you know, it's just the the visibility and insights into your your infrastructure, your applications, your network, and the business, right? The the concept is not new. We've had observability software, you know, used to maybe maybe called APM software or infrastructure monitoring software. Like the the concepts have been around for a long time, there's been a lot of um there's been a lot of solutions that have been around for a long time. What ends up happening is when you start to containerize and modernize your environments, uh two things happen from an observability perspective. The first thing is you can imagine you're breaking up your larger monolithic applications into smaller microservices. So there are more tiny pieces running, you're running on containers, which are running on on VMs. There's just more things to monitor and observe, and that generally produces a lot more observability data. So the very first problem you'll find is either there's too much data for your backend, or it costs you too much. That's one aspect that a lot of folks in the industry see when they start containerizing. And the second thing is you can imagine the types of problems you're trying to solve on your monolithic apps running on a VM, are slightly different to the types of causes of problems in a distributed um, you know, container containerized environment there, in the sense that you can imagine a lot of APM software was really looking at, let's say, how the software was interacting with the hardware and the operating system, whereas in a containerized world, you generally don't get even access to that level. Plus also more often than not, you know, a cause of your issue is some downstream dependency did a deployment or a feature flag change or something like that. So the causes of the problems have changed over time as well. And hence you really want a a tool uh or a product that can it's highly optimized for the newer types of problems that may be coming up. So those are probably the two big problems we saw at Uber. It was producing way too much data and it costs us way too much. Um and it wasn't really the ideal tool uh for these new environments. And and when we looked at the market at the time, there wasn't actually anything we could buy. Uh so we ended up being forced to build our own solutions at at Uber. What were the sources at that point of time that were available? Because right now I think there's a lot more competition in the observability space. It it was it was still I would say a lot of competition uh back in those days, but different types of of companies for sure. Um, you know, back then tools like AppDynamics, New Relic was was very popular. Actually even Datadog was, you know, I think that they were like a series C company when we were looking at this um this problem space. There were a lot of different solutions, but none of those solutions were targeting containerized environments. You can imagine it like the the majority of the market in 2014 when we were solving this problem at Uber, had not containerized. There was like pre- Kubernetes becoming the de facto platform there, right? So most folks were running on VMs. And I would say an APM style uh piece of uh software was probably the right solution. Uh whereas today, you know, that's changed quite a lot. But yeah. And you mentioned open source. Uh was this M3 uh database that you opened source? Yeah, it it was quite a it was actually multiple solutions. One was M3. Um that was that the backend and it was a time series database that was great for storing um metric based data, so numerical measurements over time. Um, Jaeger was created from the same team as well, that's for distributed tracing, that's a CNCF project today. And bits and pieces of various clients and things like that um were also open source as well. But yeah. So you saw a gap in the market that no one is addressing, you decided to start the company. Uh what what were those initial days like? Um, like talk to me about like getting your first five customers. Yeah. Uh so so to your point, we we saw a gap in the market and that wasn't even when we were creating the technology. I think it was much later, especially around I remember 2018, 2019 when, you know, um at I think a a a CubeCon in Seattle actually, um, you know, all the major cloud providers said, hey, we're going to go all in on Kubernetes. And it was it was sort of only then that we realized, okay, there's a real gap in the broader market. Um you can imagine just like every other startup, nobody knew who we were. You you go to somebody and you're like, we we're Chronosphere, we're a tech startup. Nobody really uh knows you and there's no brand recognition there, right? So it was actually quite difficult um in the beginning. And to get the first five, I would say um one or two of them were I would say companies that we had worked with people at those companies when we were at Uber. So there was a little bit of trust on, okay, this was the observability team at Uber, we had worked with them before. We have used the technology before. So that gave us a little bit of credibility and trust on a couple of those companies we were working with. Honestly, the rest of it was just, you know, you can imagine the typical outbound. I was on LinkedIn every day sending 500 messages to various VPs and uh and and and CEOs out there saying, hey, this is a this is us, this is the problem we're trying to solve. Uh you know, uh is is is there any way I can I can get you on a call. So, a lot of uh I would say outbound uh emails and messages uh to try to get those opportunities. In some way it's also like um mission critical, right? Because the observability data is used to find issues, live issues in your product or service and to fix those issues if, you know, anything, because it tells you how your services running or not running. Um so it's it's always hard to convince when you're creating a mission critical uh technical product and selling that to a company. Uh so what those initial customers were like, okay, we are just transitioning it to Kubernetes, so this might be a good time to test it out because we have not entirely built out our service? Yeah, um actually it was interesting. Uh we see more of that today. Initially, it was a lot of companies that had actually were already transitioned. Uh so there were a lot of tech forward companies that were running mostly containerized environments at scale, it's like 2019, 2020 by the time we started the company. To your point, I think being mission critical, actually probably doesn't help us uh or didn't help us as a startup, right? Because you're like you're trying to convince this company to replace a piece of mission critical software that they're probably purchasing from a big public vendor and a well-known brand name. And here you are as a one or two year old startup trying to replace that piece of mission critical software. I think what that translated to was the benefit of switching had to be so large uh that it would outweigh the risk of replacing a mission critical piece of software. And for us really early on um the majority of the benefit there was uh both on the scale and the performance side of the backend, but also on the cost efficiency um from the beginning. It was just so compelling from a uh it was so much more cost efficient than the other solutions they're using today. Uh and a lot of companies um cared about that back then. Plus a lot of scale and reliability for properties. And you know, we're not talking like it's 20% more cost efficient. We're talking like it's like four to five times more cost efficient, right? I think that the gap had to be very large back then, because of course like you you know, if I'm in their shoes, that's a pretty risky decision to make to bet on a on a startup for such a mission critical piece of software. Uh but yeah. So you sold companies that were already operating at scale on the cost benefit that they're going to get? on on on both the cost benefit. You can imagine scale because these were tech forward companies already. They were growing their businesses at, you can imagine pretty incredible rates, you know, 100% year on year or something like that. So they really had to care about the future scale, they had to care about the reliability of observability. If you think about it, you know, if you want to provide your customer 3 9 SLA, you actually really need your observability tool to give you better than 3 9 because if your observability tool can only run at three 9s, like there's no way you're giving that that guarantee. So those properties for that profile of company that was tech forward at scale, um uh you know, was was a good fit there um at the beginning. Um, in terms of uh let's talk a little bit about like the products that you offer. So can you talk uh high level, you know, what are the products that Chronosphere today offers? Um and also talk a little bit about the business model. Yeah. So there's two products that we offer. One is our observability platform. Um that is pretty typical observability platform. You can imagine you can ingest and store logs, metrics, traces, events, all of the various types of data that's produced by your infrastructure, by your applications. Uh we obviously ingest and store that uh and then we provide all of the analytics capabilities on top so it can help you um debug issues. I would say compared to, you know, that's pretty standard of these platforms, compared to the others in the market, it probably differentiates in two main ways at a at a high level. Uh the first is cost efficiency, uh and we don't just do that from unit economics uh there. I that is one way, but actually what we realized is in observability there is a lot of waste. Uh you store and pay for a lot of data that you may or may not need. Uh and what's interesting is the way these most observability companies are set up is that they charge you for more data that you produce. It's a pretty typical SAS type of model, right? So you can imagine these existing vendors are not motivated to have you reduce that data volume. They're not actually motivated to tell you what's useful and what's useless. But us Chronosphere as a disruptor to the industry, we have to do something different. So actually what we did was we created features that would actually show the customer what is and isn't useful. And you can imagine they can make some decisions and we gave them a bunch of tools to optimize the data, thus that we can align that they are only paying for the useful data. And you can imagine the useful data is generally a subset of the whole data set there. So that's uh our way of ensuring that the costs are lower. It it it does reduce your cost, but it's really a guarantee that you know that everything you're paying for is useful. It's been used, right? So at least you know your your dollars are being well spent. Of course, the overall dollar amount is reduced. And then as I mentioned earlier, you sort of need a different tool that goes and optimizes for, look, the the probability and the the the probable causes is probably a downstream dependency. It's probably like a, you know, generally software doesn't break unless you do a change, like you roll out a new version or you change a feature flag. So it's looking for those changes and trying to correlate them with issues and whatnot. And I would say generally what our customers have found is that they probably reduce their time to detect and resolve a problem by around 65% or so. So it is generally more effective at at solving problems um than their existing tools that they're on. So that's the observability platform. That's how it differentiates in the market. Separately, we have a separate um uh solution called a telemetry pipeline. It's actually called a uh observability telemetry pipeline. And what that does is actually you can actually install this inside your environment. You don't have to do a migration over to Chronosphere. You can like put it in front of, let's say, Splunk or Elastic or some existing tool. And it's actually going to try to both uh route and transform the data it collects to those backends. But it can also uh reduce and optimize those data volumes as well, right? That there are certain things you can do in your environment to to gain that that efficiency uh there. You can do things like, okay, let me route subsets of the data to um you know, uh cold storage S3 or Azure Blob Storage for things like that to to reduce the cost there as well. So that's a a separate product we have. You don't have to use that with our observability platform backend. Uh but you know, you can imagine that they provide um a similar benefit without the migration uh there. So it's like if it's almost like selling to customers who use your competitors. Um, it's Splunk and because they're technically your competitors, right? As a product, they also have observability and you can still use telemetry pipeline to reduce costs even though you're not actually switching to Chronosphere? Yeah, and that's uh, you know, ideally we would want everyone to to switch, especially for their containerized environments. But, you know, that might be that might take some time. You might be locked into a contract. They they may be other difficulties there. Uh so the telemetry pipeline both allows you to do that transition uh eventually. And not just to Chronosphere, you can imagine with something in the middle, you can perform a migration from one tool to any other tool. Um but but but also reduce the costs in the meantime as well. So provides a lot more short-term value um to our customers, and then longer term to get to maximize that value. Ultimately, ideally you would switch over your observability backend as well. Do customers using observability products think about the predictability of cost? I would say in the last two to three years as the economy has changed, uh they care about it a lot, right? And it's not just the absolute dollar amount. Like a lot of our customers are seeing what fraction of my revenue, what fraction of my operating expense do I do I spend on both cloud infrastructure overall, but in particular observability, because it actually gets quite expensive there. And the predictability and knowing what relative percentage of cost that is matters, because even though you you know there's an absolute dollar amount for sure, but you can imagine if your business and revenue was to grow 2X, but your observability costs is going to grow 3X. That is just a bad efficiency model over time, and over time you're going to get far less efficient, right? So the predictability and and bit being able to both see but also control that uh is is actually key. Uh and it's it's the controlling piece as well. So you can definitely see it from a dollar amount, but you can imagine like when we provide our customers with the tools that show them where their spend is going to, what pieces of the data is useful, how it's being used by the end users. It really just gives our our customers an ability to pick and choose and make those decisions. You can imagine a executive can say, hey, I actually only want to spend, you know, let's say 5% of my operating budget on observability. Well, great. You can do that. We're just going to show you, okay, this is how all of your data is being used. And in order to get your budget back to 5%, here are some tools you can use to reduce the the volume of data being stored and being used uh there. I think there were a series of products that I used to see a while back, uh which promised um cost cutting in cloud. Um and I always felt like, you know, products that already have observability sort of data, um can do that in a a better job of, you know, reducing cost overall for your infrastructure. Um is that a right assumption when do you help your customers not generally for like predicting, you know, your the observability service costs, but in general your out cost or your infra cost? Is that something you help your customers or is that a product or a feature that is potentially on your roadmap? Yeah, that's a great question. Um so so the interesting overlap between observability and I'll say cloud cost management is all of the utilization data, like how many cores you're using at what percentages, how much memory you're using, how much disc you're using, all of that data already exists in your observability platform. Uh it's already there, right? And and you're not just using that for cost management, you're using that to know when, you know, there's a spike in CPU and and whatnot. So what what's interesting is we already have that data for other purposes. What we do for our customers and it's it's it's it's a great point, like maybe we should productize this. But what we do for our customers is we actually just allow them to um have open source based uh dashboards and visibility into that. So you can imagine if we already have the utilization, you can run something like Open Cost, uh which is just an open source project on top of this and actually see cost insights on your infrastructure. So we give them the benefit because all the data is there. We're not trying to double charge for it or anything like that, because again you're using the data for something else. So a lot of our customers are using us for that. Um not alone, they have to pair it up with an open source project uh right now or perhaps pair it up with a product that they buy off the shelf for that. The advantage of doing that with Chronosphere is you don't have to duplicate that data into the cloud cost management platform. And Chronosphere, you only pay for that data once and you can have two benefits from it. Um, you know, it would not perhaps be a a terrible idea for us to try to monetize that in the future, but right now our main focus is on, you know, you can imagine the core benefit of observability is improving that uptime, reducing the number of incidents and what not. And we feel like that is generally providing a much um more benefit to our customers than perhaps on the cloud cost management side today. So one of the things that we see that, you know, uh multi deployments is they are attached to one or two clouds, right? Customers have uh attachment towards one of the big three clouds. Um and all the three clouds have some version of observability products. I know Azure has Azure Monitor, AWS has I forgot the name, but Google has its own observability platform. Cloud Watch. Yep, yep. Yeah, Cloud Watch. So how do you compete uh with those products? Because, you know, there might be some kind of bundling pricing, you know, as the minimum, it's scale there is, you know, pricing advantages for all the three clouds. Um how does being a product from you know, not these big clouds? I can also see an advantage because there are certain areas in the cloud where not being part of any ecosystem is actually an advantage. Um I'm curious how you think about playing in this ecosystem, right? When there's so many so pretty much every service has a competitor and a partner from the big three clouds, right? So I would love to know your thoughts and how do you think about this uh playing with the ecosystem. Yeah. Um I'll probably look at this from maybe two or three different approaches. The first thing I think that's unique about observability in particular, um versus other categories or types of products is, you got to remember that observability is the thing that's meant to tell you if your infrastructure is up or down, right? It's the thing that's going to tell you, I'm up right now, I'm serving customers. Now, if that's running on the same infrastructure, so let's take for example, I won't pick on Azure. Let's let's pick on AWS, right? Like their services depend on, let's say, but their observability services depend on S3 and Kinesis, for example. So when S3 goes down in a region, your infrastructure is probably impacted. Like you as a company probably depend on S3, it's probably impacted. The thing that's meant to tell you you're impacted, also depends on S3 and is down at the same time. And this is just generally what happens, right? You can imagine US East 1 goes down, half of the internet goes down, right? But it's actually in that moment in time when you need to observability the most. Um and the fact that it's coupled, it it's not the same for databases and things like that, but for observability, the fact that it's coupled is actually there's a huge advantage to decouple that. There's a huge advantage to say, I don't want my infrastructure that I'm monitoring to be also the infrastructure that my observability comes from or runs on. And it's not just from the cloud providers. I actually think companies out there should think, well, even if I use a SAS provider, what do they run on? Because if they run on US East 1 of AWS, it's not going to matter because even though it's a SAS provider, we have a common dependency there. So that's actually pretty unique. And for us, not just as a vendor um that's not a cloud provider, but actually our architecture is purposely single tenanted. So we have an ability to make sure that we are not on the same public cloud infrastructure that you the customer is running on. So that when you need us the most, I can almost guarantee you that we won't be affected by the same thing, right? So I think that's one thing I think about there and that's a huge disadvantage about observability services in particular in the cloud providers that maybe don't exist on some of the other services there. The other angles I think about this is you can imagine and I used to work at AWS and Microsoft and whatnot, like they're really good at providing building blocks, right? Like they're really great at providing the underlying infrastructure, the pieces you need. They're less great historically at at building a great end-to-end SAS product. They just it's not in the DNA, it's not what they're trying to do. And I think in observability it's the same way. If you look at these services like Cloud Watch Azure Monitor, what not, I think it's a decent storage for that data. Great, like that that's fantastic. Do they have, let's say, these capabilities to show you the efficiency of the data and the cost? They don't really have that. Are those tools really great at like deep root cause analysis and anomaly detection? Like normally the product is is not quite um as advanced there as what you could find um out in the market, and that ends up being a a differentiator as well. And I would say that if that's not the case, then we wouldn't have a marker. Like if you look at the observability market and who the leaders are and like if you look at the Gartner Magic Quadrant, who the leaders are. None of the cloud providers there. You see, you see, you see Chronosphere there, you see Splunk, you see Datadog, you see DynaTrace, like in this market, it feels like it's been tried and tested that products generally will hold against um against what the cloud providers can provide. Now, if my value proposition at Chronosphere was different, if I only wanted to provide cheap storage of metric and log data, I would actually probably have a lot more higher competition from the cloud providers there because the the difference in value is much closer. So I think what ends up happening is as a vendor and as a company that needs to compete with them, I think you need to put a lot more differentiation on the product side as opposed to on the underlying, you know, um storage and unit economics because if you if you play that game, you're probably going to lose against the cloud providers. What's your philosophy on you know, thinking about what are you going to build next? We listen to um a lot of our customers on this. Like the good thing is you can imagine generally the tech forward leading companies are containerizing first. Um they're doing it at at scale. So generally we get to work with the companies who are who are normally at the bleeding edge of the technology stack anyway. Uh and they're the ones that are constantly pushing us to say, cool, you've given me these features. That's great. Uh what is next? And they actually inform a lot of that. So I do think have targeting the bleeding edge uh and the early adopters in the market gives you a lot of input onto product innovation versus if you're trying to build a product that's tap targeting the laggards or like the vast majority, you're probably not going to be able to get the insights from your customer base there. So I think we're pretty lucky that we we we we target the early adopters and the folks right at the edge uh and the innovators um uh and the and the tech forward companies, and they actually provide us a lot of um uh they provide us a lot of input into how to further improve our products um there. Who are those some of the tech forward customers today? Because it might be different when you first started to, you know, who who those customers are today, like so talk to me a little bit about those customers today. Yeah, when we first started, it was I would say a lot of um large companies that were digital natives. So like DoorDash, uh Robinhood, um like Affirm or or Box, like these are you know, generally companies that grew up in the 2010s, um started off in the public cloud, you know, as opposed to on premise hard or anything like that, generally. Um you know, they were the first to containerize because they could see all the advantages and they grew huge businesses uh in in that particular uh era and they were really pushing technology uh uh there, right? So, you know, that was our our sweet spot at the beginning. You know, in like the 2020, 2021 type of timeframe. I would say today, we actually see, you know, more of the majority of the market now containerizing. So now if you go to like pretty much any big enterprise out there, you pick like a you know, a JP Morgan Chase, an American Airlines, like a Visa, like those are companies that are containerizing their environments actually at at fairly large scale as well. That that they may have been doing it like a year or two behind, you know, those those tech four companies, but the majority of the enterprises are doing that. Um and it's not just because that's a necessarily a definitively better architecture. I think to your point earlier, most companies need to depend on multiple cloud providers today. I don't I don't see I see very few big companies taking a single bet on a single cloud provider. In fact, not just do they bet on multiple cloud providers, they generally have a hybrid strategy, they have some portion of their environment that's on premise uh as well, right? You can imagine if you have that, you have two to three different pieces of infrastructure. If you don't containerize, what what you really and if you don't have a common infrastructure layer like a Kubernetes across that where you can move workloads around, you're really going to have to implement your infrastructure three times. Uh and that is, you know, just a very expensive decision. So I do think that most enterprises are on this move to containerization because they have a hybrid and multi cloud strategy there. And now we're actually seeing a lot more demand from those companies as opposed to just the tech forward companies. Of course, the latest, you know, uh is is all the AI companies out there. Uh the the good thing about that is everybody who's starting out at AI startup these days or a scale up, you're going to be running on modern containerized infrastructure. Like none of those companies are running, you know, like on prem, uh even VMs. All of them are containerized from day one. And that's also again like our our sweet spot and what we've optimized the product for uh there. So is uh is it a big differentiator that you are, you know, focused on containerized applications versus um I haven't I don't know if Splunk just, you know, looks at that particular uh just for Kubernetes clusters or um is that a big differentiator in the industry or? It it it it is a big differentiator, but it's a big differentiator because it solves the two pain points when you containerize, right? If we just had a solution that was targeted at containerized environments, but let's say the volume of data did not increase a lot. If that was the case, it wouldn't be a big differentiator because nobody would really care about it. People only care because when they do that, inadvertently they are, you know, you can imagine uh when you go containerized, it's not like the the containerized architecture gives you more computer or anything like that. It's all the same VMs and compute power at at at the end of the day. But actually one of the big differences that people don't think about is your volume of observability data grows a lot, right? So you can imagine when people are doing this, they're noticing that their Splunk bills or their Datadog bills are going through the roof. And that creates a lot of pain on one hand on the cost side. And you can imagine that feeds into one of our advantages there because that's one of the things that we are solving for. And on the other side, again, as you as you shift more and more workloads there, more often than not, the source of your like problems are those situations I described earlier. So it it is a differentiator for us, I would say, and I would also say it's very hard. You can imagine if you take the Chronosphere software and you go take it onto a mainframe environment, it's not going to be very, hey, it's not going to be very effective at solving those pro. You can do it, but it's not going to be extra effective at solving those types of problems because that's not what it was optimized for and you don't have a cost problem there. Like it's not like the volume of data has increased on your mainframe. So the there is a little bit of like a product being built for a particular market, a particular use case there, that I think it's very hard to have something where like one product is the best fit, is the best solution for a mainframe environment, for a VM based cloud environment, for a containerized environment. Normally that doesn't happen. You have a different product that's specialized for those things because the pain points and the problems you're trying to solve are quite different uh between those environments there. How do you position yourself or another way to ask this is um how do you market um an observability product? And another way to say this is how do customers how do you acquire how do you acquire customers today? Yeah. Um so if you think about Chronosphere and what we're targeting. So we're targeting those environments first, right? So you can imagine uh you know, we will go and ensure we target companies and and and reach out to companies or try to target companies that are containerizing more than they're not, right? So there are certain, let's say verticals that are great fits for us and there are certain verticals that are not great for fits for us. So we do scope and target that a little bit. The second thing is if you think about our advantages there of like cost, scale, reliability. You also have to think about which end of the market cares about that, right? So for the same properties, if I go to somebody and and you're, you know, you're you're a relatively small, you're containerized, but it's a small environment, right? If you're a small environment, do you really care about cost efficiency of observability that much? Probably not, because it's not costing you that much. Do you care about four or five nines of reliability? Probably less so. Do you care about the performance? Probably less so. So like then you have to think based on our product, uh or like based on your product and in Chronosphere's case, all of those properties are really geared towards the top end of the market, right? So all of a sudden now for us it's like, okay, let's go after large containerized environments uh there, right? Uh and then beyond that, you can imagine a lot of these properties, you know, there are benefits for the end users, but there are also benefits for the the the executives, because you can imagine the executive cares about the budget and things like that, right? And observability is also one of those things where I find especially today in a distributed architecture, it's very hard for one team and one end user to just observe one piece of the stack and get a lot of value out of it. You get the value out of like observing the whole environment and everything interconnected. And because of that, normally you can imagine like a a PLG motion where one person will just try to deploy it on their one app, doesn't work