A technical due diligence is an integral part of most acquisitions – needless to say, especially if it is a software company you are about to acquire. In short, the purpose is to assess the quality and condition of a company’s software assets. Sounds pretty straightforward, right? Well, a good and truly useful technical due diligence includes a couple of not-so-obvious things. Not staying on top of them can prove to be quite costly. So to make things easier for you and as a little reminder, here are four perspectives to remember and include in your technical due diligence.
For more in-depth tips and insights into the technical due diligence process, download our guide.And as code is about ones and zeros, what’s behind it is sometimes overlooked. People, that is. A technical due diligence should analyse the development. How is the code familiarity within the team – i.e., is knowledge distributed between members, or do things like code maintenance rely on a few in-the-know experts? Who are the key people, and how wide will the knowledge gaps be if one of them leaves?
2. Processes
If the code quality is good, what else is there to worry about? Does it for example matter how that excellent code is produced? Well, yes. A well-oiled code factory machinery – or rather, development process – is more likely to be robust, sustainable and profitable. Because after all, time is money. Immature processes, with a lot of manual labour, put a lot of stress on an organization in the long run. So remember to take a look at the flow of the software development cycle. Structured or ad hoc? And how do deploys work? Does the team put out fires around the clock for weeks before every release? To summarize: the level of automation is important.
3. Open source and third party components
What’s wrong with open source software? It keeps you independent from licensing, enables the cost-efficiency of off-the-shelf solutions, and often makes it easy to get support from developer communities. All this is true, but still: if there is an element of open source code in the software you are planning to acquire, it is important to look into it. What are the potential weaknesses and risks? Is it maintained and regularly upgraded, and is “your” software updated accordingly?
Also, while open source code is free to use doesn’t mean it is free to sell. Commercializing a product containing open source software can be challenging (you probably already knew this, but still worth a reminder).
4. Security issues
You want to get an idea of how susceptible the software is to security breaches – particularly so if there is sensitive information involved. A fully-fledged pentest (short for penetration test), where a cyber expert simulates an attack to the system to find weaknesses, may be the way to go. On the other hand, these pentests can be both costly and time-consuming. Do you have that time? Or a purchase window (or an exclusivity clause) that is only open for a couple of weeks? Consider your priorities here. If time indeed is short – and/or the risk of being the target of cyber attacks is low - getting an indicative overview of the risks could be an option.
Hope that was of help! Consider these four perspectives, and you reduce your risk of unpleasant, software-related surprises.
For more in-depth tips and insights into the technical due diligence process, download our guide.
And if you want to learn more about how we can help optimize your technical due diligence, please just get in touch!