This is the third article in a series of articles on technical debt, one of the biggest areas of risk for searchers buying a software business. The first article was an introduction to the topic. The second article described the different kinds of technical debt. We're focusing most of this series on the acquisition process.

We've talked about known and unknown technical debt. How do you find out the existence of technical debt during your evaluation process, including diligence?

Prior to LOI

Understanding what technical debt may be lurking prior to full diligence can be a challenge, but there are questions you can ask as you're speaking with the seller to get a sense of how the company operates today. Here are some warning signs to look for early in the evaluation process:

- Significant manual processes in product delivery: Good software teams solve problems twice. The first time might be manual, but the second time they write software to take manual steps (and possible errors) out of the mix. Often times you can find these kinds of issues in customer onboarding. "Joe does this, then sends an email to Susie who does that, then finally Jim does the other." Ask the seller: "Tell me about how you onboard a new customer."

- Lack of a formal product roadmap: In nearly every diligence we've done for searchers, the lack of a product roadmap has been a leading indicator of an underlying ball of spaghetti. There's something about writing down where you're going, even if it's high level, that helps everyone make better decisions. Without it, the tendency is to make short-term decisions repeatedly. This is the breeding ground for technical debt. Ask the seller: "Do you have a 3-9 month product roadmap that you communicate to customers or use to manage priorities internally?"

- Lack of documented product architecture: As with the roadmap, writing down how all of the pieces fit together often times forces you to make better decisions. Seeing it before you implement it (or even as you're implementing it) exposes flaws in decision-making that can be corrected earlier. Ask the seller: "Is there a document or diagram that shows how your system works?"

As the buyer, you don't have to necessarily know what a good product roadmap looks like, or what the architecture diagrams mean. Simply asking about them, and having the seller walk you through them, will give you an idea of how the team operates today.

After LOI

Once you're well into the diligence process with QofE and legal, having a reputable firm conduct thorough technology diligence is the best way to limit your exposure to technical debt. You should expect that your diligence provider will document areas where technical debt is present, as well as rough estimates as to what it will take to address the issues. 

Financial estimates, even if only directionally accurate, let you and your investors make informed decisions about the ability to address issues post-close. It may mean that you pay less for the business, raise additional money to address the issues, or even walk away (though this is rare in our experience).

Every software business has technical debt. Decisions are made in the moment that seem right but later don't make any sense. Or there is pressure to deliver to a customer and shortcuts are taken. Because the businesses you're buying as a searcher are nearly always bootstrapped, technical debt will likely be a part of the purchase price. The only question is whether you will know the price before or after you've bought the company.

In our next (and last post), we'll talk about how you pay off technical debt. Stay tuned!

Have questions or comments? Let us know in the Comments section or reach out to us directly.