I think most technical founders are just heavily underrating the amount of volume that you need to do, and I think you can really brute force at least your first 10 customers in this way and get that early momentum.

In this episode, I'm joined by Andy from DeepTrace, an AI built to identify and fix problems in production. In this episode, Andy explains how a bunch of YC engineers learned how to do sales. Enjoy. Yeah. So you weren't doing sales before.

You were an engineer at Tesla and SpaceX and now and your team doesn't have go to market people. You just have founders who are engineers and had never done it before, but have figured out how to build kind of a machine that gets new revenue. Right?

Exactly. Yeah. And especially, you know, early days. We were talking about this before Jack. I think like the thing that buyers are buying and people wanna buy from an early stage startup is not just the product.

Right? It's like the whole package of you and the product. And so, you know, early on we really to get our first handful of customers, one of our first customers was actually Opendoor, which is now they're making a comeback. It's a Fortune 1,000 company with multiple billions of revenue a year. And like the way that went down was we, you know, I outbounded, LinkedIn messaged thousands of people on LinkedIn just asking for mentorship.

And one guy decided, the CTO of Open Door, Shreesha, decided this kid seems scrappy, he seems hungry, why don't I get a coffee with him and hear his story? And that's, you know, that relationship blossomed into becoming one of our first customers. And so I think like the huge part that technical founders especially underrate is just the importance of you're really selling yourself and you're selling the team behind the product that you built.

I I think like I I don't know. I feel like there's sometimes this feeling that you don't you're not like good at sales if you're not kind of salesy or smooth and the kind of person who takes over the room. But actually, I felt like people aren't even looking for that at startups. I don't know if it's what you found. But if you're buying a product, you want someone knowledgeable about it.

Right? Yeah. Exactly. I don't know.

Exact and I think for DevTools especially like it is really great to be able to talk to an engineer. You know, I'm sure everyone who has procured DevTools at large companies has had to talk to inside sales and that's not a great experience. They really don't understand what your life is like as a developer. And so technical founders, I think, should really lean into that where they are kind of like the ones that built the product and and they're great middlers. Like, salespeople, I think, have kind of practiced the two ends of it, so, like, opening and closing.

But, like, everything in the middle, they're not really knowledgeable on. They can't speak to with the same kind of depth and rigor that a founder or someone technical, an engineer would be able to. And so I think that's like a superpower that technical founders have being able to die you know, go a mile deep on any details and just being extremely knowledgeable as you say is is like a a huge advantage to being a technical founder.

Yeah. And how did you get your so you mentioned the first very first customer, which sounds like a the kind of first customer that most of us could ever could only dream of. How did you go from that one to the next, say 10 customers?

Yeah. So Opendoor wasn't actually our first customer. Our very first customer was a stablecoin company, Rain, based in New York. And they I think they recently raised a a series c, so they're doing great. But, yeah, they were one of our first customers.

And basically, the the way that we got our first 10 customers was just through, like, raw volume of outbound. And I think especially as engineers who you're you're just used to like putting out PRs at your previous company and just you're you're measured on like the the quality of your your engineering output or the stuff that you build. Like, it's a very unnatural thing to think about a sales pipeline. But I think most technical founders are just heavily underrating the amount of volume that you need to do. And I would suggest like if you're new to it, like bumping it up a couple orders of magnitude.

So just to give you like a picture of what we're doing and what we did to get our first time customers through YC, for two whole months basically, everyone on our team maxed out all of our LinkedIn requests, connections, and sales navigator every week. And so that's I think that's around 250 per person that we were just, you know, 250 per person for a team of four per week. So we were doing a thousand just on LinkedIn. We were doing, you know, you can only imagine how many cold emails

Cold emails.

Saw. And yeah, just like I think you can really brute force at least your first 10 customers in this way, and get that early momentum to figure out, you know, what is the what are the next steps to to do once you have that early kind of kernel of value that you're delivering to just that first set of customers.

