Ep # 136: Solving Half-Adopted Cloud Challenges in a $10B Market ft. Paul Dudley (Streamkap, CEO)

Adil Saleh 0:03 Hey, greetings everybody. This Adil from hyperengage podcast. And, you know, in the past three years, we've, we've had a ton of platforms, you know, that are helping with data on the GTM side of things, revenue side of things, you know, some of them are, like data ops teams that are helping, you know, teams. But very, very few that we talked about that are actually helping with the engineering side, infrastructure side, you know, how to, you know, populate your data at scale, the lower cost, and, you know, more efficiency. And you know, of course, in the real time streaming. So, I mean, it's my pleasure to have someone like Tom, who's the founder of Streamkap, cap with K letter K, and founded this platform about four years back, and they're helping engineering teams with screening ETL and you know, and they've been very successful and the recent time. So, Paul, thank you very much for your time. Paul Dudley 1:06 Yeah, my pleasure. Yeah. Appreciate having me on Adil Saleh 1:10 Perfect so, I mean, the first thing that made myself and my team curious is, is, is how big of this problem going going forward for the teams that are, you know, having data warehouses at different places and huge amounts when it comes to, you know, the size of the data when it comes to, of course, the security side of things as well. So how did you actually see, I see that you you exited gravity in the past as well. There was also a TL platform. Could you tell us a little bit more about your prior experience and how it entails, you know, and actually contributed to the inception of Streamkap, and how big of a problem it was back in 2022, when Paul Dudley 1:53 it started? Yeah, so, I mean, broadly, you know, moving, moving data around between different systems is, you know, is already a, you know, 10s of billions dollar business. And you know, it goes back to pre cloud era, when people were doing everything on prem and had to, had to move data around. So in certain ways, this is a very well established industry, but the sort of modes and mechanisms for that have changed. So we obviously had the transition from on prem to the cloud, you know, which really kicked off in the 2010s and is ongoing, I think, to sort of rough estimates are like, we're sort of halfway penetrated into the ultimate like level of crap of cloud adoption that we'll see across the industry. So there's still a lot, long way to go there. And then, you know, the other is that, you know, sort of going back to the very beginning of of ETL, which trans stands for, extract, transform and load. But you just think about it like moving data between systems. Yeah, that's always been batch processing and meeting, you know, once a day, once an hour, or something like that. Everything that's happened in that that previous period of time gets updated, you know, across to the other system. And we don't need to get super deep into why you need to do that, but, but in short, you know, they're different. Different databases are better for different things. And so, you know, we've seen in the past 10 years or so the growth in cloud data warehouses like snowflake and you know, they're specialized, built for analytical processes. And so I worked at two companies Previous to this, one gravity, which I was co founder of, and the other of Bora, which was where my co founder and now co founder started. Both of them were data companies, both built in the cloud data infrastructure space both focused on batch processing, and the insight that we had that led us to start stream cap coming out of that experience was we saw more people doing streaming. We saw more requirements for low latency data, and generally people were having to build those solutions with very complex, lower level systems. So they'd spend months getting into production data pipelines. And if you contrast that with what we kind of experience, we'd been able to provide with gravity, you know, it was minutes to get up and going. So basically, we wanted to bring the experience that people were accustomed to with modern cloud data platforms in the batch world to the streaming world. And we knew, you know, there's, there's a ton of people who need to do that and, and, you know, for some, I guess, consumer focus and things that we, everyone is familiar with, you know, in terms of the reasons why, like, the low latency matters, if you think about, you know, Uber Eats, for example, right? As a consumer, you're ordering on your phone what you you know you want for dinner, and you can see in real time, like, where, what's the status of your order, right? And so that's that's pretty important for you as the the end user, that that kind of data is super important for the driver, because. They have to know which orders are they getting. Where, where are those orders? You know, what do they need to go with them? Behind the scenes, there's routing that that needs to happen to make sure that, you know, one driver is not getting things that are all over the place. Obviously the restaurants need to know what orders are coming in, who's picking them up, that kind of stuff. So all of that, like back end infrastructure, stuff that Uber has built, they have huge engineering teams and operate at massive scale. But there are, there are use cases like that across a huge variety of businesses that don't have the engineering resources that are required to build that. And that's really what stream cap does, is we kind of bring that underlying infrastructure make it super easy for any business to adopt, adopt streaming and deliver kind of lower latency for either operational use cases or or customer facing use cases Adil Saleh 5:48 with with significantly low maintenance, yeah, Paul Dudley 5:52 no maintenance, and generally lower cost than batch. So there's really kind of no reason not to adopt it. I mean, that's been our kind of big value prop is our customers don't need to have a bunch of existing streaming infrastructure or expertise. Basically, they can bring us into their existing architecture, and we just make things go faster. Adil Saleh 6:11 Amazing, amazing. And I was also curious another thing, of course, when we talk about the developer tools, they don't have, like, you know, like all the B to B SAS companies, more in the GTM function, customer support sales organizations, they have, like, their own customer success platform or cm that they're finally invested in. So what about you? Like, how you're basically onboarding the customers? I'm sure that's going to be pretty long sales segment when it comes to infrastructure integration and all of that. So how does that go towards the onboarding side of things, and then really taken from Paul Dudley 6:46 there? Yeah. I mean, it can be, it can be a longer sales cycle for larger enterprises, not not so much from a technical perspective, but just, you know, the processes that they have in place, you know, because generally, we're integrating with their core product databases, where, you know, there's very, very sensitive data. And we do offer, you know, a bring your own cloud so we're actually, we can deploy in their cloud environment so their data doesn't leave, which actually helps that a lot. Because they're not, they don't have to worry as much about, you know, our security posture, even though we're sock two type two certified. So yeah, for enterprises, it can be, you know, can be a few months. But actually, because we make it really easy, you know, for sort of mid sized businesses, you know, we've got the kind of key elements that we tick the boxes on security and so, you know, it doesn't necessarily take a long time. It can be just a few, a few weeks, you know, like, get get things plugged in, to do an initial test, which users can do on their own, but we help them with if they need it. And, you know, they kind of verify, you know, does it work? Does it move data from A to B? It's one of the really nice things about our product, is like the success criteria is pretty binary, right? It's not like, it's just like, hey, do we need it to get from from from one place to another. And if it does that, you know, if it's low latency, if it's reliable, if all the data arrives, which we're going to doing all those things, then, you know, it's like, okay, yes, this works. And up to the you know, the pricing is a factor, but generally, we're very good value for folks, that's usually not a big discussion. So our experience has been that, you know, it's, it's, you know, it's something like a 30 day sales cycle for smaller companies, and, you know, like, I say, for bigger companies, just because of the process that they bring to the table. You know, it might be something, you know more in a few months, but, but generally, it's not super, you know, it's not super long sales cycles. Adil Saleh 8:38 Okay, so along the journey post onboarding. Like, do you also track the interactions? I'm sure there's some level of actions that you're tracking for all the customers to, you know, make sure that you help them with adoption to the product. And also, of course, if there is any chance you can expand down the road, like, Yes, from a customer success standpoint, how does that process work for Yeah, Paul Dudley 8:59 so again, it's, it's not, like, it probably as complicated as it is with some other platforms, because, like, we're not our main mechanism is, like, how much data are we moving, for you, which is, you know, somewhat correlated to the number of users, but not particularly, right? So generally, we never expect have a large number of users, and that's, you know, so we're not having to do, like, fine grained analysis of, like engagement and things like that. It's more like, how many connectors do people have, you know, are they connecting different databases? How much volume is coming through, and then, and then, there's also, like, a softer sales kind of thing, like, are there other divisions that could use us and that kind of thing, but, but, yeah, it's relatively straightforward for us to see. It goes back to that sort of binaries, like, is it connected? Is data coming through? Is it reliable? And then are there other data sources that we could, we could bring in, is kind of the main things that we look for. Now, on the flip side of that, in terms of like, looking for problems. During adoption, you know, it's like, okay, there's, there's some fairly straightforward things that happen on a regular basis. Like, we have docs that tell you, you know, what permissions you need to grant our user in order for things to work. And, you know, sometimes people don't read the docs, and so they have an error in that, right? So it's not like nothing that's overly complicated. Generally, no, there are corner cases, obviously. But like, generally, there's kind of a few classes of like, problems that people run into that are generally configuration issues. And so, yeah, that's an area where we can jump in and help out and say, like, Hey, here's the, you know, we have this stuff in the docs, but like, I say, not everybody always reads the docs. So we can say, here's the script you need to run to make sure you've got the right permissions. And, you know, we're up and going from there. So there's definitely a lot of value that we can add in helping people on that journey. But, you know, I think again, in our world, it's not overly complicated, Adil Saleh 10:55 yeah, and also this looking at the knowledge base and everything is super important. Because being a being a founder, I know that it's become, it's become a family expert for other teams, if you don't look at that knowledge base before reaching out, yeah, and I think, you know, few months back you work. Adil Saleh 11:15 Yeah, there's a little lag. I'm sorry. Go ahead. Paul Dudley 11:18 Yeah. I was just saying, I think, like a general, because our users are generally engineers, I think they have the expectation of like. First of all, they have an expectation that the documentation is good and complete and tells them everything they need to know, which we do a good job of. And generally, engineers are pretty good about like, following that, but not everybody is. And if contrasting that with like end users on a GTM tool or something like that, I think I would have lower expectations that they would read the manual, as they say so, but, but nonetheless, like I said, there are definitely problems people run into because they they haven't read the manual or the docs. And you know, that's where we can jump in and help them, Adil Saleh 11:59 actually. So you got, like, account managers or implementation managers. How's this? We Paul Dudley 12:04 have engineers who work in kind of customer facing roles to support that, because it's fairly technical. Like the main thing that engineers like working with engineers, and so that gives them the confidence that they having a non technical person as an intermediary would not be helpful in that context, absolutely, Adil Saleh 12:26 absolutely. And I was also thinking about, like, a lot of these, you know, developer tools, I would say, like, see, customer data platforms, these, these kind of tools, they go about like accelerators or venture backed funding at the beginning. So how did you not think about it like, of course, you've raised funds, but thinking about not going through accelerator or, you know, tech storage is very suitable for product like these. So have you checked around these, these accelerators? How was that? Yeah, we, Paul Dudley 12:59 we did not. I don't know, we didn't, we didn't submit to any, I think, other than yc. And I don't know, maybe we should have submitted to TechStars, but, you know, I think my general sense is like that. You know, there's probably some value add in those. But like, YC has the one that has, you know, perhaps the most value add, but definitely in terms of, like, the process itself. But, you know, there's a clear value add in terms of, like, brand signaling, which is helpful, but for the others, I'm not, it's not so clear to me that that's the case. And so I think you're weighing up in that case, like, is the process helpful? Is there something differentiated? Because generally, the, like, the dilution that you take with those is a bit higher than you might have otherwise gotten with, like, just raising pre seed, you know, from, from investors outside of an accelerator. So, yeah, I just didn't my sense, you know, I'm not an expert in this, per se, but my sense was, like, the the signal from, from there was no, no accelerator that had positive signal in a meaningful way other than than yc. So, yeah, I don't know, yeah. I mean, you have Adil Saleh 14:12 your viewpoint that's, that's, that's the thing, like, it depends on how it should be more aligned with, with your business vision, and, you know, the commercial side of things as well, like how bad you want customers and how relevant those those customers are. And your case, like y Come here you see, like you have more peer growth that is more relevant to your ICP. And apart from getting, you know, advice, and you know, all these resources that they have, you get to meet with, look like founders, and you know, it's such great network, very close that network. So now thinking about like raising funds, like what was your first thing you know that you wanted to prioritize while raising funds? Of course, you were ready at that time. It's important to be ready for funding. And so how was that process, you know, generally not talking about, you know, from from funds perspective, talking about, you know, how to drive the vision of your product, and having the freedom to do what you want to do with the product. Paul Dudley 15:15 Yeah, I mean, we, I mean, I guess we had a pretty clear vision for what we wanted to build. And so I didn't feel like any of the investors that we who were interested, I mean, the people, the investors who came on board in our pre seed and ultimately in our seed round, were all aligned to that vision. So I don't think we felt like we were at risk of compromising any of our product vision on behalf of investor, I think you have to be a little careful like because I think even very well meaning and smart investors, they're going to come to your conversations with a viewpoint based on the pattern matching that they've seen across all the companies that they've supported, right? And I think you just have to keep in mind that can be good advice, but they don't know your business as well as you do, and they never will, right? They know about fundraising, which is valuable, right? But, and again, they can look from the outside and say, Hey, like from a pattern matching perspective, like the way that you're set up doesn't like match the expectations of a series, a investor or a seed investor or whatever it is, right? And so that's helpful, because you can think about, like, Okay, what if you're kind of, if you're, if you're focused on fundraising, you know, what kind of shape do you need your team to be in? What kind of story you need to be able to tell from a product vision perspective and a market and that kind of thing. But at the end of the day, like, they don't know your customers as well as you do. They don't know your product as well as you do. So you just have to be thoughtful about, like, what it is that they are good at from the advice perspective, and often they're really helpful in that context. But you just have to gage that through the lens of like, what's right for the business. And you know, I think my my core driving thing has always been like, what is going to deliver value for customers? And if we're able to do that, and you know, and by extension, deliver more revenue, then everything else will work itself out. So that's oversimplify things. But you know, if you have a valuable product that people want to buy, then you know, you just want to architect your business around, you know, continuing to provide that in a in a, you know, with good margins, and, you know, finding more customers, right, which is kind of roughly where we're at. Adil Saleh 17:34 So I mean, quick question on the planning, like, just imagine, like, Would you be able to build the same platform in three in the less than four years, without funding like Bootstrap, like, how did the funding help you throughout this job? Because in this industry, I've looked through a lot of platforms. It's, it's, it's okay, you can build a platform too, but, but to build a platform like this with lower costs, lower maintenance, it's not easy. So how do you see it from that? I mean, looking at some of the founders listening here. These are developers, engineers. They wanted to build the platform, but, of course, they don't have funding, and the funding is the hardest getting right I have capital right here. Paul Dudley 18:13 I have a lot of respect for folks who Bootstrap. We in the world that we were in, like we had a couple people want to hire right away who are not going when we sold gravity, that we're not going with gravity. And so, like, it kind of put us in position where we're like, okay, we want these people on our team, and we got to pay them. And so we're just going to, we're going to go raise money right away, right and so, and that, that's specific set of, sir, and it also felt like we were at a particularly, like, emergent time for streaming in real time. And so, like, we also felt like there was a, there was some urgency around capitalizing on the moment. We're still relatively early, but like, you know that was the right time, I think, to be starting. So those, those, those are the things that kind of pushed us in that direction. But yeah, if you can bootstrap, I mean, in a lot of ways is great, right? Like, gives you a ton of freedom. If you can get to, like, meaningful revenue without funding, it just puts you in a very powerful position, from negotiation perspective, if you decide to raise capital later. But yeah, our situation is such that, like, the combination of the market opportunity that existed, the team that we had available, and you know, what kind of stage of growth that market was in, it seemed clear to us that we wanted to raise money to build that. But, yeah, I think there's definitely, you know, a lot of businesses I respect a lot that have started out with, you know, in my space, like they've started with more of a consulting approach where, you know, they're kind of, they're one just general advice for which I think is very salient for for for founders, especially technical founders, is, you know, make sure you're falling in love with the problem, not with the technology or the solution, right? Because if you kind of over index on the technology that you're building versus the problem you're solving for the customer that can definitely lead you astray. Lately, going back to the bootstrapping like if you fall in love with a good problem, if, as a first step, you have the ability to solve that problem with more of a consulting approach and then build a product that does what you're doing that can be a great way to go, and Adil Saleh 20:19 because we get to meet a lot of known technical co founders. I don't, I don't like to, you know, call them by that, because in the world of AI, everybody's technical I've seen, like, VPs of sales or building platforms using, you know, these, you know, platforms that help you develop and you tell them the problems you perform them. And you know, they give you the platform, interactive platform. So my point is, the best part about being an engineer and a founder is you see the problem very closely. You live with it. And best part is you can build it like you can develop it. You know, you're engineer, and you know that's that's a real job for engineer to solve the problem, which is what you mentioned. So, you know, falling in love with the problem is super important for engineers. So also talking about, you know, these, these platform bootstrapping and, of course, going on their own pace. Of course, everybody wants to, you know, ride the wave and capitalize the time and time sensitivity with AI is a big, big thing. Now you've got to make sure you do things either early or do it really different. Different is now big question, because everybody can do anything, you know, because I'm talking about deep sea, can open AI with you as well being someone picking your brain is going to be very interesting, because a lot of known technical founders that I get to me, they have a different lens. So, you know, it's, it's relatively easier, but from a from a building standpoint, but how you see it as as a marketing standpoint, how to sell it, acquiring customers, getting initial logos, traction, all of that, being an engineer without funding. Paul Dudley 21:53 I mean, I'm not an engineer, so maybe I don't have the perfect perspective on that. But, I mean, I'm a reasonably technical business person, I guess I would say, like, I studied physics, but I'm not an engineer, so, but I think the key thing that, like, I just this, is this is something that every startup, this is not novel advice, but, like, just talk to customers, right? Like, that's the super important thing. And I think maybe somewhat harder sometimes for engineers to do, but even before you have a solution, maybe even before, actually, ideally, before you start a company. Just like, if you have an idea, you've got a problem you want to solve. Go talk to people about that problem. And here, you know, valid, I mean, maybe it's something you've lived yourself, right? Which is great, like, you have a starting place of a really clear view on what the problem is, and you know, potentially, what the solution is, but you just want to make sure that, like, that's, in fact, a problem that other people have. So if you're out and talking to, you know, your your prospective buyers, you're going to get some great insights around. Like, you know, how many people have that problem? If they do have that problem, you've got a great kind of audience of potential development partners who could be early customers, and then also can steer you be like, Okay, well, it turns out that this problem that I had, that I feel really passionate about, is not a common problem, and maybe you have to pivot, or, you know that, or maybe you just decide not to build that business. So the earlier that you have those conversations, the better. But that also helps a lot with fundraising. So, you know, when we went into our first fundraise, you know, I had a over 100 conversations I'd had with data people as as some of the, you know, context for why we were starting Streamkap, right? And that was, that was really impactful, because, you know, we knew that there were people who were facing this problem, and we had people so we're able to get, like, our first customer within a month of starting the business, which it wasn't exactly consulting, but like, in the first version of our product, like, as I described, the main job our product is to do is get data from A to B, and that's all it did. Like, there was no there was no application, no like, anything that you could log into this new UI. Like our team had to do everything in terms of setup. But at the end of the day, like data arrived in BigQuery, and that was the key deliverable. So yeah, having those conversations as early as possible is validation. The biggest thing, right? Adil Saleh 24:12 Validation is super important, like having to, you know, and maybe if you don't have a product, that's okay, just make a small prototype or interactive model to them, and this is what it can do and validate the problem with folks that are, you know, ideal for that, and ideal personas, perfect. So I was also wanted to, you know, pick your brain on on this Chinese language model deep sea that is creating a lot of noise, and they've cut down on the cost and adaptability and a lot of other things, as opposed to, you know, open AI, how do you see it impacting your industry? Paul Dudley 24:51 I mean, it feels to me more like, I mean, obviously it made a big splash in the public markets with the NVIDIA stock price and. And you know, I'm sure if open AI was a public company, it would big, the big impact on opening eyes valuation, although, you know, it seems like it hasn't impacted the like Softbank investment at a double valuation of 340 billion, or whatever it is now. But anyway, you know it, my view is that this is not sort of unexpected, right, like we kind of knew, like I'd heard rumblings late last year that maybe the returns from increased scaling of the frontier models was, you know, delivering fewer returns and and, and, you know, at some point, at least for text, like, we were sort of arguably already out of data to train on. And so we're kind of moving to different, different approaches, basically. And I'm not an expert, you know, in this stuff, in the AI side of particular, but you sort of see the pattern of, like, what's happening. And, you know, it seems like what happened with deep seek is, if you take it at face value, you know, they took the constrained environment that they were in terms of GPUs and what have you, and money and and use that with some more intelligent approaches to, you know, to get to a kind of a good, similar outcome. Now, I think since the, like, the initial, you know, sort of press around. It was like, Oh, they only spent five and a half million training a model that's competitive with the with a model that costs 10 times as much, or, you know, 100 times as much, potentially. But it seems now that, like, it's likely they actually that was just like the final kind of the final run, the inference cost is low, so it is very cost effective to run. So is a genuine innovation, for sure, but it is also not clear how much actually got spent on the training, and it may have been quite a lot more than was initially reported, and potentially training on the output of OpenAI as well, which is, you know, doesn't change take away, like, the innovation. But I think the degree which it was a stark, you know, 100x reduction in cost is not so clear. And there's also, you know, some, some, I was just actually reading this morning rumor, admittedly, that, like, open AI has GPT five already, but they're just using it internally for training. And, you know, and that, like, there might be a change in the way that these frontier models get used, that they become, because they become so expensive to not only train but to run, that they probably won't necessarily be used, that's true, primarily for inference, will actually just be used to train and improve the smaller, more cost effective models. So we'll see about that again, with speculation. But there was, they were suggesting that that was something that's happening at anthropic and potentially open AI, and we did, in effect, you know, if the rumors about deep seek using open AI to train their models, then it's effectively the same thing in maybe a slightly illegal way, Adil Saleh 28:28 That can be a big, big problem in the in the Congress to which, which Facebook had in the past, and the Yeah, back touch, Paul Dudley 29:26 yeah. I mean, yeah, I think there's a few things there. I mean, the on the healthcare side, obviously people are, you know, as individuals, you know, they can go to, you know, just like they go to Google and, you know, ask Google medical questions. They can go to Open AI and ask the medical questions. I think in that context, you know, they're mainly like, the position that I think that the main, large sort of AI chat providers, let's say, are taking, is just like, hey, don't take this as medical advice, right? Although I've seen some anecdotes from people about like, the. Power of opening eyes, like deep research capabilities on looking at, you know, people doing their own research around like they have a, they have a, what do you call it, like a rare condition, or something like that, and they want to get, you know, look into the papers and stuff about it, and, you know, inform themselves. Have said really good things about it. But I think any like, any system that's being built explicitly for that purpose is going to have a much higher bar for accuracy. And yeah, I think that will inform having a different approach, right? You can't afford to have hallucinations in a in a purpose built healthcare. LLM right, but yeah, that's a bit out of my, out of my immediate purview. But one thing I will say, having talked to a few folks in that space, you know, I think their their approach is different, right? They're going to be running their llms, generally, in their own systems. So in fact, folks who are on Databricks, they're using the native like models that are available on Databricks. They're not going to be shipping that stuff off to an API, whether it's certainly not to deep seek in running on Chinese servers, and, you know, probably also not, you know, open AI on their servers, right? So, yeah, it's something that I think you'll you'll see a slightly different architectures in that context, and then maybe more than slightly different, and a lot more emphasis on accuracy. Because in some contexts, you know, 90% accuracy is totally fine, but you know, Adil Saleh 31:29 in some ways, yeah, I mean, I'm learning. I'm learning, yeah, I'm learning, listening to you, and, you know, revenues, information, because I'm not so familiar with this, the backstage of the AI, I'm just a user, regular consumer. I share the problems. Give them forms, custom chat, chat, gpts that I built. Have a co founder. We're building a B to B SAS product, and it's already there, got a handful of customers, working with the design partners and working with the you know, integration tools, like, you know, these developer tools to, you know, do the integrations, and, you know, data infrastructure using Amazon services for all the, you know, the cloud and the server. So, yeah, I mean, it's, you know, from the programming side, the engineering side, not sure how efficient it is, but for, for our side, like, for the marketing side, it's the chat GBT is working. Like, pretty okay, like, pretty, pretty good. And it's solving all the problems. And, you know, we're doing more with this, you know, optimizing the time. You know, previously I had, like, when I started this business as a product wise, you know, we had around seven people. Now we have like, three or four people, and they're doing more job, like more work. You know, all the KPIs after this release eight, nine months back. Oh, one, we're just cutting the time at 50% so they are now 50% faster. How big is your team? I know that sits around 10 to 15 people. Paul Dudley 32:58 Yeah, yeah, we're around 10 people. So, yeah, I think we've seen similar, like, I think we're, yeah, we're not like, we're using AI internally for, you know, I think help, helping our engineers, with, you know, with with their work, as well as, you know, augmenting our marketing as it sounds like you are. So, yeah, it's, it's something that we, we use in that sense. We haven't been using it. It's not in our product today. So one thing I kind of differentiate is, like, are you building it into production? Which I think there's not that much of yet, frankly, outside of, like, pure play, AI companies and then, and then, you know, are using it, like, internally to improve operations, which I think is the much more common use case that we see today, because it's pretty easy to deploy a co pilot or, you know, to just give people chat, GPT to answer questions, but, but yeah, like building something into your product is a very different bar, right? Adil Saleh 34:02 Yeah. I mean, it indicated I would take a time for your industry, maybe in a different shape or form, but it's not yet there, yeah, you know, for for developer tools. Okay, perfect. So now, of course, it's just the start, like first three years. I would say you're sitting between the first, you know, I would say three to four years of your business. So looking at the product, product might be a little bit closer than, you know, two, three years back. But how, like, Did you set any kind of operating principle like DNA? How does the culture look like it at stream camp as a team, I'm sure, like, it's in a startup. It's about, you know, you know, making sure you're good at everything you can be thrown by anything at your desk any day. So you got to make sure you saw the bronze house. How's your team working around and how's the culture? Paul Dudley 34:51 Yeah. So we we focus on a few key things. One is it's very customer centric. So just from like. A, you know, being very responsive, engaged with customers. That's one thing that we, we, you know, we built a great product. But as I mentioned, people run into little hiccups, and one of the things they really appreciate is, is our hands on approach. So like being very responsive to customers, and, you know, engaging them with the with folks who really, you know, are experts in the area and can truly help them is, is one key element on a certain related note, like providing a ton of value with our product. So, you know, one of the things that we we, you know, we think we could probably, because we do something, you know, we're faster than vegetables, like we could, we could charge more than them. But what we focused on is like, look, we don't have to. We can have good margins, be less expensive than batch competitors, and then we're just, like, incredibly compelling value proposition, right? So rather than try and extract, like, the maximum amount of money from our customers, better to, like, have a good business and, you know, just be incredible retention is very good as a result of that. So, like, our focus is on, like, how can we be hugely outsized value? That makes it a kind of no brainer, both to sign up for us, as well as to, you know, stay on board and and then, you know, very much like, we have our vision for the product, which, you know, guides our overall direction. But you know, we're also very responsive to to customers and, you know, looking at like, where do we need to go next? Right? Like, I think you have to balance, like I said, like a longer arc vision, and definitely don't want to just build every feature that your customers asked for. But, you know, being able to hear from them, actually. This goes back to what we talked about earlier, in terms of the problem, right? Like, you know, if you just take the first level of like, a feature request from a customer, that you can get into trouble. But if you if you are listening to your customer, trying to understand, like, what are they trying to achieve, what's problem they're solving, you know, then you can kind of decompose that into what are the core problems you see across your customer base, and then, you know, use that to inform your product strategy. And, you know, make sure you're building the right things, and you know, aligning to both their immediate needs and where you see things going in the future. Adil Saleh 37:05 Yeah, yeah. And how big of a problem it is to enable your team to be more custom, right? Like, I would say, just like you mentioned, of course, a lot of these engineers, they are, wanted to build the product feature, and they want, they're really good at it, but looking at from a lens of how customer wants to solve the problem and from the business outcome or business impact of that feature, are you doing some sort of like training, or how you guys are investing In I mean, generally, like, of course, their communication is something that, Paul Dudley 37:44 yeah, I mean, there's an interface between, like, our engineers are interacting directly with customers, and so they're getting requests directly. But, you know, we also then, I mean, something's like, okay, there's bug fix, then you just fix the bug, right? But like, you know, if there's product new features, that's something we, you know, we collaborate with, and it becomes part of our, our product discussion. So, you know, if we, if we need to, we can go back to them and kind of, you know, say, like, Hey, here's the, I mean, we had a customer the other day request like, Oh, can we get, you know, log output from your system to Datadog so we can monitor things. And we do already have alerting and things like that. And, you know, on the surface, like, we had some internal discussions, like, what we could do, and then we talked to the customer, we say, Okay, well, yes, we could give you all the logs if you wanted, but that would be a bad experience for you, because it's a lot of data, and the logs themselves are like, the amount of useful data within those logs is small. And so you know, what we actually ended up coming back to is like, actually, our existing alerting feature gave them the information they needed, and the thing that they didn't realize was that we had another mechanism that could send that directly to the system that needed it. And so basically, we didn't have to build anything new. It was just like, hey, actually, just use this mechanism to get that data into that system and then into Datadog, and, you know, the problem is solved. So, yeah, it's definitely really important to have those, those conversations with customer about, like, what? What's the end goal, and not just say, like, okay, hey, this customer needs this, and we're gonna go build it. But yeah, I guess there hasn't been an explicit training for engineers? It's more like, you know, we're small enough, and you know, if it's a meaningful feature, we're discussing it anyway. And then, you know, that includes both internal and customer discussions. Adil Saleh 39:32 Perfect. And before I said You three, I just wanted to ask two questions. One is, one is, what is the of course, you're looking at your roadmap every three months for all the major features and enhancements that you will what is, what is that makes you excited about the product? It could be featured, could be some new initiative you guys are taking, maybe internally as team. What is that going into 2025 you know that makes you excited product wise. Yeah, Paul Dudley 40:00 so, I mean, just this is not necessarily new feature, but we've been we, we launched a bring your own cloud deployment last year, which is like, in that context, we're not actually operating as a SaaS, or at least we're only personally like, the data that the customer is sending never leaves their environment, and that we've seen a ton of uptake for late last year and early this year. And so that's kind of a new architecture, to a certain extent. And so that's been really exciting. It's opened up more enterprise customers for us, and it makes those conversations a lot easier, because it's not like going off into somebody else's environment. The data stays, stay in their environment. Another big focus for us is doing transformations. So most of our customers today are just using us to move data from A to B without changing anything, just kind of replicate it as is. But there are tons of use cases where you want to be able to, you know, change the structure of the data on the fly, so you might be joining up two different sources of data, or you might be making sure that it fits into the structure of the destination. And so we've been doing that for a year or so in beta with customers that are that'll be coming out as a self serve functionality here in the next couple of weeks. And we expect that to open up a big new surface area for people to use us, right? So I think we do a great job with our kind of core initial use case, but that opens up people to do more. You do more with our platform. Oh, Adil Saleh 41:32 this sounds interesting like for us to be very honest, we wanted to make sure the data is in such model that whatever integration that we do with Salesforce, HubSpot and all the CRMs, all the chat tools, all the billing tools. We do it like turnkey. And we took, like, three months to, you know, make sure we structure that data and form up tables and whatever you have, like, you know, I'm not that technical, but again, to pass that data from the warehouse to tools like Mixpanel for product team, you know, and then to segment, you know, pipe it to, you know, CRM and other teams. It becomes so easier, as you mentioned, you know, that three months, four months of work, and make that data model compatible for for the destination or platforms like segment, to pipe that data across different other tech stack. It becomes super essential, and it becomes quite a work. I've seen that work in my product team, and, you know, the CTO, my friend as well, working really hard to, you know, make sure that data is well structured. And, you know, and you're saying that it, you that once you're done like it can automatically stream it across different platforms or based on the destination, and it automatically structures. This, the structure, sorry, structure the same data model that you had. You don't have to redo it, or, you know, to be able to pass to stream shrink at Paul Dudley 43:00 Not, not necessarily, but basically what it means is, like, you, I'm sorry if this Adil Saleh 43:05 is a dumb No, Paul Dudley 43:06 no, it's not a bad question. It's just there's a different like that is fundamentally the kind of thing that you could do with this functionality. Like, as in, we could say, like, Hey, here's a template for, like, how to transform data into a HubSpot input format. But that's not the first stage, and I'm not sure if we'll build outputs to HubSpot, but maybe a little more technical than it's worth getting into for your audience, but basically just it means that you can, you can do that kind of thing. So I guess the thing we wouldn't necessarily have right away, would be automated formatting into a the format of a specific destination, but more so just the ability to do that transformation on the fly. And things operate a little differently. Like, if you're sending it to HubSpot or Salesforce, like there's a very strict set of requirements that you have to meet, or otherwise it's not going to work. Whereas, like sending it between two different databases, it's it's a little more fluid. But, but there are things that you can do that are that sometimes are a requirement for things to work, and then other times just is more efficient to do it in the stream versus waiting to land it in the destination. So there's some differences in the way that, like sending data to snowflake works, versus sending data to HubSpot, it's a lot more open and less constrained. But there are still some advantages to doing the transformation in the stream. Adil Saleh 44:31 And as an ETL platform, it is essential for you to have it real time. Like like populated in the real time. Paul Dudley 44:38 Yes. So that's one advantage that we offer is like, you know, our systems are sub second, and so it just gives people the opportunity to move things a lot faster. Not all use cases that our customers are doing have a strict requirement for real time, but because they don't necessarily want to take out all of their infrastructure, so they might be using snowflake already. And self like is not a real time system, but they're probably using, let's say, five Tran for their data ingestion. And fivetran is pretty slow, so if they replace fivetran with us, they don't make any other changes, and all of a sudden they've taken 15 minutes of latency out of their system. So they're not necessarily real time, but maybe they go from a 30 minute end process to a to a one minute or two minute end to end process, and that's, you know, a big improvement. And maybe it's not where their end state is. They want to down the road. They could use something other than for than snowflake, for lower latency. But that means that, basically, with us, like a they reduce a lot of latency, be they're doing it at without changing a bunch of other stuff. And then also a future proof, right? If in the future, you know, snowflake gets faster, then all sudden, they're not constrained by us, right? Like we're always going to be, you know, kind of the, not the right limiting step based on our latency. Adil Saleh 46:39 yeah, perfect. Paul, it was real nice meeting you. I wish you good luck with all all these new features that you're working on and how you're making a difference, especially with the cost, you know, and I appreciate that you've been some one of the founders that is not, you know, trying to acquire customers for the sake of generating revenue. And, you know, I know that competitors are charging a lot more with, you know, not these action capabilities that you have, and you're still trying to make sure that you cut down the, not, not just the price points. I've been looking at the price point pretty straightforward, pretty clean, you know. And of course, it is user base. But again, at the end of the day, you had the chance to, you know, charge them more what you did, so it takes a lot of lot of courage, and a lot of you know, a lot of character. So I appreciate that. Paul Dudley 47:26 Yeah, yeah. My pleasure. Adil Saleh 47:29 Yeah. Thanks. Video, perfect, Paul. Have a good rest of the day. Was nice. Take Paul Dudley 47:35 care. Bye. Thank you.