This is the fourth and final 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.  The third article described how to uncover technical debt during the deal process. We're focusing most of this series on the acquisition process.

We've talked a lot about the different facets of technical debt, but the big question is: How do you pay it off? Via scheduled and (less preferably) unscheduled payments.

Scheduled Payments

In many ways, paying off technical debt is a lot like paying off credit cards. There's a common approach to paying off credit card debt called the snowball effect, where you start with the lowest balance card and pay as much as you can each month on that, while making minimum payments on the rest. Once you've paid off the lowest balance card, you apply all of the funds to the next lowest balance card. And so it goes until all of your cards are paid off. The theory behind this approach is that you get "wins" early in the process, which encourages you to keep going, as opposed to starting with the largest balance and potentially quitting mid-stream.

The same methodology can be applied to technical debt. You're likely going to have some large, gnarly issues as well as some more simple issues to tackle. Starting with some of the more simple issues, and including them in your regular development process alongside new features starts to create the snowball effect. As long-standing issues get fixed, everyone sees the results and understands the organizational commitment to making the product better.

As you get to the larger issues, there is now a culture of fixing things that need to be fixed, but doing it in small, manageable chunks, all as a part of how you operate.

Unscheduled Payments

Unscheduled payments are like the letter from the IRS telling you that you owe $50,000. You find a previously undiscovered mess in the middle of a key feature or customer delivery, something that must be fixed right now. It can set your delivery back weeks or months, cause lost business and customer churn. Simply put, it can be devastating. Unscheduled payments caused by unknown technical debt have been the death of many seemingly good software businesses.

Additionally, dealing with these issues in a crisis often creates more bad decisions, leaving you further in the hole. 

Thorough technical diligence can help you understand the areas of the application where unscheduled payments might come from. It doesn't mean that you know exactly the scope of the problem, but understanding the likely points of risk, along with bracketed financial impact, is a significant step forward. Things such as heavy customization for each customer, inefficient and unreliable ways of moving data around the system, and a significant number of manual processes are some of the warning signs that trouble is lurking.

We hope these posts on technical debt have given you additional insights into one of the key areas of risk for buying a software business. Just like anything else, the risk can be managed by doing your homework early in the process and working with diligence providers who have run small to medium software businesses. There's no substitute for battle scars and experience.

If you have questions about a company you're looking at, even if at the IOI stage, please let us know. We'd love to arm you with questions that you can ask early in the process to get a sense for what you're buying. Please leave a comment in the Comments section for this post or reach out to us directly.

Stay tuned for more articles on buying software companies as a searcher.