Do you think there's any tips and tricks that are actually worth knowing when doing that? Or is it just do you think just throw time and energy at it and

Yeah. So I think a big a big thing that's underrated is just like volume. So for sure I would say like anyone starting out, that's like the one thing I would recommend above all else is like, you really need to do a ton of volume. But then also I would say like you you want to, at least for us what we found to work really well is not just saying, I think it's, you know, many people will come in and ask for feedback and that's more effective than just pitching on the on the first LinkedIn message. But just being like genuinely sending messages out there that are genuinely curious in nature where you actually like are asking expert advice of the other person and putting yourself in a position where the other person feels like they have something to offer.

And I think that really starts the relationship and call off in a kind of way where it's not super transactional and both parties are getting to know each other in a way where you're not just, you know, pitching them on something to buy. So obviously, you know, I mentioned Opendoor. The way we got Opendoor as a customer was I was just, you know, genuinely asking for mentorship from CTOs of Fortune 1,000 customers. We weren't super familiar with the enterprise buying cycle or DevTool needs of these huge companies. And so I was genuinely looking for mentorship from someone like Tricia.

And so I I would kind of play into that angle, I think, is what I would recommend, at least what worked for us.

And so it obviously, so you're which we've mentioned, but you're the founder of DeepTrace AI instant response. What what kind of things would you be I mean, guess it would depend, but what kind of things would you be asking people?

Yeah. So think what a couple of things that we kind of try to ask our customers or ask people that we got on calls with were just general pain points around observability and debugging. And I think connecting on just like a war story and being able to draw out emotions in that call, where the other side, like, you know, every engineer who has worked at a job for a couple years just knows like just the visceral pain of being paid at like 3AM. So just connecting on connecting on those experiences I think was a huge thing for us. And then also, I think it's a very unique time where the role of an engineer is changing so rapidly with cogen and, you know, all the different dev tools that are being released week over week.

So, you know, being a YC startup and seeing like the the frontier edge of that, kind of connecting on that and discussing what the latest tools people are using, what kind of techniques people are using, think was another way that we really got our foot in the door in a way that wasn't just selling, selling, selling.

Interesting. Were you sending these one by one?

So we weren't sending them one by one, but we had kind of like personas. So the type of message that you might send to VP of engineering at a Fortune 500 would probably be a lot different than you know, what you would send to our champion at Mintlify, Nick Cammy. I don't know if you know him, but he's Oh, yeah. Big on Twitter.

I I follow him on Twitter.

Yeah. He's great. Yeah. Yeah. And so the kinda message that you can have kind of templates I think is useful or different personas and things that you might send to different kinds of people.

But we were not handwriting every every message. And I think honestly to get to like the thousands of messages a week kind of scale, it's really hard to really personalize every message. Although there's a different school of thought where some people will suggest doing hyper personalized messages. In our experience, that did not yield as much as just pure volume. But, you know, there is a different school of thought there that I I recognize has worked for some people.

When you have kind of personas, are you literally kind of using an old school, like mail merge template where it's like, maybe you put, you know, company name is changing, but it's broadly the same message. Or are you still using LLMs to kind of tailor it or is it like

So we we don't use large language models. We actually just hand wrote like a set of templates. And and I recommend anyone that's going through this exercise should go through this kind of exercise where they think about like what is like the the really the value proposition of the product I'm offering. And I'm going through like, okay, here are the personas that I'm gonna hit up, and here is what they are gonna like like, let me truly put myself in their shoes for a moment and think about what they care about with respect to the value proposition or the product I'm offering. And so we all got together, you know, one day before YC when we were starting the company and wrote out like, you know, a five to 10 page Google doc about the the different kinds of personas that would resonate with our product and why they would resonate and in what different ways they would resonate.

And then hand tailored a set of crafted LinkedIn messages for those personas.

