Considerations Unique to Acquiring a Software Company (Product)
December 23, 2021
by an investor from Harvard University - Harvard Business School in Toronto, ON, Canada
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)
from Carnegie Mellon University in San Jose, CA, USA
People who lived through technical debt would understand the severity of risk and growth ceiling a company is exposed to due to this. In a physical product or service business, one of the top risks is supplier concentration. Supplier concentration translates into old tech stack and aged product. Many sellers will skillfully avoid the age of the product. For example, many old software companies will call themselves SaaS and cloud software. SaaS is a business model you adopt and not a representation of the scalability of the business. An old product in Cloud is a change in the product delivery model - unless it is rearchitected as a cloud-native product (e.g., a multi-tenanted, easy customer onboarding, customer self-administration, etc.) the implementation and support expenses will only increase.
Changing an old tech stack is extremely difficult. Existing employees will be uncomfortable and likely you need to swap developers with new tech knowledge. You might need a new architecture aka rebuild with some reuse of old components vs fixing old products with more support needs - this is equivalent to building the product from scratch. Often it is a long and painful heart surgery in a software company.
from University of Texas at Austin in Houston, TX, USA
^redacted We offer technical due diligence for SaaS/Software based businesses at Rapid Diligence. Essentially, we do a complete codebase and tech stack analysis that helps uncover any architectural issues, deployment/development issues and much more. Here's some more information: https://rapiddiligence.com/codebase-techstack-analysis
Feel free to send me a DM or email at redacted if you have any questions!