Technical Due Diligence with Code & Co.
Adapted from a recent PE Funcast Episode
[Jim Milbery]
I am here with Lukas and Dan from Code & Co. We've worked with you on several projects, and we're about tech due diligence today as part of a broader overall diligence as you look at companies. Lukas and Dan specialize in tech diligence, so I thought they were the perfect guests to discuss the ins and outs.
Maybe you can introduce yourselves, talk about Code & Co, and then discuss how you chose to focus on tech due diligence for private equity guys.
[Dan]
My name is Dan, and I am one of two founders of Code & Co. We founded the company seven years ago, and we specialize in tech and product due diligence, and even more so, we focus on private equity and growth funds. And thanks to our industry, we can do so remotely. So we're a remote-only organization, and we work with funds worldwide.
[Lukas]
My name is Lukas, and I am a cofounder of Code & Co. I worked as a software engineer at ThoughtWorks before founding Code & Co.
[Jim]
How did you both meet?
[Dan]
We met around 2010 or so. Lukas and I were at the same VC office begging for money because we both had founded a company and were raising funds. I did something in digital publishing, Lukas did something in e-commerce, and this is how we met. What's funny is that we clicked personally, but professionally, we went our separate ways. So I did an executive MBA at UC Berkeley and the Technical University of Munich and then joined Rocket Internet in Berlin as a director of products. I built several companies from scratch when Lukas was a software engineer at ThoughtWorks. We continued talking and always figured we wanted to do something together. In 2016, we discussed building something around understanding software and building technology; hence, Code & Co was born.
And I think the story about how we came into doing tech diligence is also quite interesting. We played with a bunch of software solutions, but then a friend of ours, an M&A adviser, reached out while raising funds for a company. And he didn't understand what it did. He said, "Guys, you know technology and business, so help me translate." We didn't know to call it due diligence, and since then, we have used our network to grow the organization.
[Jim]
So let's talk a little bit about your methodology. We buy founder-owned software businesses. So our focus is on the software as the product. Before ParkerGale, Devin and I were in other funds that did other deals besides software, such as healthcare and manufacturing businesses. We also did technical diligence on those deals, frequently leveraging packaged software, so we had very different requirements. For example, we owned a company that made metal roofing products, and they were on Epicor as their ERP platform. So, they didn't do any custom software development in that case. We focused on finding guys who knew Epicor to ensure a proper implementation. You primarily focus on software companies instead of technology at non-software companies. Would you agree?
[Dan]
Absolutely. We focus on software and do everything from deep tech, AI, ML, big data, cybersecurity, and API life cycle management, to tech-enabled offerings such as IT services. Ultimately, we always say we look at companies where tech is the product or could be the product in the future or where tech plays an integral part in accelerating the value. In the case of an IT-enabled service, they have internal software or they have accelerators they can use. So quite sector-agnostic, but yes, the software is the key.
[Jim]
If you're a manufacturer running a commercial ERP system like SAP or Oracle, I would still do InfoSec diligence and focus primarily on finding somebody who knows that ERP system to audit. I would say the tip of the spear at this point is, no matter what, you should be doing InfoSec diligence. Is that fair?
[Dan]
Yes, it's fair. In addition to that, we're not big fans of something that people could call IT due diligence or pure digital due diligence. In the end, humans build software, and teams scale software. And then users use software because it alleviates some pain points, right? And so we don't want to do just an IT due diligence that assesses a company's phone systems and file servers. We're trying to optimize for impact and look at the opportunity that the company is pursuing. Tech plays an essential part in value creation in most deals in product due diligence these days. Hence, we believe it must be a holistic, modern, and actual assessment comprising technology, product management, and engineering. We define product management as the art of knowing what not to build. So this means can a company allocate its resources effectively? Do they make something worthy of the customer's attention? Does it alleviate a pain point? What interfaces do exist? Do they have the data to back it up? What's the plan going forward, product vision, and road map? And what's the customer onboarding process like? And tech - very much the hard facts from architecture to infrastructure, automation and monitoring, scalability, and single points of failure. You mentioned security, and we look at that, too, of course. And lastly, engineering, which is people and processes. Who's missing? Or maybe who should not be lost by the company? Who should not leave the organization? Software development has a life cycle so the keyword would be agility and fast iterations.
[Jim]
Most employees will not know there's a sale process going on officially. The chatter spreads typically the closer you get to finishing a deal. But in reality, we're trying not to engage with everybody in the firm. Because that's true, there are just some things we won't spend time on. You focus on critical systems. So as I divide these things into pieces-- if you're buying a healthcare company, you will focus on their EMR and EHR systems, and you're going to get experts who know those systems. If you buy a manufacturer, you concentrate on their ERP and supply chain software.
[Dan]
Oh, 100%. You want to make sure that everyone spends time wisely. So as you said, the guys that you're looking at, you're talking to them because they built a successful business. And the idea is that you can accelerate the value these guys have generated even further by partnering with you guys. But in the end, they are already quite successful. Otherwise, investors wouldn't look at them. And hence, we aim to optimize for growth opportunities and ask the most critical questions that identify opportunities for additional growth and highlight potential key risk drivers. What I love about my job, it's we get to be constructive and forward-looking. And the truth is, in tech, most things are repairable. You can almost always fix software; a gap today could be a significant strength in the future if guided by new investors. And in tech, there's no one golden path to achieving a goal. Tech is very much the art of making decisions and managing their impact. You are never really finished with product development. So in the case of a due diligence process, you want to ensure that you focus on the stuff that can make a difference in the future. You assess the foundation of what brought them to this conversation they have with you today. But then also ask how investors can accelerate growth or value creation in the future. And another truth is that the PE industry is quite competitive. Sometimes we have seven or eight funds reach out to us and ask whether we're already conflicted about a deal. And so, relatively few notable companies and investment opportunities are on the market. We know how in demand a target is, which is quite fun to realize from our perspective. Due diligence is necessary, but what's also important is keeping their business running. And what's most important is finding a work mode to collaborate in the future if you guys agree on a partnership. And we're in this position to ask the questions and, hopefully, advise investors like you ahead of making such investment decisions.
[Jim]
So I can't entirely agree with you that private equity always adds a ton of value. Let's not oversell that. I would say it this way, if you're investing as a private equity firm, you want to have deal partners that can find deals and close deals. And my partners have forgotten more about transaction stuff than I'll ever know. We buy software companies. I'm a software guy, and my job is translation. I don't know any portfolio company employee's job better than they do, and I never will. I know a little bit about many different technologies. But in general, what is my job? My job is to translate. My job is to look at technology in three categories: risk mitigation, cost reduction, and revenue enhancement. As you identified earlier, we focus on risk mitigation in the early stages. Most often, the most significant risk is singular points of failure within the team. A couple of people are so instrumental in pieces of this thing that if they get hit by a bus or captured by a sharknado, we will be in trouble. So often, we'll need to focus on cross-training and documenting in the early stages of ownership.
Cost reduction is taking costs out of systems and the business. We focus on it, and there is real value in focusing on cost reduction. Cost cutting means much more than cutting staff; it often means helping customers cut costs using our software. But the big driver is revenue generation. How do we provide new features, functions, and modules that will get us new customers? Can we add features to get more wallet share from our current customers? That tends to be a sweet spot for smaller focus companies. Now, if you're a giant conglomerate like Oracle, you got a zillion products to sell. It's not as important that everything fits together. In our case, we must ensure that we're doing things around the edges of our current product. I'm comfortable engaging you guys to do technical reviews of our portfolio companies because we speak the same language. And one of the things that has been great about your team is that you guys are pretty flexible about code bases. You get some technologists that want to see everything rewritten in what is the latest and greatest, right? So you engage some diligence firms, and they'll say, "Well, this thing doesn't use MongoDB, so it's terrible. A significant portion of the world's software is probably still written in COBOL, Java, or PHP. There are many legacy languages out there that are still okay. My job is translating that to:
Do we need to deal with this at some point? Maybe.
Do we need to deal with it now?
Do we even need to deal with it over our investment horizon?
Can we chip away at it?
Is it a Big Bang replacement?
We speak the same language, can converse, and quickly get to the nuts and bolts. Do you deal with firms, or how do you deal with firms where the partners are not technical? How do you translate what you do into an understandable or digestible format so they can make a go or no-go decision?
[Dan]
So back to the value question. I believe that, in the end, tech is an enabler of business success. Hence, you can use multiple technologies to solve the same problem. You probably want to ask whether potential hiring constraints may happen in the future. For example, if you look at COBOL, the people that know COBOL are dying out because it's not very popular anymore for new development. And regarding the translation, I'm grateful you bring this up because if you want to remember one thing from this podcast, we want to function as translators between business, finance, tech, and product. We have clients who are very tech-savvy like you, but we have clients who are not as tech-savvy as you. And we want to make sure that they understand what we assessed and why we assessed that. Something that I consider pretty important is that we don't claim to be the smartest people in the room.
Ultimately, we have the benefit of asking dumb questions as outsiders. We've seen 250-plus companies or so in the last seven years. So we've seen a fair bit of deals, but obviously, we're never going to be as good as the guys who have been doing this for decades at a time. We had a deal in the US once where we sat in the conference room, and the guys in the room were longer at this company than Lukas, and I had been alive then. So sometimes you have very senior, experienced professionals, and in the end, our job is to translate between the worlds of business and finance and tech and product. And as outsiders who have seen a lot and can ask dumb questions, we can also help the company identify something they may have overlooked, having been in the trenches for a long time. I think we all have the benefit of just being new to a business and bringing a fresh perspective.
[Jim]
Besides translation, I think what you and I bring is that they haven't seen 250 other companies. They are laser-focused on something they believe is a huge problem or an issue that you would say, "We looked at 250 other companies. We've seen scalability issues like this before. It's not a killer."
[Lukas]
I just wanted to add regarding the translation that in the end, yes, you do due diligence because if you borrow money from lenders, they also ask to see your due diligence. So it's almost like the customer or recipient of our product is the investment team and other stakeholders like lenders and insurers. So translation is also necessary so that whenever we write a report, we try to translate not just to you but to everyone in the deal process. We have seen other due diligence reports where the authors thought the more technical the description, the better. But often, it's the other way around where you want to make sure that you address, translate, and put into context whatever you find in the language that lay people understand because you never know who will end up seeing this report. And also, the report is not going to die. You might leverage the report as preparation for when you sell the company. We've seen so many scenarios that we recognize patterns between companies that others have overlooked. As Dan mentioned earlier, there's not one right way of achieving a goal in tech, and that's the beauty of it. And the great thing about it is that the software companies' customers don't care about the technical implementations. They want a product that works and fulfills whatever need they have and the reason for them to buy the product. So for us, it's all about balancing all those things and finding common ground.
[Jim]
Many people didn't do sufficient due diligence on FTX or JPMorgan's acquisition of Frank. How much diligence got done in both of those cases? Not a lot. And that can be one of the challenges with multiple investors working on a single deal. You've got a lead investor that says the deal is good, and if you're trying to glom onto that deal, you may risk getting kicked out if you ask too many questions. That's one of the reasons we're a "control" buyout shop, and typically we are the only investor. We may have some co-investors but are lead investors, so we determine what diligence gets done. How often do you find yourselves in a situation where, of the 250 companies you've looked at, you've had to say, "Guys, there's some real hair here."
[Dan]
Depending on the process and the investor, there's no cookie-cutter approach. So some investors are willing to take out more risk. Some clients do, in our opinion, a bit too much DD in the sense that they're just too slow and try to turn over every stone, which may not be overly helpful. But with other clients who are super fast and say, "Look, we are comfortable with a bit more risk because we believe we can fix that." And I think tech is mostly healable.
Yet, we've shut down deals due to hard-to-explain red flags. There is a deal we looked at twice in the last couple of years. It was a B2B software that raised funds for a forthcoming cloud strategy. However, we didn't believe in their cloud mindset when we assessed them first. There were some architectural gaps and some fundamental security holes. So our recommendation was for them to abort the deal, and the fund did, but then 13 months later, another fund reached about the same company. We went into the review very open-mindedly and explained to the target: "Hey, we want to understand your potential. So what happened in the last 13 months?" And frankly, nothing. That tells you how much value you can generate with this team. And then, the day before the potential signing, the group uploaded a pen test under a very random/obscure name. They had done a pen test after we asked them to, and it was very dark red. Architectural debt is costly to fix, and they tried to hide it. They tried to sneak it by us, but we found it, and it was a huge wake-up call also for the investor who ultimately aborted the deal.
[Jim]
Could you define architectural debt for our audience so they understand it when they see it?
[Lukas]
Architectural debt is a subcategory of technical debt. Technical debt, in the most straightforward way, is a sub-optimal solution to a problem you have today that you will need to fix in the future. So it is almost like borrowing money and then paying interest on top of it. If there's too much interest, this could slow down the organization because your "interest" costs are too high. Adding new features becomes too difficult. Architectural debt is fundamental and means you have a technical setup where the foundation is wrong. This debt hinders scalability and security, and it's almost impossible to fix because you have to switch out the basement of a house while you still live in it.
And then there's some technical debt that can make sense because time-to-market constraints are often a balance of decisions. Maybe I have a subpar solution today because I want to try out something instead of building this for two years without shipping it to customers and then getting feedback if it's solving a problem. I shipped something fast to ensure people got it into their hands. This technical debt is easily healable if I address this at some point down the road.
[Jim]
I'd add that if they've written their own framework, that's usually a bad sign. Homegrown frameworks often have heavy technical debt attached. Part of the reason it never works is that if it takes you two years to rewrite the product, the customer's requirements will probably change while you're doing it. So you're chasing an endgame that you'll never get to.
Moving on, If some company is about to be sold or thinks about selling to private equity or venture, what's your laundry list of stuff that you would tell them to get in place?
[Dan]
It depends on the maturity of the company and the sector. If you're in an industry with many regulations, certifications answer many things regarding security, maturity of internal processing use, etc. We're pretty happy when you deliver an architecture diagram with information on the technical stack, what kind of database is in use, infrastructure deployment, and a pen test. Somebody besides you has verified your system's security or tried to break into the system and confirm that everything is more or less solid. Then from a product perspective, I'd love to see a road map. I don't care about the timing; I want to see that there are themes and initiatives that the company is working on now and that there's more coming in the future as well as a methodology in place backed up by data to understand what they're going to build next. An organization chart is helpful because sometimes companies don't even have product managers. So they have an R&D department, but they don't have customer support people, and the developers act as the hotline, which means it's difficult for them to carve out time to deliver focused work. Ideally, there are tons of best practices, such as DevOps. If you provide that, that's already a good baseline.
[Jim]
I think falling out of the practice of documenting all that takes commitment, in my opinion but keeping those things up to date makes it way more manageable when you get into a diligence conversation, right?
[Dan]
100%. I think one of the key challenges in building a successful business is hiring. And you need to have some documentation to ensure new developers can join the team properly and get on board quickly. Investing in up-to-date architecture diagrams is essential whether you are in an M&A event or not. You want to invest in keeping these system documents current so everybody has a shared lingo for discussions. We just wrapped up a project a few weeks ago that was a company with 75+ developers, and they didn't have a single architectural diagram. We often discover that even when it's a professional process, such as an M&A adviser or an investment bank supporting the seller, we often find the tech side of the deal book is fairly underwhelming. It's pretty surprising how even in tech-first organizations and in professional M&A processes, technology continues to be an afterthought.
[Jim]
That's very common, and sell-side investment bankers typically don't have technology specialists on the deal team. And the sell-side investment banker doesn't get to pick the technical diligence provider; the buy-side bankers and new potential owners make this choice. You won't trust the company's banker to do the tech due diligence on your behalf. If you're not doing that work to keep that stuff up to date daily, you will be scrambling when it comes time to sell the company.
Troubled that Jim knows about a move called Sharknado. The rest, though... pure gold.