Yeah. I think that's brilliant. I I and I feel like people don't do this. I don't know if it's just if my inbox is representative, but, you know, the things I get messaged about is always, you know, like podcast related stuff. And like 99% of messages I receive are like, I love your podcast.

I love the episode. And then it's just an obviously generated, LLM generated like bunch of nonsense about yeah. That just like makes no sense of just like you obviously like there's there's no well way in the world I believe that you've said this. And so I think that like an actual targeted one which was like actually addressing my pain points would just work so much better because it's like, even if I don't think it's sent just to me, I don't care. It's like this person actually gets what the challenges of, I don't know, someone with a podcast has.

It's like so much better than trying to just come up with this super because everyone everyone's so fluent anyway with the l l what the LLNs produce. Like, they know when it's just like Exactly. Most of the time. I don't know. Mean, maybe Scott, maybe

I it's interesting because honestly I think like writing and truly like creative, valuable writing and outbound is one of those forums I think is one of the last things that language models will be able to do well, which is a very interesting observation. And perhaps it has to do with just the fact that these are kind of tasks that require some kind of taste are like not super verifiable. And yeah, I think there's a huge amount of alpha still in just being, you know, standing out as like a real person in your outbound and emails. And you'd be surprised. I mean, I think a lot of founders at the beginning have a perception that when they're not getting responses on LinkedIn or email that their message is not even being read.

Where I think like, even like, you know, CEO, CTOs of Fortune 500 companies, they're reading every message at least in their email. There's a high chance that your message is being read. So really, it's just the bar of the quality of that writing needs to be human and speak to that person.

Yeah. Do you have any I mean, this is almost a stupid question, but I'm gonna ask you anyway. If I'm coming to you and I'm like, I'm sending 250 LinkedIn messages in mails a week, say, or like, I guess that that would be combined connection plus InMail, I would imagine two fifty.

Right? Exactly. Yeah.

And I'm getting five responses, you know, where people are at least like, tell me more. How you know, do you have any kind of gauge on orders of magnitude of what is decent at least from I know it's specific to you, but at least like what you might aim for.

Yeah. So that's a great question. I and I think, again, it's like very context dependent. A company that, you know, a compliance company that is selling to startups that just got into YC maybe, you you might expect a much higher take up on that versus like selling to enterprise buyers where the contract size will be like millions of dollars, there might be a much lower hit rate on that. So I think it's all very context dependent.

For us, what we found is like we were able to get on every 100 LinkedIn messages sent out, we were able to get at least you know, 40 people that would accept the connection. And then of those around half to 75% were responding in some way. Not to say that they all converted, but like that kind of high connection rate is what you should be able what you should be able to see on like, you know, 40% at least on LinkedIn especially where, you know, there's less noise compared to email is what I would say you should ballpark around. And then one thing I'll say in terms of if you're building a product that you're very confident is delivering some value. So in our case, AI incident response, we're very confident that this is something that is delivering real value if we can execute on it.

So for this type of product, I would say like that the core thing that you wanna iterate on is the type of person that you're you are reaching out to. And I think generally, you know, in AI dev tools, there's so much value that is being produced that and so much product overhang that you should be relatively confident in the thing that you're delivering. You should be relatively confident for most products that you are delivering some kind of value. So I would really focus on like getting to the right people. People.

And before anything else I would try to root cause that. Am I talking to the right people if I'm only getting a couple hits a week? And for us a surprising intuition that we had on that, developed on that, it was that actually younger people, regardless of what stage of company or regardless of what role, younger people were just much better able to grok the value of DeepTrace. Because I think they have, they're more AI native. They had more experiences with similar tools.

And so that's just like there are all these kind of things that you need to build an intuition around, and it's just a process. It's just kind of an iteration process.

That's so funny. I hadn't even considered that. That's I I think that can be something that everyone listening should think about, to be honest, with AI stuff. That's so interesting. Wow.

I feel like maybe maybe I'm gonna, like, start replying to more emails just to feel less old. And so how do you think about who to target? Because, I mean, especially when you're starting and you're like, it's basically a new category when you you were starting out. Would you say I mean

