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 often accrues out of sight.
When you buy a software business, there is almost always trouble lurking. Even the most well-capitalized, well thought out products have issues that need to be fixed later. The business changes over time, people come and go, and it's easy to take shortcuts along the way.
In the next few posts, we'll explore the different kinds of technical debt, discuss how you as an incoming potential owner understand the amount of debt you're taking on, and finally how to think about paying the technical debt off.
As you search for and evaluate software businesses, fully understanding technical debt will help you prepare to face the challenges after you've acquired your company. Stay tuned!
I think that I am noticing that even without technical debt, tech evolution is causing rewrites so fast that the special burden of technical debt is something I would consider less of a special cost. That is, if developers need to invest 30=40% of all their time refactoring anyway due to evolution, then it might not be a big deal that with big technical debt, that amount might be double.
My company has been working in Web development, simple php/mysql/javascript with different frameworks. The frameworks have changed. The big 7 tech companies are innovating so fast, they are setting expectations for users. It leaves the little guys forced to build on their services.