As aspiring CEOs, I suspect many of you will at least consider purchasing and operating a software company. Before you do, I implore you to read (or listen to) this post, as it represents one that I sincerely wish I had the opportunity to read in 2013, before I purchased my own software business. This will be especially true if you have a non-technical background, which certainly described me all those years ago.


In today's post, I explore the signs and risks of "Technical Debt" that may reside within a company's code base that all prospective acquirors must vigilantly look out for. "Technical debt" essentially refers to the accumulated impact (measured in time, cost, and required rework) of product and engineering decisions that prioritize speed over quality and scalability.


Though technical debt seemingly starts out as a technical problem, it can quickly accumulate and become a significant business problem. Too much of it can significantly impair the ability of an acquiror to grow the business in question, and can necessitate additional time, cost, and energy not originally contemplated in the initial investment thesis.


This was my experience. After acquiring my own software company, I quickly came to learn that the company had way more than it's fair share of technical debt (this despite a comprehensive technical due diligence process), and as a result, I often felt as if I spent my first 2-3 of operations trying to untie a knot that my predecessors had spent the previous 20 years tying.


I don't want this to happen to you, which is why I wrote this piece. I also deliberately wrote it for the non-technical reader. Before you acquire any software company, please ensure that you use these points as part of your product due diligence process, so that you don't experience the feeling of drowning in technical debt, as I did between###-###-#### at least).


Link here. Please enjoy: Considerations Unique to Acquiring a Software Company (Product)