Yeah. I I think you start with a hypothesis. And, again it goes back to the creating that document where you really go through the exercise of like what is the value prop? Who are the personas I wanna target? And then from there, the same way that you know, I think we as engineers applied a really engineering heavy mindset to it, or a kind of way of thinking about the problem where we would have these cohorts that we would test.

So we would test personas A, B, and C, see which ones perform better. And then think about why is this persona performing better than the other. And then you start to run these experiments. And it doesn't have to be such a formal thing, but I think applying some kind of engineering mindset to it can deliver can surface these like really interesting insights like what I mentioned where we were noticing like, actually it looks like we are having a lot of success going bottoms up rather than top top down at some of these companies. And we started to think, you know, what what's going on in these calls, reviewing the calls.

And it started to become clear like it's because these young people are the ones that have the most experience with AI tools and they speak about their experience and how bought in they are to the other tools that they use. So it's just kinda like I think in in any like applying that engineering mindset and iterating your way through to find the right persona.

Yeah. And have you have you found, you know, I guess is it you sort of maybe touching on like champions. Is it like a is that like a thing that you guys are thinking a lot about at like, especially these bigger companies?

Yeah. So a a big part of it is you wanna find someone that is at the right level. So you wanna find someone that is, you know, senior enough that they hold weight and they're able to get the deal through if they want to, but also that they have enough context that they see the value at a very visceral level, especially for our product. So, you know, there is all these levels in a company. Probably for most products, you know, there's there's a whole set of enterprise products that you might wanna sell to the CTO.

But most products, they're the person that is gonna see the real value in that at a visceral level is gonna be closer to, you know, maybe the VP of engineering for a DevTool, maybe even an engineering manager or maybe even IC. And so just for your product, finding the right level of abstraction within the company is like I think that's the core skill when thinking about who should be your champion and how you should think about going through that.

Yeah. And then is that, you know, if it's about you figured out what the right level is, have you found things that you can like filter people on? Because when you're staring at, you know, you're staring at your LinkedIn feed, got the search bar, you start to whack in some filters. How are you finding the right people? Because presumably it's not just engineer and, you know, look at their profile pictures, see if they seem like they're quite under the age or whatever.

Like, you know? Yeah. Like how are you?

Yeah. Yeah. So what you know, there's all the basic things that I think a lot of people understand where it's like the longer this person has been at the company perhaps, the more weight they're able to throw around. Like you don't wanna talk to someone that is really new, at least at an IC level, and is not able to get your deal through, or it just doesn't have the say. So that's, you know, there's all those basic things that you might think about through a traditional sales process.

But also I think one thing that we think is kind of interesting is like, is this person kind of like a rebel? Like do they they the type of person they don't like process? Because process like this kills startups. Like if we have to go through a 10 step procurement process where we're gonna get buy in from you know, security and IT and like four other stakeholders, this is like the death, this is death for us. Yeah.

So obviously, you know, Nick Cammie on Twitter obviously seems like kind of a funny guy, a rebel himself. Like you've looked at some of his tweets.

Oh, yeah.

Yeah. And so, yeah. This kind of persona I think is something that we found to be interesting is like personality type, if you can extract this from their online presence is gonna be something that for us really, really worked and was a lot higher hit rate than just, as you say, just like messaging a bunch of engineers.

Yeah. But I I feel like, you know, Nick Nick from Minniflies don't grow on trees. You know, there's not there's not gazillions. And when I whenever I've done Cold Outbound, I always found it's quite hard to because most people just don't have very much online of their, you know, their presence. Or I guess you're just trying to saturate first the people that do that you can figure that out about.

Yeah. So that's a good point which is that while there may not be a ton of them, they certainly stand out. And so there's a selection effect there where you can really go after those people first. I mean there's ways that you can kind of glean this just from their background. Like we have, you know, in our search and selection criteria, we really prioritize and try to reach out to people that have worked in startup settings before regardless of whatever role they are currently.

