How Private Equity Is Rethinking AI & Tech Due Diligence (According to Code & Co.)

Value creation is the most overused word in private equity. Because as private equity people, we go and we got operating partners will value create the hell out of this thing. Right. It's not right. It is really that level. It's understanding there's always room to improve business. Yes. It's not venture capital. It's private equity. It's the private equity fund. Cast, pour yourself a drink and have a seat. Hello, Funcast fans. We are back with some old friends of the firm to talk about tech diligence, especially in the age of AI. Our longtime due diligence partners, Code and Co, Dan Lucas and the newest member of the team, Kirby. Welcome. Before we get started today, I do want to give you a little surprise here. This is the first email that introduced you to me from cczag. The original email. That's so sweet. I think there's an interesting company on here that we didn't call on the reference sheet. Let's take a look. Oh, this is how I met Code and company right here. Cor Seller capital. There you go. You guys had me. You should have called the reference Joshi. We didn't call all the references right. Amazing. Thank you so much. Oh, you're so welcome. It's been such a great relationship. So let's talk about how you guys, we know you. How did you get started in. In doing this business? How did. How did you two meet? How did you decide we want to be in the due diligence business for private equity firms? Because that's a very specific thing. So. Yeah, I mean, Dan and I, we've been friends for a long time. We actually had our own respective startups. Like, is it like a spinal Tap? Like you met when you were five years old and you're singing the. You know, you get the song, you sing and we're like early 20s, not in the 5. 19, early 20s. 20s. Berlin startup guys meeting. Meeting at a venture capitalist office we both pitched at with two different companies and startups. Do you both get invested? I mean. Yeah, both got invested and both failed miserably with the companies. Yeah, yeah, you got to have one. You got to have one in your. It's the first one. Indeed. But then also, I think this is one of the reasons we decided that eventually then when we founded Code and Co, we didn't want to take any external capital. It was like one of the core reasons. Right. That we wanted to. To really build. Yeah, you should never take capital ourselves. Private ending fund. Just wait until you want to sell the whole thing. Yeah, we don't need to deal with that. So that was actually for us was a really good learning and then so yeah, in between the startups failing and then funding could and co we did a lot of different things. So for instance I work as a software developer at ThoughtWorks. Dan, he was a director of product at Rocket Internet in Berlin. But then yeah, we were ready to do something together but we weren't really sure what we wanted to do so we just started working together and given that we're both developers, we had something that we could capitalize on being our development work. Right. So in the beginning started doing some dev work. We for instance built a large mobile app and sold it to vw which was amazing because this was our funding from the get go and a good company to fund. I'm a big VW man. They have some problems right now but for Germany, I hope this, this is going to get sorted. Well, my college suite mate Mark McNab, he negotiated the settlement with the United States on behalf of Volkswagen. Oh wow. He was the CEO. Yeah. Oh yeah. Longtime prospect. Now all of this behind us, the newest member of the team. So how'd you guys meet Kirby? And how'd you, how did you rope him in to being part of the code and go team? I mean we've been super fortunate to do this for a long time. Right. Found it in 2016. We've done hundreds of DD's last year just to quantify this a bit. Last year we did probably like 200 DD's this year we hope to double it, knock on wood and stuff. And we've been super privileged to work across sectors GEOS industries. We've been serving people like you for a long time across the globe. Exactly. But time zones do exist, let me tell you. And so after a full day of work in Europe we have offices in Berlin, in London, in Paris. But after a full day of work, Paris, Munich, everybody talk about music. There you go. Half the people have no idea Shazam came even pick that song up anymore. So you know, after a full day of work, time zones do exist. The say the excitement to join a workshop for west coast deal at like midnight or 2am in the morning is you know, less than stellar. And as such we wanted for a long time have a dedicated team in the US and we're super fortunate to find Kirby at a dd. But you can tell the story yourself. It's, it's one of the points here in, in, in 2020 and we now have an office in New York, a team and we're Excited? Who are you? Kirby? So, I mean, overall, it's funny to see this email because Code and company always includes their case studies. And I'm seeing this deal right here. It was Corsair Capital, Kansas City. I was leading product at a fintech company, and these two German guys walk in to do this thing called due diligence. It was my first experience with it and I thought it was so fascinating. So as we went through the product and I was talking about all the things I was so passionate about there, it was cool to see, like, this is this guy's job. They get to come, they get to listen, they get to ask questions. I didn't know at the time that they were also being detectives, trying to figure out where the skeletons were and things like that. Because, you know, in the workshop, you don't feel that vibe if it's going right. But after that, the whole point, I know it worked on me. We don't want you to see it coming. The pixie dust. I was like, oh, of course. I'd love to show you what's in the closet over here, you know. But the. The reality was is that after that I had followed up with them, we stayed in contact. I had startup that got acquired by as an add on from K1. And after that there was some more free time. And so I followed up and I got the chance to be a senior advisor. You know, their framework's always evolving, but, you know, after a campfire in Cape Cod, after the AGC conference, you know, I had the chance to agree to join, to be the North American lead. So it only took us five years or so of begging. Yeah, six years. Yeah, but I mean, that's kind of one where I can see why it was needed because they've already been doing North American work, but we've been busy since day one, so we already have a team on the ground and we're actively hiring more people. You're right. Time zones exist. And people like to see people face to face too. Zoom works for a bunch of things, but time zones, you're right, do exist. And it's nice to be able to parachute in if you need to parachute in. And for me, it's a really cool time to see the company as dd. When I first met them, maybe it was a check the box. I don't know. I really felt like it was different then. But now in this era of AI and AI defensibility, it shifted left, you know, and what was like a quality of earnings now? Now we're looking at Quality of tech, quality of AI. And it's cool that code and code can be engaged pre loi and collaborating to have a point of view early on. So I feel like the work is more important than ever. And selfishly, I get to learn more than ever. Yeah, I mean it always should be. You know, part of the problem with it being a checkbox item is, you know, from the classic if you're buying a manufacturer or a health care company, what del Tech is often checkbox. It's like, do you have infosec? Do you have disaster recovery plan? They're not. You probably have a commercial product you're using to run the platforms. Not doing diligence on that stuff. That kind of drifted over into the software side is people who traditionally in the private equity bought hard assets, now they're buying software companies. To them was like quality of earnings, right? Like, oh, we do this thing and it's a checkbox item, it should be fine. It's either binary and the, the equality of earnings is often it is binary, you know, but with tech diligence it's not, it's never binary, you know, unless it's something like crazy. Like I said, you're running an ERP software platform on a Nintendo Switch. We get it like out of the box, that's not going to work. But in general, right? It's, it's an. It depends which is very different than. So they just checked it off because they couldn't do anything about it anyway. I mean I've been told tales like 10 years ago, you guys, it used to be called it due diligence and I'm sure that's what the checkbox is. But I mean, you guys, how's it evolved? Yeah, I mean you said it yourself, right? It has shifted left dramatically. It's become more important given, you know, unless we have sufficient confidence or clients has sufficient confidence in a company's ability to exist, you know, and not be the next cloud feature, there's no point in looking at scalability, architecture, cyber security and all that fun stuff. Right? So I think for us it's, it's been a very rewarding time in many ways because as you said, the rate of innovation has never been faster. So also our rate of learning has never been faster and innovation has become such a quickly moving target. It's insane and it's so fun. And as such, you know, today our work begins with an outside in analysis. Looking for web signals and stuff like that and identifying signals. But given it's not yet based on a Lot of evidence. It's signals. Right. And then we want to make those proper insights and that hopefully match our clients investment thesis. And we get to do this via workshops, document analyses, code scans and whatnot. And you know, phase one is typically now top three items of ICs as AI. AI. And then guess what bit of AI? I'm guessing it's AI. Yes sir. Indeed. And as such you know we get to look at how defensible as a company do they know how to play defense maybe even better than a Lakers. I know you're a huge Lakers fan. Yeah. So I can tell you a fun story about this. One of partners at a prior fund that we're in business with. Nice enough guy, huge Lakers fan, also from la. Wore his Kobe Bryant shirt to Boston Gardens into a Celtics game. That's brave. He had to go and he's not a brave guy. He had to go throw out the Kobe shirt and buy himself a Larry Bird shirt in order for him not to get killed at the Boston gym. Curb the Bird. Yeah, that's his nickname. That's my GitHub. GitHub hand. Really? Really. Larry Bird. I mean yeah, he's a legend in Boston. All right. So this, this is I think an interesting piece of this that we that is worth talking about. I think it started as it diligence just because initially it was just the back office crap in any company you bought. Right. I'd make the argument now that's certainly not true of software companies because their product is software. Right. But I defy you to find any manufacturer healthcare company, I don't care what they wrote some software themselves. It may just be ERP reports but they're in the software business. Right. And I think that's one of the biggest areas going forward that's going to be a challenge is as AI makes it easier to customize these things. A lot of companies that aren't in the software business are going to realize yeah you are, you're in the software business my friend. A hundred percent. I think it probably even speaks to how code goes evolved. You know, overall what was maybe just straight software due diligence. Now there's hardware diligence that's done, there's tech enabled. You know, more like we're buying software and stringing it together. And in that space there's one risk but also tons of value creation. Not to use an overused word but basically how can like as former founders operators what our team culture is going and work with those teams to make it more efficient or hopefully make it more valuable. And that's something I think is pretty cool. You know how I feel about, you know, the part the PE partner saying value creation because you know, usually we have to code switch a little bit. You got, you guys are in, you guys actually adding value as opposed to the PE partners. We don't add a whole lot of value. Let's be honest about this. Or use the people we know. Exactly. Yes. Yeah, this is, this is. Comments made by the partners of Parker Gale reflect only Parker Gale's partners and none of the other partners in the B business. We need confidence in the team's ability. They're not just the next cloud feature ultimately. Right. And two, so have. Do you have the foundations in place to innovate and things like that? Only once there's sufficient comfort, we're going to play offense, right. We're going to look at, you know, we're going to do the whole thing from product and product operations, roadmap architecture, infrastructure scalability, open source cybersecurity and all these things. And also understand, hey, not only how resilient are you, but, but you know, what can you do? Are you deeply embedded in your customer workflows? Right. Maybe. Do you have access to proprietary self renewing data, which could be a flywheel and informed data machine learning features or AI features? I think ultimately what a lot of people are sleeping on today still is the miracle of SaaS is potentially dead, right? Or at least it's, you know, severely. I don't think necessarily it's dead, but at least it's challenged, it's changes. You will have deeply unprofitable users, you will have deeply unprofitable user flows and workflows unless you embrace AI. And that's a fun, that technical implementation thing also, right. Talk about mlops. I don't want to bore you or the audience with technical details here, but you want to make sure you use AI where it shines, right? Of course. And just don't throw tokens at a problem because one, hallucination and two cost. Right. That's a big issue. So you want to make sure that you're deeply focused on. And this is back to the product thing you mentioned before, right. You want to be really good at discerning where can AI add value? And is my architecture designed to be malleable? Can it evolve with whatever next trend may happen? Right. So I think this is ultimately we're trying to understand. So speed to insight matters, right? 100%. Yep. So our goal is to be the fastest when it comes to delivering insights, we can start from the outside in, we can source, you know, former. Ideally we talk to the team. Next best person to talk to is potentially someone who used to work there, right. We can talk to them via LinkedIn and get some first insights. We call it Lightning DD. We try to understand, you know, signals, identify signals on the web. And this is also where we use agents too, right. We can suddenly browse the entire Internet, right, And come back with data and insights. So but obviously since it's not backed by evidence, it's almost it's signals, it's not yet insights, right. Then hopefully we can, we can get access to the team and you guys say, look, let's do a first discovery session with the team and we can do a product demo architecture, walkthrough, things like that and then come back, substantiate our in our signals and you know, develop them into first insights. And then once we have sufficient comfort in the team's ability to, you know, have they embraced AI? Is there something that could be a moat? Is there, is there something that's, that's, you know, that we like? Then we can go deeper and do the whole, you know, maybe still check Marky thing. Is it scalable enough? Right. Is it reasonably secure? That's okay. It's irrelevant. That's a great question though. So let's poke into that question because we run into two problems. I see two problems, right. I'm going to talk about a friend of mine, I think you guys know, Alan Williamson. You know, my argument is at the end of time, if a bomb hits this earth or asteroid and destroys it, the only thing left alive are his code and cockroaches. That's it. He writes it. So which is good. But the reality is that I don't think most of software companies always know what their scalability target is. They don't know how many users they're going to have, they don't know how many per second. They don't know. I mean, we used to live by this stuff, right? Because you only had, originally you had cpu, disk and memory. Those are the three things you had to worry about, right? Then you start worrying about networking. Right now we have to worry about like AI latency. But literally it was a fairly simple process we could sort of figure out. I think everybody today either underscales or they overscale. You're not Facebook, you're not Twitter. So I don't need this giant back end of automated servers spinning up and down, right? But that's a really fun thing to build. Right. So I want to poke into the lightning thing for a second, but this is such an interesting topic. Do you ever find yourself in situations where they just overbuilt? Like, it's really good, but they're just way overbuilt? Yeah, for sure. AI maxing's real, I think. Good example is like we ordered a company that do like, I don't know, very basic e commerce stuff. And there was like the most sophisticated architecture we have seen. There was like, you looked at their infrastructure architecture, directrum, and it reads like an AWS catalog pretty much. Oh my God. Yeah. So it's like there's somebody who was in love with aws. Exactly. So it's like. And they didn't need it, right? It was like. But it was. What they did technically was boring, right? So they made their job more exciting. And great cto, by the way. He was knowledgeable. He was. He had a lot of expertise. He just got bored on a job, we think, you know, so. But that. That creates its own problems, right? Oh yeah, for sure. Like huge. I think the best software is the one that solves problems when they arrive. So not. And potentially sometimes even once they have arrived, right? I mean, you remember the fail whale at Twitter, right? For example, right? That's okay. You want to start with potentially a monolith. Why? Because it's simple, right? You have UI business logic and data persistence in one deployment. That's straightforward stuff. It's simple, right? And if you hit your scaling limit, well, you might carve out, in this case, I think it was a search function or so. Right? Carve it out into a dedicated microservice. Suddenly you have the whole problem of scaling up and down specific microservices and managing intra service communications, things like that. The beauty, however, is you can build dedicated solutions for specific problems in whichever language is the best right now. And architecture is the best right now. This is great, right? It's always a trade off. I think this is the stuff that helps us get out of bed in the morning, if I'm being honest. Right. We get to work with smart people like you and the other side of the table companies, Right? Because unless they've built something awesome and impressive, you wouldn't be talking to them as a private equity fund, right? Well, except sometimes we do run into the. That is amazing you did that. We can't invest in it, but it's amazing. I can't believe you built that. And display due diligence. Right. Ultimately. Right. And we just, you know, we're looking for signals and that we have confidence in the team's ability to go with the times. And I mean, five years ago or 10 years ago, it was mobile and then at some point it was cloud and then it became this maybe microservices envy of, hey, why, you know, do we. Should we stay boring? We can do like a fancy microservices architecture and, you know, run kubernetes clusters left and right and, you know, possibly not need it in some situations it might be needed. Fantastic. Right? And this is the kind of stuff that we love. This is diligence, ultimately. And this is what Lucas said in the beginning. The dd, what they've found very often is more like, this is okay. And there's a massive red flag. We're like, no, the devil's in the detail here. Right? That's the problem. Right. And we are here to discern, understand, do we have confidence in your ability to make good decisions. Right? So that, and I'm quoting you from the last time we spoke here in this podcast, to grow revenue, right. Or expand your margins, so save cost and manage risk. Like ultimately, this is what, you know, entrepreneurship is when you look at technology. We are going to do this as an episode. And I didn't have the heart to tell you that I added optionality as the fourth between risk, cost and revenue, because I think optionality is the. And we'll save it for that time. But there's two really key points that you talked about that I'd love to dig into there. So first there's the. I always want to explain to people SAs, because SaaS is both a payment model, right. I'm paying the user, paying the software vendor a license per user or per something. Right? Per drink, whatever. There's SaaS. The. You're running the. You're running it on your data center hardware for me. So I'm not in the hardware business. Right. And there's the multi tenant SaaS. That is, as a user. I don't want it to be multi tenant. I don't care. I'm assuming that you want it to be multi tenant on the other side because it's more cost effective to do that. Right? So one of the problems we've run into is people misunderstand SaaS. If you. Our software company with significant data and expertise, we believe that's a huge value now in the age of AI, that may not have been even a couple years ago. Because part of the problem we have with some of our companies is they're really really good under the covers. Like a lot of these system of record, they don't have the time for the analytics on top of them to draw that data out. They just didn't. So here's an amazing, funny. You all know Nori because she was part of the the Bizcom deal. Sure. Nori grabbed the entire JIRA ticket history from one of our portfolio companies, dumped it into Claude and did a whole analysis herself on, you know, where we're standing on tickets. And it wasn't bad. Like, that's amazing. Yeah. You couldn't do that two years ago. You couldn't even do it probably a year ago. Right. But we're sort of sudden get to that point. So. Yeah. Do you guys believe in this concept of if they've got data and expertise at the data layer, that's going to be a moat? Or do you think that Milk goes away with AI just because data's everywhere? Oh, here we go. My take on this is that do we need to do this like the Newlywed game where they go in the soundtrack booth and we asked Kirby the top five answer to. Because you had said earlier, you said maybe 2025 is the time to experiment with AI and 2026 is the time we should really be optimizing and leaning in so you don't get left behind. I've worked at a fair amount of companies where we would tell people we have proprietary data, but I knew we couldn't do anything with it because the architecture wouldn't allow us to get there. And so the things that I'm seeing that are most important inside this diligence is that we all know where the world is now. If we want the data to be an asset that's truly valuable, what is the engineering team doing in the architecture to make that available? And then if people are then tuning that to then use it in AI models, how are they doing it in a cost effective way? And so some things are still the same. Like you still want to look at the unit economics of the business. There's more variables now that we look at it. Of course, it was cloud computing. Now it's like cloud plus AI. And then if, if you get more users, do you understand, is that actually going to erode your margins? Of course. And these are the things that I think are most interesting. That something's the same. Something's the same. But I think ultimately, no matter how you define SaaS, whether it's browser usage or, you know, hyperscaler, multi tenant deployment or recurring billing. Right. Ultimately, the miracle of SaaS was zero margin of cost. So close to zero margin cost. And new accounts and new seats. Right. This was fun. It was easy. And there was a high degree of cost efficiency. And what I mentioned before, this doesn't exist anymore unless you do it right. Right. And this is where data is so important. Right. You have this layer of managing AI ultimately. Right. And this is what I mentioned before by MLOps. You need to have a process, a technical process in place, a pipeline in place that uses AI where it shines and hopefully also manages costs. Because otherwise you're just going to set data centers on fire pretty much and burn through tokens. And that's not what, you know, sauce. This is not sauce anymore. That's what we're going to do in the economy, unfortunately, because your average user now is going to just type it into chat GPT vs Google search right now they're going to get a better answer because, you know, I have to scroll through Google. Google. Do we use Google? No, I never use Google. I'm a duck. Duck go, you know, person. Anyway, that's cool. I'm definitely. He was baiting you in that answer. He's like, do you have a Yahoo email address? I have a common, you serve email address. I have a Prodigy email address. You want to do this? I can go pretty far back because I'm way. Because I'm way old. Exactly. He's checking your receipts back there. That, that's, that, that there is the, there is the key to all this though, right? It's, it's the, you got to have your gross margin. You got to know what it is. You got to know whether you're going to, you know, send yourself out of business by not mapping this stuff. But here's, here's the problem. Right now all these vendors are selling, and by vendors, I mean the LLM vendors, they're selling dollars for quarters, right? So you might as well spend as much as you possibly can. That's number one. Number two, I don't think the people at the layer here understand like what they're spending, right? So, you know, this is, this is, I think, what's going to crush them. They barely understand how many, how many folks, if you, Here's a good question. You've done an audit, right? And you're doing, you're, you're talking through it and they're running Azure, they're running on Google Cloud or maybe they're on Oracle Cloud or aws, right? How many times do you see that they're overspending on their AWS or over to your point over productizing, they bought too many. Like ooh wait, AWS has got one of these. It's like they're going through like oh, you're Trader Joe's or oh, I'll take one of those. Right. Like how often do that? This happened this week we were like, why do you have three clouds? You don't need three clouds. I think, I mean their businesses are, you know, reasonably scaled or there needs to be a sort of, you know, massive resilience or even there's some, you know, you want to prevent vendor dependence and things like that. So there are reasons for multi cloud deployments. Right. But for most companies they're not right. And to give you a couple of examples, I think one of the. But that's a well known. That's what you said. It's a well known thing. Like we're 10 years into the cloud, right? Yeah, exactly. You should. There are plenty of people that can help you tell how much you're spending, whether you re architect it and you're fine, you're telling me. Which I totally believe because we see it all the time. You're still running into companies that have no idea. I mean ultimately, I think almost every company we look at you can optimize from a cloud spend perspective. And I think that's one of the, I think one of the most straightforward value creation levers post signing post SBA is or post close is optimizing cloud spend. And it's also something you can outsource. There's external partners that can help you beautifully. To give you one example, one case study, we did this deal in the marketing tech space. This was a couple of years ago and they had a pretty massive scale. It was a multi cloud deployment and we ran a hyperscaler cost optimization audit afterwards. And I mean this is an outlier to be fair. Right. But, but it's, it's true numbers. So Lucas, keep me honest. But it was. We identified cost saving potential of $6 million per year in. Right. And it was. I'm not surprised. Which is hilarious. Now what's like what size company was it from a revenue standpoint? Just to give the. Because like people, it was not maybe 50, 200 million ARR or something like that. It was not that big actually. I mean it was big but like not huge. Right. So it was like it did move the needle 100%. Right? You would think it's kind of. You would think, oh is 6 million a lot for a hundred million dollar company? And the answer is, if you know 80% it is, it's huge. Like Amazon is not that expensive if you know how to use it. It's not. I mean, it's not cheap. I'm not trying to say, you know, Bezos has a giant yacht and did his whole wedding thing in Italy. I get it, that's not free. But yeah, I think the same thing is true though, as we shift into, whereas we're in this AI age, is that you now have to look at cloud compute, but you're also looking at AI spend. Yes. And in this one, the common piece is organ maturity. It starts with the leadership, it goes into how it's implemented. But did they prioritize the time to find good unit economics? And if they haven't, it's a value creation opportunity. And if they have, that's plain offense. They could probably optimize it more. They've obviously identified something that's powerful that they want to do it. And one of the things that I like that, Dan, that brings up whenever we're looking at companies is where they've put AI on a feature and they're losing money on the feature because they haven't put the telemetry in to know what the value of that feature is. And they also don't know that it's probably could have been solved in a different way. So I like that. That's now part of our playbook as we went through things. What's interesting about that is that's such a complex issue. So we have a very old portfolio company that's years ago, nice guy, great company, and they built a mobile application because the customers said they would be interested to have a mobile application. I know you're going to think this is a story. Oh God. The whole thing went off the rails. So they built this mobile app. Nobody used it like less than 1% of the customers, but some huge percent of the customers cited it in references to other potential customers as the reason they bought. They loved the idea of running on the phone. They just never bothered to do it. But they loved it. They showed it to all their friends. And it was one of those things like, okay, technically we lost money on the engineering side building a mobile app, but we made it back on the marketing side 100%. I mean, go to market is a thing also, right? It is. I mean, we see so much fun stuff. Like we saw we had ordered this one company once that had a really good in into enterprise customers. And if you look at enterprise customers, at least in Europe, probably the Same in the us there's governance institutions like purchasing departments and things like that, right? Yes. And so you talk to the department that wants to use this software, but they have to go through purchasing. Right. So they kind of strategize with you. Right. And there are instances in that case where this company had a very specific ESG certificate and very specific. On Super Edge, Casey. And then as part of the rfp, they said, we as the department, they just told the purchasing department, we demand that you have this specific certificate. Plus. And they were ISO certified as well. So you need to have two certificates. One of them needs to be this weird ESG certificate. So it's literally the only company you could choose. Right. So that was such a fun thing. That's funny because we're, we're people forget I'm old enough that we dealt with purchasing departments selling to enterprise customers. I mean, I covered Eastman Kodak for ingress way back when. And those were the, you know, you'd be perfectly set up, the prototype went well, they were ready to buy and the person would look at it and go, not Oracle. We're, we're, we gotta stand in agreement with Oracle or Sybase or something else. And, or, or we only pay this price or you have to have this other crazy thing we used to in the United States, there was ADA was the programming language. Anything that went to the government had to be written in ada. You know, it's like you could go in here in Chicago. I think that's an ADA shop. It is, yeah, yeah, yeah. They are an ADA shop. So on the marketing piece, the joke internally is that a year ago, you know, you see these sims and now every SIM that's seen as an AI company, so everyone has rebranded to an AI company. If they are or they're not. It's refined product marketing side. One of the things that I think is interesting when we go in and we start working, having that entrepreneurial mindset is where somebody's not utilizing AI and we can give a recommendation and a plan where like, here's the most limited version you can do to actually have a little bit of AI branding. That's true. Could be like an audit feature you have where we say, hey, we run the 3i to audit check like their code was perfectly fine to do it, but just a little check on that allows that product marketing to be true. And I think just a sprinkle sometimes is okay because then it's like, true. I think the beauty is also like, if you look at again, devils in a detail Right. It's perfectly okay to start easy. Like if you just want to integrate Claude or OpenAI via an API and a little bit of UI, you know, Pixie dust on top, that's fine in the beginning. Whether you are then an AI native company according to your investment banker or the iam, you know, that's to be seen. But I think it's easy. It's good to kind of fake it till you make it. But ideally, and this is again the fun part of our job, we need to understand is there a credible path towards becoming utilizing AI in a more embedded, more reliable, more predictable way, whether that's internally in terms of efficiency enhancement, whether it's externally as an upsell or something like that. Right. So you might start easy and that's okay, like MVP mindset and stuff, but it's probably not going to be the end game. Right. And to me, like, we talk a lot about diligence, that's a lot of red flag front, like what are we trying to avoid? The fun part of the job is the value creation because we are entrepreneurs ourselves. We go in there, we're working post deal and it's oftentimes the creativity to say like, how can we improve the value of this asset? And sometimes it's just practical things to say. Put this in here. Here's the engineering implementation for it. It's not going to cost a lot, but overall it's going to probably help you win deals. And to me, like, that's a fun part of the job. Yeah. The hysterical part about that is value creation is the most overused word in, in private equity because as private equity people we go and we got operating partners will value create the hell out of this thing. Right. It's not right. It is really that level. It's understanding there's always room to improve business. Yes. Right. And we all come from different perspectives. So it's not that the teams are not smart or experienced or whatever. I've just seen thousands of deals, so I've seen it done thousands of ways. So I may have been, you know, mostly they're stupid ideas, but at least it gives them something to bounce against. Right. That we've seen it before, they haven't. Which, which I think hearkens back to something, a question, a point you made that I want to, I want to dive into. So smaller software companies, you mentioned using the right tool for the right job as part of AI. So hey, should this be done in Python or should it be done with, you know, with the when LLM versus you know, Opus 4:7 or whatever, right? They have these names. 1, 2. Like, I'm so tired of the names. Kermit the Frog 7 or whatever. Small teams don't have that luxury though, because they probably know one language, right? They built it in something because that's. They knew. They're a dot net shop, they're a Java shop, they're a Node JS shop, right? Now, when you look at diligence. So let's say five years ago, three years ago, there's no way I could. We're going to do this in Rust, right? I don't know anything about Rust. How do I know the team knows anything about Rust? How do the I know the consultants know anything about Rust? Because it's so new, I'm paying a guy 2,000 bucks a day that just learned it a week ago, right? But he knows more than me, so I think he's a genius, right? That's tough. Now, in AI, if Rust is the right language, I'm not sure I need to be a guru in it, right? Because it's memory safe, it's super fast. Like, there are reasons to use that architecture. But now with an LLM, I can probably generate a lot of that code. But like, how do you diligence that? Like, so I'm, you know, I thought Rust was a great thing for this. I don't know anything about Rust, but I'm a good, let's say I'm a good software developer, right? Like, I'm not, by the way, folks. But let's say I was right, that I knew good architecture, whatever, and that, you know, Alan says I write crap. You know, it's the easiest way to get engineers to write more product for you. You just write some for yourself and they hate it, so they just redo it. It's perfect. Perfect. It's a speed thing. It's an inside tip. So how do you guys look at that problem? So you're right. I think we should use the right tool for the right job. But is that a safe thing to do with these smaller companies that don't have the expertise? I think it's a multifaceted question. On the one hand side, right tool for the right job, yes, but reality still exists and skill is a reality, right? And also size of the ecosystem or hiring market, like Elixir, for example, is a beautiful language. Phoenix is a fantastic framework and did a bunch of the Rails core guys. Our favorite framework is Rails and also our internal software stack uses a lot of Rails, which is great. It's a very token efficient language. But you know how I feel about Rails, right? It's okay. I just spot nobody's perfect. Nobody's perfect. Oh, I'm far from perfect, trust me. And you know you're at the. You're in the homeland of rails, right? Because base camp is here. Yeah, exactly. Dhh is here. Go by if you want to do the whole thing, you know, thing at the. Exactly. Flowers at the doorstep. Exactly. So actually we should come by. We're gonna hear for another day. We need to just drop by the office for sure, take a picture. So no. So right tool for the right job. Yes, but realities do exist, including skill set, including size of the ecosystem, et cetera, et cetera. That being said, AI made the explainability of code much easier. Right. And the third point is agentic development was a buzzword until end of last year, but now it's kind of real. And the step change was opals 4.5 or so end of last year. And to give you just an example from our daily business at code and code we have. We use agents for development too and it's. I mean we do nothing else every day, all day than auditing companies. Right. So last year we did probably like 200rds. This year we hope to double it. And so, so we see a lot. And we also see a lot of the current trends. Right. I think not that many companies yet you leverage agentic development. So it's a huge, that's a huge evaluation lever. Split that for a second. That's a really good point. Split it between when, when can you say yeah, they're basically doing agentic development because this is not like, it's not a binary thing. It's a bit of a, it's a bit of a roadmap. Right. Maybe they're just trying open spec to start, you know, putting some gardens like talk about, talk about how you would evaluate that maturity. Yeah, this is a great one. I would love to put you guys in phone booths for this one because I bet you I want to get answers to this because it's going to be okay. So explain to me, explain to me what that level is. I think firstly it's a moving target, right. Last year just having GitHub, copilot or cursor as an was fantastic, right? You had this little sidekick that helped you write the non fun bits, tests and stuff like that, right? And today agent development means there are agents that when you go to sleep they write code and you wake up to a pull request. However, these things are like PhD interns. They're super smart, but inexperienced, I guess. Right. They need very, very good guidance. And let me walk you through an SDLC example that we do every day AT Code Co for internal software suite. And. And someone. We use Slack for internal comms and someone reports a bug in our internal software. So I write a message in Slack. Then an agent that we call draftpunk because we're engineers and we like stupid puns. Draft punk picks up the ticket or a message and moves it over by MCP to Linear and creates a ticket. This ticket has acceptance criteria. It has steps to reproduce actual result. Expect results. Da da, da, da. Hold on. Your own MCP search server. Yes. Okay, so I just want to make that clear. Then an agent, another coding agent, reads through the ticket. It goes back and forth, a little product agent, and they align on a strategy. Then the coding agent actually writes the code, opens a pull request. GitHub, Copilot and Claude. And there's different. We talked about the weird naming conventions and stuff. There are also different, like coding agents you can use. Some of them are more pricey than others. There's one that's super fancy that we don't always use because like 20 bucks per review, so it's insane. And others. And for other use cases, you know, we just use it for like just. Just listen to the words you just said, though. 20 bucks. It's insane to review this whole code. Well, just for one pull request, right? Like one pull request. But you know, if you do it like me, you just make sure that pull request is huge. That's a good point. Yeah. Really big branches. Pull request maxing. I like it. Gotta be capital efficient. That's token efficient. We are gonna do it. We are doing an episode for PE Partners on what a pull request is. So I wanna have you guys on that episode translating. Just think of it this way. Somebody writes the code, somebody else has to look at it. Now that's good enough. So new code is shipped to GitHub via a pull request. And then code is reviewed. And that's the fascinating thing. Now you see, line by line, code reviews. Not a human writes those comments, but GitHub, Copilot and Claude, right? And then we wake up in the morning. Andrew, our fantastic cto, he wakes up in the morning. Or his colleagues, they wake up in the morning to review the code's contributions and tell the AI, no, this is not a pattern we follow. Or, or because these things are prompted to write more code. As one example, they're not Prompted to write ideal code. So we had this instance where instead of just editing an action in a controller, it just duplicated basically a controller. It was just this whole waste of code, right? So, and then the beautiful thing, and this is where we like to see companies that truly embrace AI as a best practice today. And maybe it's a moving target, right? So six months from now, maybe it's table stakes, is that you tell the AI where it went wrong, right? So you go back to, you know, configuration files, include and so forth and tell it no based on your comments, based on the review of the codes review or coding bots review, you tell it. This is how we write code. This is the stuff we don't want you to do, right. So what I'm trying to say is, as a very long form example, thank you for bearing with me is it's a moving target. Six months, 12 months ago it was just having a sidekick that takes care of some code. And what's fantastic today, it's engaging to development. But the agent development bit is not just letting agents write code because then it's going to be a terrible code, very likely, but having this human in the loop process that ensures quality, those guardrails. And I think that's the essential bit that we like to see or one of the essentials. And then obviously there's model governance, AI security things, how do you prevent that when you use AI and features that the model drifts so it becomes less accurate over time, etc. Etc. Etc. Lots of things to look at, but ultimately it's back to the function of do we have confidence in the team that they can improve and they're willing to improve and you know, given agents, you know, team members these days, you need to guide them and give them guardrail so that they can improve. I think also it's like good example of when we started 10 years ago and developed our own stack, right. And continue to do so today, it was the right decision because in the end it's like this is how we stay sharp, right? Because of course, yeah, we work with AI on a daily basis ourselves, right. This means technology has always moved very fast. Now it just moves faster and faster and faster. That means if you really want to be able to audit this, you need to stay ahead by also working with it on a daily basis. Right? So I think this, I mean if you, if someone would have told us like last December that there's going to be like this automated draft punk, we probably wouldn't have believed it, right? So this is like how fast this all develops. So just pushing a boundary, being able to also just experiment, I think for teams is really important and I think it's super interesting because if you look at it, there's like this whole Wild west moment right now, right, where you're just trying out stuff, experimenting, right. So for instance, last week when actually I'm back on writing features as well for our internal tooling, played around a lot with like context engineering, right? Giving the agent actually the context around what do we actually do as a company who's our user, who's actually working with the software. Right. This actually improved the results dramatically. So I think it's really cool to not just like, I don't know, reading this, the fourth book about agile development and then suddenly just implementing what has been around for like 30 years. Right. But it's something that's truly being shaped as we speak. And therefore you can also be one that co shapes this by just trying out stuff and see what sticks. I think what I remember when we Met Kirby in 2020, right, in Kansas, you not only, I mean we did this, you know, the workshops, etc. And then, and then we asked you for restaurant recommendations because we're there as tourists as well, right. So we spent some Kansas City. It's barbecue central. Yes, sir. It was. You give us. Hold on, you have to be careful at Kansas City, Kansas or Kansas City, Missouri. We were, the workshop was in Kansas City, Kansas, but then they went to Kansas City, Missouri, you know, where the culture is. There you go. I have friends who live in both, so I knew that was, that was a good trap and you hit it. Exactly right. And I remember that actually when we met, afterwards we spoke, gave us restaurant recommendations and then you asked us, you were like, hey guys, is how do you work? And you kind of saw that we were like, you know, not using PowerPoint or you know, Google Docs for notes, but an internal system and because when we founded Code and Co in 2016, we said, look, we love working with smart people, we love being at the forefront of innovation, we love getting paid to learn. It's a great position to be in. We don't like consulting, we hate PowerPoint. Right. We want to make sure that we have a process in place that's scalable and that's fun, right? So I remember that when you the good news, I think Germany just announced that they're going off office and back to Libra. So I think that was this week. So yeah, they don't like it either. The entire country hates PowerPoint. Very true. I agree. By the way, I hate PowerPoint. I hate SharePoint worse. So I would take a yes. And to that. Whenever you're thinking about. Whenever I'm thinking about how people are moving into agentic coding, to me, a lot of it's the leadership and the organizational maturity. At Code Co, we're aligned as with leadership. And then you see a very practical way to get to that human in the loop system that Dan walked through was not overnight and to experiment, you know, and always be learning. But inside of companies that I'm seeing, there's this already embedded workforce. The engineers, they're hearing from somebody like, oh, you guys won't be relevant anymore. And what we're saying is the engineers are even more relevant because it's an asset if you can keep it. And if you give token max and give me this like, massive vibe coded app, but we can't debug it, we can't actually use it. It's not truly an asset. And so the teams that are experimenting, kind of easing into the water, it's like great automated testing. That's a really nice way to kind of start to ease in to using agent encoding. And then once you're truly feeling it, moving into a more advanced system like Dan described to me, is how I'm seeing people moving, you know, from, yeah, I'm just kind of over here using a copilot to truly having a system inside an organization. Okay, so you want to get three points from all of you, which is perfect. So I was going to ask you the same thing. I think that's right. Because when we do due diligence. Right, right. I don't know how you know, because, you know, you would know it for me, I don't know how they do it in Germany, but, you know, dental work here, when you go to the dentist, the dentist says, do you floss? And you say, every day. And he knows you don't. And you know you don't. It's a lie that he's like, I could see it. That's the evidence and that's the code coverage. You know, and test coverage is every portfolio company. If I say, what's your. What's your code coverage? And for the record, we do floss too in Germany. I want to verify that in the diligence. So they start. They start saying 95%. Then I go, really? Okay, it's 80. Yeah, come on, guys. And it's usually 30. I agree with you that the simplest point, if you don't know what you're doing in AI, one of the easiest things to do is to start doing test coverage with it. I think it's right. I mean, are you starting to see that from a company saying, realizing that that's something they should do or is that like light dawns over Marblehead when you tell and it used to be, what's your automated test coverage? Okay, easy value creation item. It's going to create efficiency. And now it's like, okay, well how are you actually tooling that test coverage? So testing is a very easy way to ease into it. Bug fixing is an easy way to where we started. So Dan's talking about this system. It started with baby bugs. Now it's taking bigger features because you have to tune it. And part of it is tuning the system. It's also about tuning a mentality. And that's where when the engineering team is doing that, they're also identifying what is important to their coding style for their particular code base. And a little bit more of a leadership development plan. You can't just have principal engineers running the company. It's a like a legacy risk. And so how you're bringing junior developers in, training them on those ways, making sure that their skills don't, you know, they don't have atrophy there. Sure. That to me is like more of a leadership decision on how you bring in agent coding. I think that this deeply resonates. I think this is important. And I think it's funny that it's a controversial take. Likely everybody says junior deaths are dead. We don't believe that. Like if you're young, if you're hungry and you're as a human growth mindset wise, you're as AI native as it gets. You're willing to experiment, you're willing to, you know, change your ways of doing things and or be challenged because you're new to things. I think you can be super valuable to organizations. And obviously you need the guidance from more experienced engineers too. Right. So that's the problem. Older engineers or more experienced engineers are certainly also not, you know, ready for retirement. Right. They need to be part of the team. But I think it's the, I think we can be fairly, you know, constructive and glass half full here. It's the combination is going to be winner. The thing Dave Kellogg, who's an old friend of mine, we started in tech support together, he's a very famous marketing guy. And one of Dave Kellogg's standard points is a Disney World parking attendant gets more training than your average dev or sales rep at a software company. And I think that's true. I agree with you. I don't think junior Dev is dead. I think though, none of our organizations that we see are really set up to really mentor the next generation in through this stuff. Right. And that's part of the problem is you've got to have a. You got to have a game plan for that. Because again, I agree with you. The older people that have the institutional knowledge and the why we did it the way we did it, like you, you can capture some of that with AI, but it doesn't mean you can solve that problem. You need to train the under people below because we've all seen code where you've got comments like you can't take this line out. None of us are sure why exactly. Just don't do it. Hopefully we're not hitting those anymore, but there's still some of that that only somebody who's been around for a long time knows now. Lucas, I want to. So this is funny now we're going to. This is a little bit of like tech person to pure tech person. I'm doing the same thing. We're writing code here at Parker Gale that we haven't done in years. Like you know, part of the podcast stuff we're doing because I can. I don't have time to learn the low level languages but it lets you get back into the actual code, which is really interesting, I think. Yeah, yeah, no, I think that's great. Also I think people like us that used to work very hands on as a developer and then maybe stop for a bit. Right. Are actually now. This is amazing. Right. Because you know exactly what to prompt and how to do stuff like on a high level architecturally, but you don't have to like the low level actually typing it out anymore. So I think it's really cool. And this is something I think also going forward how teams will actually be co staff that there is people that are potentially high up that continue to then actually productively produce stuff because it's less work just to do it yourself than to explain it to someone hoping that they understand what you mean. Right? Yes. So. So now it becomes so how. I think that product management is going to be huge on a go forward basis given AI. Right. Both. Both from a. How quickly product management can turn around things. And you know, we've way too many. We see way too many product managers that spend way too much time internally because it's easy. Right. And they just busy themselves with specs and stuff like that. Well Night. You don't have to. Right. The key is talk to your customers. You can build stuff in front of them to say, is this what to your point of. Do you understand? I'm explaining to you, I'm looking at this. If I built you this, would you do it? Would you buy it? And I think that's one of the things that wasn't available before. The second part of that is architecture. You know, I don't. Architecture is always the challenge here. So how do we diligence architecture now, given that AI code? If you have the wrong architecture, if you slop AI on that thing, you're going to turn that thing into like this giant money. That sounds fun. It's a blob of like it's discussing. So. And that's always the thing. I think architecture becomes one of those between software developers is always a, you know, get out your pipe, get out your, you know, your jacket with the. It's like a professorial thing, right? That's why all the arguments are so fierce. That's why I'm like, you know, forget Ruby on Rails, you know, like, it's all. That's ridiculous. But for the right job, it's like, how do you, how do you diligent to architecture now, given it's so important? If they, if they throw a framework on this thing? That is a disaster with AI, like, how do, do you find the customers are receptive? Do they understand that architecture is an issue? I mean, CTO probably does, but maybe the board doesn't, or maybe the management team doesn't understand they're locked into some kind of architecture that's hard to break out of. So I'll answer your question briefly and then I'd like to hear the team's thoughts. We were in a meeting yesterday with a firm and we met with several firms in New York, you know, clients, customers. And one of them said, I want to make sure in the diligence that their architecture can actually support proprietary data and AI growth. And Dan said, you have one of the more advanced views of the firms that we're meeting with, because you actually understand that. And so I think it's going to make a difference in firms that understand that architecture is important. I agree, because one, scalability. We could find a red flag in scalability just by looking at the performance reports, but fixing the architecture and then also fixing it for what problem they're truly trying to solve to me becomes more of the problem to explore there. But I don't know, what do you guys think? I agree But I think realistically also not every company suddenly or needs to be AI native, right. Like there are companies in regulated industries, there's Production Adjacent manufacturing ERPs or quality management systems and CPQ and whatnot, that's still not even run in the cloud and they can't because you integrate with machines and the people are there anyways in the factory to put the wood in the machine or whatever. Right. So I think you always have to make sure you look at the sector, you look at the sort of of realistic expectations of what's possible. Also legally, I mean if you look regulate industries, fintech for example, right. We've done a ton of credit decision engines and of course they would love to use large language models and transformer architectures for stuff but they're just not allowed to because you need to have deterministic stuff. Everything needs to be auditable, everything needs to be version. So if you want to buy a house and they say no dear Jim, no mortgage for you and you sue them five years later, they need to be able to roll back to the model and the algorithm them from you know, back then, feed it the same parameters and it needs to give you the same outcome because otherwise it was not deterministic and it was just. And there's grounds for, you know, complaints and stuff. We've got a techcast episode coming up that we just did a quick demo script to prove to just show it how it'll start going off the rails on a simple question because. Because it is. They are not deterministic and that is one of the most difficult things we have explaining to people who are non technical the difference between deterministic and not deterministic. Okay, well let's look at that question though from a different point of view. I answered from a buy side like a doom and gloom mindset. We also work on the sell side and everything in between. Sell side work right now is where architecture has been most important. To help explain why it's valuable. We're working on a project right now. They've built a beautiful ETL process and inside extract, transform and load for you. Thank you warehousing folks. So but with this, you know they're talking about all their assets for these proprietary models. Really said you're missing this huge piece that's very hard to do. LLM can't just create architecture that's scalable on the fly. This is an asset. We need to highlight this and explain it in a way that non technical people can understand that this is a moat, this is strong. So I think that on the sell side architecture is a thing that's become more now front and center. Like this is hard to do. Let's talk about one piece. I think that's interesting. We haven't talked about some of the mechanics of diligence. Right. So there's two things that I think are interesting from our perspective. We're starting to see the, the hey, let's do our own diligence on our own companies before we take them to market. Right? Why not? We can be prepared to be ready to go to market. Why don't you? Because oftentimes the PE world where we tend to do it on you know, the finance and back office sides on all of our companies, like our associates are machines. So they tell you all that ready? And then everything else in the organization is like, oh yeah, we're going to go side. We probably do a better job of, you know, because you're sort of doing the day to day job. You're not really kind of. But we think, yeah, we think that's a new market. We think that people should be bringing people and say, look, I won't mention because we're on the other side of that. We're on the buy side a lot too. And I've had diligence firms on the other side. The large ones that hire, they don't have a bench, so they hire somebody for the particular diligence and that person, all they're trying to do is impress the guys that they're doing diligence for. So everything's an issue. You know, it's like what'd you write? To sit and see? Really, you know that. Come on. Right. There's that. That's, you know, literally, you know, patently ridiculous. They don't really understand. So but we're finding that to prevent that we want to go into diligence knowing. Because you guys were involved in the Bizcom diligence, you remember how long that ran? I mean when we saw, oh, you on the buy side, on the sell side, three months of tech diligence, three months. Because we had other stuff going on the deal. So they just kept going back for more and more questions. Right. It was this issue with. It moved so fast that we weren't, we didn't go out to work. But from that we're kind of looking at going out to market. Do we diligence ourselves before we go? So our buy side work has shifted left. We're starting pre loi. We're getting involved in conversation. I thought you were liberal. Or social, the sell side work has shifted left even more. And if you think about like a house, where you would fail on a sell side is you say, hey, code and co, come in here, help me sell my house, make this asset look more beautiful. We've got two weeks. I'm like, okay, you could put new curtains up, maybe put some new couches in there, but overall the technology components in the basement, right? And we need to look at this 12 months out and maybe it might be great, but you don't have telemetry involved. Like you're not actually tracking, proving the value of this asset. And so us working 6 to 12 months out on the sell side just to make sure that there's one, if there is something to fix, they have time to fix it. Or if it's truly valuable, how can we just spend the time to really craft the best story? So that's my point of view. I think also there's a very interesting aspect. I mean obviously, yes, there's the document and then you do the work yourself, you prepare the team. Also I think it's like if you, I mean realistically, you're going to sell a company potentially to the next sponsor, right? That has a different angle for the next five years. And I know there's like five or six PE firms looking at the asset at the same time, right? You want to make sure that you shield the internal tech team as well. Because if every one of these five or six companies has like in a workshop with your tech team, they're not just not going to work for like, I don't know, three to six months, right? So it's something, if you actually do vendor work on the tech side too, you actually first of all prepare the team. You make sure that you can actually fix stuff if you do it early enough. But then also you become like the first line of defense, right? So if there's like in the first phase, all six want to have like a first session about technology, then we can step in, we can do this in the first instance and only like the 2 and 1, 2, 3 preferred bidders that go to the later rounds then potentially get access to the company itself, right? So I think it's also from that point of view really good to do not just by looking at it early enough, but our goal also in the mid to long run is actually to do have a continuous due diligence where DDs don't just become this one off thing, but you continuously DD and improve a company so you don't really have to Do a vendor DD just by doing this. You can click a button, say okay, now I can export the point in time, the factbook and then this is the vendor dd. So it's not like a non event, like a deployment should be a non event. Right. Also, I mean, let's face it, no one does DD because they want to. Right. It's a thing you have to do in order to partner with someone like Jim. Right. So you want to make sure that I think it's an important thing to do for the aforementioned reasons. Right. You de stress the process, have smart people that act as the first line of defense so the team is not distracted, they have better things to do with their time. But also, I think most importantly, there's also a, I guess a coaching element here. Right. So you are challenged and given we're in an industry of constant change and you know, as discussed, the rate of innovation, rate of change is only accelerating now and you know, it's fantastic to be challenged. And this is why I think we're quite bullish on this idea of, of remaining involved. We work from pre loi to post exit and everything in between. So our early signal discovery as part of lightning signing with SPA and then exit readiness and vendor techd and in between we do add ons and such continuous assessment. We do portfolio monitoring and we like it because we get to see so much and we get to challenge them and they get to challenge us. So it's a very mutual, mutually beneficial relationship and it just makes that, you know, thing you have to do DD a non issue suddenly. Yeah, I mean I think the parts of it that, so, you know, some years ago people started doing, you know, allowing automated code analysis against code bases like, you know, when we started. There's no way, I don't care if you were the last bit or whatever they want, you're not getting to see the code of any, you know, they'll talk you through stuff. But now it's like, oh yeah, well, give you access to our repo, you can run your favorite SEMA or whatever else you want, black duck against it, right? To us, that's the thing you do on an ongoing basis. So you should have all everything. We have a lot of our customers, a lot of portfolios on Vanta. I don't care what you do it in, but you have all your cyber stuff ready, you have all your proof points, you have all your code analysis, you have your open source licensing. If you cover all that stuff, then the diligence is really about strategy going forward. Not, not looking for red flags. Right. I mean, it's our house view that what code scans are actually not a good use of time. It's more so the things that you can put together from seeing the code and also the systems that inform the code. So it used to be like, oh, I can look at GitHub and I can see that the contributors. Yes. But someone goes, oh, with AI coding, we're much more efficient. It's like, okay, well now we have to look at what was going on in the contribution. How many of those were actually defects, like they got rejected. And then also is that person, person just only using, you know, let's say anthropic. Look at their account to see how much they're using and they're not actually doing any real coding. Now these factors help us understand better what's going on as opposed to just looking at that. But I mean we always look. Just look at the, you know, you're, you're all young enough that you've lived in a GitHub world. Git world. I was an SVN CBS. A lot of SVN CBS. You know, I've been a lot of these. True. But that was always the quickest. Just show me your check in logs. And we don't have any single points of failure. Well, I see that check ins are friends. I'm pretty sure you do. Right. Lucas wrote 98% of the code, Right? Exactly, exactly. Let's talk about the lightning diligence here for a second. So what I'm looking for from you three and I would really love to put this in soundproof booth for this, you can pretend maybe do this. What are two or three things, both good and bad? So if you quickly scope out those, you see some things and you're like, okay, if I see these three things, it's probably going to be pretty positive. Now we're talking about going forward. If I see these three things, I know we're dead. Right. So I don't want to go first. You look so eager to answer this one, so I'm going to let you go first. All right. I mean, again, conceptually, it can be conceptual. I mean, again, really depends on the company and the sector and all that stuff. And really, really, you know, what we can find. But there's a couple of things that are stand out. Like for example, career pages are a really good source of information because you usually put the tech stack there because this is, you know, what you're hiring for. Right? Right. So, and this gives us signals on when our Client says it's always ultimately, is there a disconnect or a match between our client's investment thesis. Right. And what the company has to offer? Yes. And if you know, the, the, the fund says, look, we're all about cloud and multi tenancy and AI nativity and whatnot. And then we see Delphi as a stack they're hiring for, or we see there's desktop deployment and that's a reality. Still, Object Pascal is still something. I don't care what you say. It's true. It's not dead. It's not dead. Delphi should be dead. It's been handed around so many times like everybody's owned it at this point. Right. But you can already see there's a bit of a. In tech, we would say cold smile. Right. There's a bit of a smell when it comes to disconnect between investment thesis. So what do I want to do as part of this with this investment versus what can I offer as a company? That's point one. Point two, we really like to browse the web for signals such as if you look, I mean, Reddit is the weirdest source of information, but for whichever niche topic that exists, no matter how small the niche is, you do find some information there as an example. Right? And if there's people. Oh yes, you do. If there's people that just complain about performance gaps or bugs here and there, this gives us another smell. Right? Or on the other hand, if you look at customer feedback like G2 Kipterra and the likes, and people just rave about the software. We did a devtool recently, man. People freaking loved it. It was like every single user seemed to be an advocate about the dev tool. Really? Wow. Because most times they love the dev tool 100%. We were blown away. Like, we were so excited to start DD and because we were like, guys, this is a winner. I can tell you that already. If devs who are the most difficult to please audience on the freaking planet. If these guys love you, you, you know, you know, this is interesting. Come on. A private equity partner would be the most difficult person to please. And my wife. Those two things are probably the most difficult person. Please. I think it's important also that we clarify when we say lightning. It's a fast engagement that's only with outside information or limited access. Maybe one interview, something like that. Because it's not fast whenever we're actually in diligence in the depth piece. But I mean, to us, I think the other area that I would call out is that when we're doing lineages, it's really whatever you can find for the type of company. And so when Dan was talking about raving reviews, one that I've really liked that we found is we found people complaining just about latency and it started to help us understand a little bit more about what was the stack and also what was the CEO. So we have no tech debt, we don't have porn stations. Like we're seeing something right here. And then we start to kind of put these like a journalist would put something together to make a story even before going in just to inform the diligence. Another one that we worked on that I thought was interesting was saw feedback that the software was slow, went to their API decks. We found a minor security issue was less about security and more about the sophistication of the team. And then we had a brief conversation with a senior engineer there and basically learned out that everyone there was self taught. And it's not a bad thing. Things in technology can be fixed, but it helps us understand, okay, well what does that hiring plan need to be? What's actually impacting the conversation with IC and the financial model? When we're doing that pre loi it's very helpful. Yeah. And we're going to, we're going to see that mess, Kirby. Because the mess we're going to see is that all essentially untrained devs with no architecture building something. It may look like a pretty good product, it's just not. It's going to be a Jenga that's going to be horrifically hard to both one diligence and that. You know, most of the time you shouldn't go into a deal, you know, in diligence. Not being prepared for, hey, we think, yeah, I want to know what you guys think so I know where to focus. I'm not expecting it to be a no deal. Right. Because why would I get that far? Why do I spend all this money? I should have gotten to the lightning thing to say, you know what, this isn't for us, we should just move on. And sometimes the value is a thesis. There was a thesis where it's say, hey, we think that their product management could use more formalization, maybe better engineering leadership. And I said yes because I just found this comment on Glassdoor from two years ago that's just roasting the team. And it matches this comment and this comment that's kind of intermixed between all the positive stuff we say, okay, well this is an area where you can just start to Build out these narratives. I think also like, I mean this team culture thing is really big, I think because I mean if you see class reviews that are not great and then not just one, but like a pattern there, that's probably not a great sign. Right. Because in the end then this means there's some friction that at least needs to be looked at deeper in the future. I think great documentation used to be a good signal, a positive one. Yeah. Nowadays you can just churn out documentation. Right. Like we see more and more cloth decks where you can definitely slap. Right. So this is like actually like. Yeah, so this is something that's harder to diligence now. Right. Because it's just easy to create stuff. So I think this is a signal that used to be very positive. Now it's very hard to tell. Right. A very concrete example, more like a technical one where I think it's probably not a great sign if you, you still use, for instance, jQuery in 2026. Right. This is like a technology that was already like 10 years ago. Not the hippest one. Doesn't necessarily mean it's bad per se, but did a lot of work for us in the old days. Right. No, that's where you go, it should be retired. I get it. But Paul Iris. Yes, yes, yes. But it's like, I don't think it's. Like I said, it's not bad but it shows that the team doesn't necessarily keep up with stuff. Right. And this is like a mindset thing again that's like more most important than ever. Right. Like that you really are interested in trying to potentially do stuff better. Right. We saw actually just one quick comment. It was funny. I know what you're thinking about because we had a DD quite recently. The IM said we use top state of the art front end technologies and then it mentioned jQuery as a first big logo. And then could also be an issue in translation that the banker just didn't know what was new or not. Oh, it sounds good. It's Jane. It's query. There were a couple of screens, screenshots in our entire time. We found it funny. It's like, hey, nothing. I mean not to dunk on jQuery. No, no. Yeah, we've done a ton. It used to be amazing but. But it was just kind of funny that we saw a SIM that said cutting ed tech, cutting edge technology stack and then they had Heroku on it and we're like, well, why is that in the sim? That was like. So I. Well there, there Is that disconnect between bankers? Right? So bankers are trying to put like, you know, to them, oh, at one point, yeah, Heroku was something everyone, oh, we should do that. It's hot, you know, and so they don't really understand what's hot and not anymore. So they're going to throw as many logos in as they can. Again, that's the pre diligence, right? If you're selling to somebody doesn't really understand the details of that and is buying the business because they like the end market of customers. They may not understand the technology, they may not care, they may not know. But that's what we're trying to get to is we care because it'll affect how we. What do we do with the business. I think this is why we do sell side work, right? This is why you should do. And I mean you're technical, right? You know these things. Most people don't. That's perfectly fine. Right? But this is why sell side work is relevant. I think they don't trust me to do that work anymore. You guys know that clarify on that disclaimer that Heroku is a firm that's not supported anymore. And so it's a tech debt item. It would slow down some things. So as part of that, that would be the translation layer as to why you wouldn't do that. I mean, I think as we talked about this earlier, like test coverage I think is more important than ever because if you don't have any test coverage, it's only manual testing. This implies that you're not far ahead when it comes to AI stuff, right? So because if you let agents lose on your code, this only works if you have like a really good regression testing suite to make sure that whatever the agent just did didn't break the rest of it. Right? So I think this becomes more and more important and it's really like an indicator of. Okay, this company likely doesn't have a really good AI maturity as well or they've gotten too close to their. I mean, look, we all have an LLM we like, right? Let's just be fair, right? I mostly work, you know, in claude, usually not the latest model, just to save a little money, whatever. But I've noticed it's picked up my bad habits because, you know, I was lazy about writing test coverage. It's gotten lazy too, you know, with me, he's like, I think, I think I. You should be the sidekick. Come on. I thought I said she'd be a better sidekick, but it's not. I actually Think I've drawn him down to my arms. We don't need it down. Exactly. Yes, I've got. We've seen some issues. We think it's this guy in Chicago that's just ruining the model. It's 100%. It's 100% side. It's getting snarky with me. You know, I've also noticed it does get snarky. You know, it's like. I've noticed that too, actually. Yeah, it's like, oh, yeah, no kidding. It broke, you know. Oh, really? You're the one who suggested this piece of me. Not me, you know? All right, so last question. Bonus round. You ready? Yes, sir. Okay, I want the craziest diligent stories with no names you've ever had. It was a crazy diligence because it went great. It went terrible. There was some. Something. There was some. I will tell you. Here's. Here's a good. I got sent by my boss once, this is many, many years ago, to a particular customer for a two week implementation. And the CTO had Tourette's. Oh. And it was the craziest two weeks of my life. And I mean, just would burst out whatever. The funny part was, by day three, I didn't even notice it. And he would literally be swearing at me in the middle of, you know, like, talking about some code base, how we're going to install us, whatever, literally. But it was the crazy craziest, literally the craziest two weeks of my life. I mean, confession time. I shouted code bases too, right? So I can relate. Yes, of course. Right. Because it's their fault, not ours. I mean, we've done this for a long time, right? And so we've seen a lot. I just wanted to write a book about it also. Maybe at some point do it gray. And it's a privilege to do what we do, right? So we see very, very good stuff. And we see also maybe not so good stuff. I think the. The first takeaway should be, is it within reason? Right. Can it be fixed? Sometimes. And I'll give you two examples. Two similar examples. We once looked at an ERP that we actually terminated for two different clients within 15 months. It was a commercial ERP or they wrote their own. It was their own. Okay. It was a custom ERP that said their claim to fame was cloud and every sector. Da, da, da, da. And you can like configure your workflows and whatnot. We looked at for the first client. This was like when Covid just hit. And we looked at the architecture and it was just not ideally designed. It was super unsafe and stuff like that. So we didn't. It's a fairly quick abort. We saw many, many very, very hard to fix red flags like architecture did. You're saying, like bond level difficulty. It was not great just to insult an old ERP. And then 13 months later, another fund reached out. And this fund, we knew what we were getting into. And actually the sales advisor actually didn't want us to work on this, but the fund was like, no, of course we want the best. And I mean, not to toot our own horns, but they consider us the best. So they're like, no, we want the best. We want to work with code and co. It's like, great. And then we said, look, we know you guys from back then. And even then we said, there's many things you can do and can't fix, right? So we gave them like a value creation plan and we were like, like 13 months later. Let's just focus initially on the delta between what we learned back then and how has it changed and evolved over time, right? So give the benefit of doubt. Deal went along. And the night before signing, literally the night before signing, you know how in vdrs you get like email notifications every day? It's like 248 documents were uploaded and so forth. You click on, you go through the index of what's new and everything was named perfectly. 1.2.3.4.5. And then the name of whatever the document entails. So quick, quickly glancing at the headlines and going through it. And then there's one document that just had, like, gibberish, like somebody like vomited on the keyboard, basically. Just random characters and random string, like, whoa. And if they had named it perfectly, I probably would have missed it, right? But honestly, and I saw it, I was like, this is weird. Clicked on it. And it was the pen test we had recommended 15 months ago. So I had never done a pen test. And it was, I mean, as red as it gets. All the things we found in terms of architecture debt and cybersecurity issues were documented. And I was like, no, this is hard, hard to fix. And it was hilarious, right? Funny enough, like, this pen test provider doesn't have like a, like a red, green, yellow kind of thing, but they use bombs, actually, for highlighting stuff. There was like three bombs. It was a lot of bombs, man. They looked terrible. And then we reported our client, who was actually on, I think the Maldives or so on vacation. And I remember that his sunburned Face palm trees in the background. We had on the call and he's super angry because it was the night before signing, right? And we just ruined his vacation. It was on a board. And the reason for it was not because it's not. Not fixable, but because you lost, lost trust in the other side, right? They obviously tried to trick us, I guess, hey, we uploaded our penetration test. Your advisors didn't care or didn't see it or so. Right? So. And ultimately we're all in a relationship business. In a trust relationship business. The beauty of tech is this helps me get off bed in the morning is most gaps can be mitigated, right? That's the fun part of this, right? But if there's someone on the other side who has proven to not be honest about this and try to trick you, that's not a good start to a relationship. That was a quicker board example one and the other example is quite similar. And then I hand it over to the team is I'm happy to give that story because one office was also my hometown in the Black Forest area, a small town. And it was funny. So this company, a very cool company, manufacturing space, they built a very specific ERP CAD design kind of thing. And we did a workshop. And the workshop was literally a history lesson on the development of computers, right? Starting with calculus and whatnot and how everybody went wrong. Like, the CTO was very, very opinionated. I think it was a fascinating presentation. I learned so much. It was like a history lesson and with the grass of popcorn and all that stuff. Stuff. And his take was how everybody went wrong when it came to development of libraries and frameworks. So he built his own framework, his own programming language, his own compiler and whatnot. So the whole stack was custom, it was closed source. We got access to. It was not GitHub, it was something else. But whatever the version control platform or source code hosting platform. And it was nine maintainers. And I mean, that was like, like the mother of all key person risk, right? Oh, good Lord. And the funniest thing again in mindset thing, this is why I want to use this as a second example. He is. It was not like, hey, guys, we understand this is a bit exotic. We have a plan, a strategy, how we can mitigate this over time. It was more like, no, you got. You guys are wrong. The whole Internet is wrong. We are right, right. And this was again, a bit of a trust mindset kind of issue that led to our client aborting. But that was. That was two examples I had on top of mind. So just to show you how I think, I think that era has gone but I've had two of the exact same thing with the developer. The whole stack like the whole programming language. Like programming language, frame, everything. It's like. And the same thing. They had an opinionated why and in all cases these guys were super bright. But it's like I could kill this company just by, you know, buying the guy a good lottery. You need a five plus five year vision, right? Yes. Like even if you have comfort with this, can you with that team and It's a massive 20 year old code base, can you realistically build something new or do you just waste resources on. On maintenance, tech rejuvenation so there's. You lose the opportunities. Right. So is this going to be interesting for the next investor? Likely not. Right. So what's your story? I mean we have seen this multiple times actually. Right. As well it wasn't the only time where there was like a custom programming language. And I think in all of these cases they had a pre made presentation defending the reason why they have it. Which shows you that they need to defend it. Right. Because people always say well do we do that? Right. It's not like we're the first ones that say oh it's not a good idea. Right. So I think that's interesting that they already had this off the shelf. Right. This like the reason why we did this kind of presentation. Right. Why you're wrong ppe. So there was like. And then it's obviously hard to explain this to the, to the, the later you are in a deal, the harder it is to convince the investment team to abort. Right. Because obviously there you spend a lot of money. Right. And you are very invested into that and a lot of time. So I think that's never a great discussion but we don't shy away from it. Right. So another example, I think it's great looked at the company, very small company, it was an add on for a large group we do a lot of work with in Italy and there was a cool software stack again like another very specific from Italy. Really? Did Stanley Tucci figure it on his walking tour of Italy or something? Very, very niche European. And the workshop that we did showed case that they only had like three developers but realistically they needed like I don't know, nine or even more. Right. Two of them were actually hired just recently. So obviously key person risk. But most more important there was a mismatch between how profitable the company should be. Right. So the founder. Exactly. That was Great for him because he took out a lot of money over the years. Right. But that means that, that on an ongoing basis you need to triple development team suddenly EBDA negative and then therefore also the valuation mismatch is too big. Right. So that's something that we actually see oftentimes, sometimes even the other way around where tech team is too big, which is obviously something an investor then likes to see because it means that you can maybe buy something cheaper than it should be. Right. But that's the double CTO problem. As you know, it's either they're so maniacal that they're firing somebody within the first two days if they're not up to speed, or yeah, we hired them, let's. We'll find something for them to do at some point. Right. You know, that's why you find these people who are, you know, that was a, that was. I won't mention the company. One of our. We had a developer working on something for a customer once and when we called the customer, they've worked on it for a year. There's one developer on a feature and the customer's like, no, we didn't want that. We said no. We got the email like, yeah, we heard, we talked about it, but we didn't need it. This one poor one guy kept going, I think I should be working on this thing. And literally there's like the thing in old German companies when they do software is called the hotline, which is like, do you know, have product management? But there's literally a telephone number you can call the developers, just ask for stuff and then they just build it for you. Right, good. That's hard now. Good God. And that is like, I mean, obviously cloud picks up nowadays. I have a phone, I just call Claude. It builds things and then you can see what the software, you can imagine how the software looks like, right? Suddenly like every, every customer can just wish for stuff, right? Oh yeah, we've seen tons, we've seen tons of those. I mean, our best, our best product managers tend to show a really good roadmap app. And then the, the customer, their customer is like, oh, I love all that stuff. And then they say, you can't get it unless you stop asking us for these one offs that you don't actually need. Right? Because that's, I think a lot of the times customers do think they need these one offs, right? Why does that happen? Because we went through the ERP BS world where every ERP product had best practices, so you might as well adopt ours, right? Which was. Are they. I don't know. For every business has their own unique. Like a manufacturer, you know, why do they customize the ERP system in some cases, because they have to, because it doesn't match their business. I think also, Jim, what you said earlier that, like, product management is more important than ever. I think this is 100% exactly. Like if. Because Claude is exactly the same thing, it will build what I ask it to build. Right. So it doesn't necessarily mean that I should build it. So the step between I can now build everything, but I shouldn't. Right. So really qualifying what you should build is more important than ever. Right. But it'll become. And I'm not leaving you out in this, Craig, because I know you're ready to answer this question. Right? No, no, no. But that's, that's the other crazy part, which is a bigger topic for, I think for another day in terms of what I see happening is because you can build more stuff. Are we going to get into a phase where we can do more customizations for the end customers of the software companies? I ended up writing my own exercise tracking application. I posted in the App Store. We did a video about it. Not because it's a Goldilocks problem. I've been training a certain way for my entire life and no app ever for, you know, now every exercise app on the App Store is some positive guy named Bryce trying to get you to do, you know, forget it. I have my old. I just want to check the stuff off. Right. But would I have wasted my time trying to do that two years ago? No, because I haven't written swift. I mean, I wrote some objective C, but I'm not a swift. Like, I built the thing in a weekend. Yeah. Yeah. I was hoping you would do like a martial arts training app. I did. I said, yeah, it's years ago. It was in the. And I'm. I'm redoing. But it was in the Apple. It was. It was called Wabisabi Kumite and it was in the App Store for years. But I took it down to rebuild it because now it's like, well, now I can rebuild it. Do it. Yeah, it was an interesting little exercise. The fight for attention. That'd be cool. It was interesting. It was an interesting app. I'll just point out that way. But now I'm like flooding myself with that. But now we get to this problem of. I do think it's really interesting. Can software products themselves have pieces so we can customize by customer and still make it Supportable. I think that's to be crazy. But it'd be super interesting and hard due diligence, I think. All right Kirby. Best and worst. So I would just say I was going to go like most wild diligence. My answer be a little bit different. It's just so you kidnap thrown in the back of a. May your most wild diligence be the one of your own company that's getting diligence. And so whenever we had sold our startup it was an add on. It was done not by Code and co but by another major U.S. firm. And I got the chance to. You can't help but not try to sell. Also you're high integrity but you also may have just written a business continuity plan last week and you're going to put it in the vdr. You're going to be there. But the thing that I thought was interesting is I now do this every day for a living. I'm passionate about it. At the time I was just experiencing it and I just saw what can happen, what can be missed. They did a code review. Our CTO Travis flashed the code on screen for two minutes. They said code looks great. Great and moved on. The colors were night. It was intended and I was like, I'm sure he picked a really hot spot to show them, you know. And I was like I did a demo, you know, but then part of it, you know, like was the demo in sketch, you know, sketch at the time Figma, you know, like was it live? You know and they're like demo looks great. And so I had the chance to see the report two weeks ago. I was talking to, you know, the firm in there. It was two weeks ago? Yeah, it was two weeks ago. And we were having a conversation about. Because I'm talking about Code and co, how we're thinking different, you know, like whatever, whatever. I read through it and I thought, man, this report sucks because it would have helped for some of the things we wanted to happen, like a better integration, like how we were going to try to come into the platform company to truly been in there. And so that was one thing. But then it just made me laugh because it said the co founder, your least product is an above average product manager. And I said okay, well at least it wasn't just average. Yeah, take it. So I'm taking it. All right, thanks as always. Fun cast fans. They now where can anybody who's looking for help find you guys? We're everywhere. Our goal is to be on speed dive for all things tech. Right. So we've been very, very privileged to work with many funds across the globe for a long time now. We have, you know, since April, an office in New York, headquarters are in Berlin, Germany and then we have presence in London and Paris. Team is distributed as a remote native organization ourselves, which is one of the beautiful things of technology. Tech is tech is tech and it's inherently global. Right. So we've been, you know, as you said, as you showed, very, very excited and privileged to work with you since 2021, I think. 2021, yeah. And as such, how can you find us? Good, good. You know, find us on LinkedIn, find us on via our website. Maybe you can even link our website in the speaker notes. Oh no, they'll be linked. You'll have a full page. Amazing. Fantastic. And yeah, we're here. Awesome. Well, thanks as always, Kirby. Dan Lucas is always a pleasure to see you Fun Cast fans. We'll see you next week. From the heart of Chicago to all over the globe, couple private equity geniuses. They share what they know. They love to mess with technology. Where the future is sink or swim. It's the private equity fund Cast. With debt, technology issues, middle market, PE backed companies. They bicker with each other and they don't take themselves too seriously. It's not venture capital, it's private equity. It's the private equity Fun Cast. Pour yourself a drink and have a seat. Neither this podcast nor any of the information contained here constitutes an offer to sell or a solicitation of an offer to buy any security or instrument in or to participate in any Parker Gale Fund or other investment vehicle. Past performance is not indicative of future results and there is no assurance that any Parker Gale Fund will achieve its objectives or avoid significant losses. This podcast may contain forward looking statements. Such statements are subject to various risks and uncertainties. Parker Gale is an investment advisor registered with the United States securities and Exchange Commission. Registration with the SEC does not imply a certain level of skill or training. Guests appearing on the podcast may or may not be a financial sponsor of the podcast or an episode of the podcast. Parker Gayle may have business relationships with certain guests, sponsors, or organizations mentioned during the program. In some cases, guests or sponsors may provide services to or receive services from Parker Gale, which creates potential conflicts of interest. Any sponsorship of this podcast does not imply endorsement by Parker Gale and is not provided in exchange for, nor intended to solicit business between the sponsor and Parker Gale. The appearance of any guest does not constitute an endorsement or testimonial of Parker Gale or any fund. For additional information regarding Parker Gayle, please refer to Parker Gayle's website www.parkergale.com or form adv available@advisorinfo.sec.gov.