One of the greatest challenges in evaluating a software business, particularly one that has a number of years and a lot of miles behind it, is understanding where the bodies have been buried in the past. 

Technical debt is the term that's been ascribed to having to pay for the sins of past product development. Unlike financial debt, however, technical debt is not usually a conscious decision. There is no moment where you say "I'm borrowing three days today in return for paying six days tomorrow." Furthermore, there's no clear way to calculate how much debt you've incurred and how long it will take to pay it off. It accrues out of sight.

When you buy a software business, there will no doubt be trouble lurking in the product that you'll end up paying more for than you'd expected in the future. It is the nature of the beast.

How do you, as a buyer, get visibility into the magnitude of the problem you're taking on?

Be Willing to Ask Lots of Questions

Before you ever get to LOI and any kind of formal diligence there are a number of ways to sniff around the work to date. Here are some questions you can ask during initial discovery to surface potential issues:

- Have you kept all of the components up to date / Are you running on the latest version of the language?