Yeah. And that, you know, that I think is indicative of a certain type of person that wants to get stuff done, wants to try out new tooling and do things a better and like newer way. And so, yeah, there's there's I think there's more signals than one might expect. And all the tools out there like Clay and Paradigm, I'm not sure if you're familiar, are very helpful in that process. Oh, so yeah, Paradigm is a, it's basically like a AI spreadsheet.

And so we use it for hydrating information about basically people that we're doing outbound to, and doing selection criteria. So it's a really great product. I would recommend anyone watching check it out. It's kind of like you have a spreadsheet and then it comes with an analyst. And you can basically set a column or something and say, you know, whatever this person is, hydrate the LinkedIn or hydrate the the places they've worked before.

Say, you know, determine if they've worked at a startup and it puts it all in spreadsheet form.

That's so cool. Because that was gonna be my next question was, can you filter this is this obviously, I've done I I did outbound before AI stuff. So it's like all my questions are like, is there a filter on Sales Nav for worked at startup? Like, can you do like, because I'm guessing you maybe can't. Because I feel like it's always like current company, but you I don't know.

I don't remember that being like, have they ever worked at a start company with less than 10 people? And even then it would be that, you know, they could have joined when they were really small. That the startup the company now is massive. But yeah, it sounds like you can do it with Paradigm.

Yeah. With Paradigm or, you know, we One interesting thing that I'll share is like And we're all technical. Right? And we're all engineers. And so it's With tools like Cloud Code it's incredible to be able to just, you know If you have a sales idea that you want to run or some kind of some prompt that you just wanna test out, it's just like a couple prompts away.

And so one thing that we do is we have access we bought the x API. We have access to the x API. And we basically built an internal tool with Cloud Code that will scrape the x or certain certain x feeds and look for people that are complaining about incident response or complaining about complaining about downtime, complaining about, you know, oh, my next on call shift. And that's actually how we first, you know, got in touch with Mintlify is our our ex internal ex tool, Notify. They were going through a monster migration and the engineers were anxious.

So

Oh. I

think it's it's really it's really powerful when you have engineers combined with Claude code that think about sales in this kind of engineering way.

That's so cool. Yeah. This is amazing, man, by the way. Just jumping in to say this is extremely helpful. Think you're you're for being yeah.

Hopefully, people listening find this helpful too. And actually, something you told me when we spoke before, which I thought was amazing, is you've been doing the most, like, engineering approach to paid ads, which I'm always, like, surprised when people use paid ads at all in DevTools. But you've been doing some interesting stuff. Right?

Yeah. Yeah. So I guess we like similar to you, I guess, as engineers, like we're just, I think inherently kind of skeptical of paid ads. But there there's a company Numeral, another YC company. They, you know Numeral.

Numeral. Yeah. Like the sales tax company. They they've done just fantastic with paid ads. And the founder, Sam Ross, talks a lot about that on, you know, he's gone on various podcasts and whatnot and spoken at length about how valuable paid ads can be if done right.

And just from like kind of taking a step back, like paid ads is really just kind of like a numbers game at the end of it. And you wanna optimize the numbers game. And it's kind of a ground game where you just wanna get in front of people that could be relevant. And to that end, you normally would have to test a bunch of copy and AB test a bunch of copy and see what resonates, what does better, what performs better. And so we thought, you know, as engineers, we could make our our ad copy into SVGs.

So basically code. And this way using Cloud Code, we could just spin up dozens and dozens of different copy to test every week and see which ones perform better. And it's you know, a channel that's new for us that we're playing around with. It is very early days in experimenting, but we're seeing a lot of promising results from it. And it's something that I think is just really cool and great that when you apply One of the thing great things that can happen when you apply an engineering mindset to sales, basically.

Yeah. That's that's just yeah. So interesting. Does it go like really wacky or is it all quite kind of twist on the theme?

It's it's not perfect with the SVGs. What the main thing that we will that I think it's good at testing out is kind of like just like the copy of the the text itself and then different formatting or coloring schemes, which if you, you know, if you have trusted or tried performance marketing as a as a channel is like actually really important. I will say, like, in terms of just editing the SVG itself, it's not super great at that. So we generally we built a skill for Claude Claude Claude where we kind of steer it away from that direction. It will generate some funky SVGs if you ask it to do the SVG from scratch.

But there's actually a company called Quiverr I think that is doing some great work on this where they I think basically train their own models to do prompt to SVG and it and the the early results look really good as well. So there there's a lot of a lot of I think it's a early an early channel and an early way an early way to do performance marketing that I can't see it in five to ten years will will not be like the way of doing it.

So everything would just be yeah. Just super dynamic and yeah. Well tested. Yeah. That'll be interesting.

Be fun if you get like the the random first experiments like everyone does. Just some absolutely batshit stuff just being tested and thrown out. But yeah. That's incredible. Okay.

Cool. And then okay. One thing I also wanted to ask you about because I have maybe experienced some interesting sales calls recently from a buyer's perspective. And I've seen that this is not a universally understood thing of how to actually do a sales call. So I'd love to hear about how you approach calls when you get you've been doing your volume, you've been getting calls, you get on the phone with someone for the first call.

How how are you approaching it?

Yeah. So I think really as a Especially in the zero to one phase as a You know doing early founder sales, you really need to sell them on yourself. And so I would not start You know, I I think it's great to do traditional discovery questions related to pain point and all of those things. But I would just start by just talking about yourself, who you are, selling who you are as a person, and connecting with the other person just on a non transactional basis. So the way I would normally we don't necessarily do this at this point that much anymore, but certainly for the first, you know, five ish, 10 ish customers, most of my initial calls I was just kind of starting out by introducing myself, you know, saying telling the other person about where I grew up, like why I decided to start this company, and just a a bit about myself and the team.

And I think there's there's all you know, when you're talking with developers as a developer yourself, there's always there's always stuff in your in your past that to talk about whether it's, you know, different technologies that you guys geek out on or whatever that might be. I think connecting with the other person at the beginning on that interpersonal basis, at the very beginning especially is really important.

Yeah. And how about, you know I mean, when it comes to showing your product, what how do you tend to do that?

Yeah. So at the beginning, we kind of sold much ahead of where the product was.

Oh, And

I think you know, I've heard from friends that work at you know, Scaling Palantir that Palantir has really figured out how to do this well, where it's like you just wanna build out a demo that wow is the buyer and that's the only thing that matters. Like even if you just mock it out ahead of time, it's like not even real. Building out like a great demo I would really invest heavily in. But at the beginning, if you're a YC company with less than 1,000,000 in ARR, like I'm not sure that I'm not sure how much that even really matters. Like I would It does matter, but I would really like again emphasize and heavily lean into just the relationship aspect of it and driving that as like the main thing.

Like you're you're buying you're buying a team that's gonna do work for you basically. And that's the mental model I would have around getting things off the ground if you're less than 1,000,000 in ARR.

Interesting. So then what so then what if they're like, can you show us the so if they say to you, oh, can we see a demo? What do you

We'd show we'd show the demo that we had and we there would be, you know, semi obvious feature gaps, but we would, you know, sell towards what it could be. And I think the right person that you have the right relationship with and who you've like connected within that call will and has the pain point obviously, will understand like that they're buying a team that is driving to a certain vision or a certain outcome that might take, you know, three months, four months, five months, but that they see a potential in you as a team to deliver on that vision over time. So obviously we our product at the very beginning was basically just the Slack bot. But we kind of like initially started the call not as selling a Slack bot, but as selling this automated way of running production. When the buyer buys into that vision, it it really just becomes then about, you know, is this is this a team that I can rely on to help take me there?

Interesting. So I guess this goes back to picking the right person and go after someone that's very I mean, these are like innovate innovate innovators. Right? Like all I can't remember. I always get the two confused.

Like early adopters, innovators. These are the people that are like open to taking a chance on like that they're not they don't think this thing exists. Right? They're like, they know that you're in the process of building it and they're just trusting that you're you care about their problem and you're smart people.

Yeah. Exactly. And I mean, to your point, you I think you do need to show like a kernel of value to begin with. Like it can't just be like Fugazi or Fugazi Fugazi. I I think like it can be a relatively bare bones product if they if they see that initial kernel of value and see where it what it could become.

Yeah. Yeah. That's really cool. Okay. And then I have one more question on the calls.

And again it's top of mind. But when people say how does pricing work? How do you tend to approach that?

Yeah. So at the very beginning, was a tricky conversation because we ourselves had not figured out the best way to do pricing. I do think like just as a general trend, software will almost inevitably move to more and DevTools especially will move towards basically like just usage as a as the way to do pricing. I think we you just have to have thought through like what you wanna say and convey it in a way that's understandable to the to the other person. I don't think necessarily there's any wrong way of doing it.

Just that it's very clear and and very transparent what what the the pricing model is. For us that looks like a a flat SaaS fee for a certain amount of usage and then overages on top of that. And yeah. Yeah. I think there there's nothing too crazy that I would say on this other than it's really important to be transparent obviously, especially for developers who I think really wanna see transparency on that compared to some other verticals like sales or marketing.

Yeah. Yeah. Do you let people do trials and kind of try things out and stuff?

Yeah. We we we do do trials and typically we Especially at It's because of how early stage we are. Like it We understand there's a lot of risk involved in going with a Trying out a startup. We do trials and we typically do a nominal amount of upfront. So it's not like nothing compared to like the the true contract if it would convert.

But normally we will charge somewhat, we will charge like a very nominal amount, maybe five to 10% of what the the true month to month or yearly annual price would be. Just for that prorated trial period, whether it's two weeks or four weeks or whatever. And we I think for certain products, it is important to get a bit of buy in from the other person where it's like they're not just trying it out. But for a product where there is like a necessary onboarding period or some kind of change management that has to happen, I think it's important to have a little bit of buy in and and getting that nominal trial price can really help on that.

Because then you're just filtering people.

Exactly. Yeah. And and well, not not even necessarily filtering. Just like I think the psychology of like we we put some money into this even if it's like just pretty nominal is like makes them more invested, changes behavior. And I think personally, we've seen that be more successful in converting pilots.

That's super, super interesting. Yeah. Okay. One I also wanna ask you about DevTrace. So probably I mean, everyone wants to not be scared of incidents and stuff.

You know, how how you guys how does it work? DeepTrace.

Yeah. So DeepTrace is, you know, more broadly a a reliability platform that does reactive things like helps you fix incidents, helps you root cause incidents and debug, but also proactive. And it proact we have a set of tools that proactively monitor your system, watch out for customers that might be smaller that you're not getting alerted on, and proactively brings issues to you in Slack and in our web interface that helps people understand what's going on in production and how to fix issues in production. And yeah, so we kind of, my co founder worked at a startup where he was on call for a banking and card product that he launched and was basically getting four hours of sleep a night for a whole month, just getting paged every night basically, which is obviously a terrifying thing and a terrifying experience. And I had kinda seen the problem from a more big tech perspective at Tesla where I was on the autopilot and optimist team.

And there were when things would break, it seemed kind of odd that maybe there was only like one or two people in the whole company of, you know, thousands of engineers that were able to to truly debug it. And I saw it was a very fragile system. And so we saw it from both of these different perspectives and just wanted to tackle this kind of hole in the developer life cycle where code was getting so great, but the messiness of, you know, what is your software doing in the real world was was something that was relatively untouched.

Yeah. I I wanna ask the question just that I feel like most people will have as the kind of the objection I imagine people will have. It's like, okay, but I have, you know, all the l l l l m's in the world. I have the code. I can see the logs in Sentry and stuff.

Why can't I just, you know, what's the difference between just slamming all this stuff into Claude code and you know, what's the special source?

That's a great question. So there's we kind of view our role in the whole in the whole thing in two to three ways that I'll lay out here. And you know, just as an aside, all of our customers basically act very actively use Cloud Code and had been trying these kind of workflows where you might copy paste the Sentry issue or whatnot. The the main things that I would say that differentiate us from that kind of solution are, one, I think we have already built like great integrations for all the different sources of data that might be relevant. So, you know, you might use Sentry, but you also might have a bunch of logs in Clickhouse or Datadog or you know, Grafana.

And then you also might have runbooks in Notion. You might have metrics sitting in a different platform. You might have data in Vercel. So And there's all these different places that your data sits that it's where it's useful to have great connectors to all of them in one centralized place. The second thing is we do a lot of work around getting the right context in the right place at the right time.

And so you can imagine like the best staff, software engineer, the best on call person that you might know or have ever worked with at some company. If you plop them in a different company on day one, they're not gonna be super useful in an on call setting. And the reason for that is all of the context that they might be missing. And so we have developed this set of agents that will go on in the background, do deep research on your system, create documentation, and are scanning all of your different systems. So they're scanning every deploy, understanding, you know, how is the code base changed in this way, what are the expected effects.

They're looking at every Slack message that you send in Slack, whether it's someone on an alert saying, you know, this is a false alarm. We're sending research agents that take a look at, okay, why is this a false alarm? What what is expected in this case? What is the baseline, for example? And creating this deep, you know, rich workspace and memory around all the different ways that people are debugging and all the ways that your living system is evolving.

So that's the second thing. And then I guess the last thing is just there is a lot of work I believe. So the coding agents have gotten incredible. And I think in a year's time like it's it's almost like in the seventies and eighties where you had, people would read the assembly that came out of the compilers from C to assembly. And you would verify that it looked right and everything.

And then at a certain point, the compilers just got so good that nobody was even reading assembly. And I think in a year's time, we're gonna be at that point with Codegen, and we're even reaching that point right now, where you'll just trust what the agent does under the hood. And so, in that world, are still We believe that there are still forms of data that the agents will not be super great at. So for example, time series data. Anomaly detection on different metrics in your system.

These are things that even humans are not super great at. And we are using a bunch of, you know, more traditional machine learning techniques and statistical methods to understand what is out of the norm and interpolate the time series data into things that the model can understand. And basically chunk it up in ways that are understandable to an LLN. And you can imagine all the kinds of data. You know, we have customers that use post hoc session replay.

There's so many kinds of data that need to be basically processed in a way that is understandable for the large language models out of the box. And that's where a lot of our value sits as well. So those are kind of the ways that I think about why customers choose to choose to go with DevTools instead of hacking together internally or just using Cloud Code.

Yeah. I'm convinced. That sounds great. Amazing. Yeah.

Andy, this has been, from my perspective, incredibly helpful. I've really enjoyed it and I've really appreciated that you're, like, extremely transparent on this stuff. It's it kinda feels like you're talking about an in engineering problem where it's like just just building a sales pipeline as if you're building a AI SRE tool. My advice. Super interested.

It

was a great it was a great time. And, yeah, I guess I it it's really fun to be able to apply an engineering mindset to everything in this world. And that's that's one of the great things about being, you know, a technical team and taking on all problems with this kind of mindset.

Amazing. Where can people learn more about you and about DevTools?

Yeah. Absolutely. Feel free to, you know, follow us on LinkedIn or Twitter on at DeepTrace AI and find us at deeptrace.com where you can book a demo or get in touch with us on there.

Amazing. Well, thanks, Andy, and thanks everyone for listening.

Thanks, Jack.