Three reasons for Technical Due Diligence
In practice, we see three reasons for carrying out a Technical Due Diligence:
- A private equity party wants to set up a new platform by expanding an existing product with add-ons: the buy & build-strategy. The challenge is finding a software party that matches the intended technology. It is important that other (new) development teams can take over, modify and further develop the software. The PE party uses the TDD to know for sure.
- The question whether a system purchased or to be purchased can be further developed or incorporated into another platform.
- Examining the software landscape of a larger organization, often specifically focused on (the value of) a particular tool. A good example is a growing SME that is making a leap from on-premises software to a cloud or SaaS solution.
Ultimately, it is always about an analysis that reports quickly and properly on the future possibilities and impossibilities of a piece of software. With the aim of determining the value of the software and making the right decisions in time.
Taking over software unseen is risky, just like buying a used car without a technical inspection. But you can still take a defective car to the garage. An organization that is stuck with unusable software is much harder to repair, or even becomes a total disaster. Our TDD assessment provides a clear and well-founded analysis to buy (whether or not at a lower price) or to refrain from buying.
Seven steps TDD process
Our TDD process consists of the following 7 steps:
In step 1 we ask the question: 'what do you want to achieve?'What is the plan behind the purchase or investment? After all, the technical requirements you set for a product depend very much on what you want to do with it in the future. With this knowledge, we can carry out the TDD in a targeted manner. We'll skip an integration platform that you're not going to use, or a mobile app that needs to be shut down because you already know it's a security risk. This is how we focus on the important issues.
Then we do in step 2 one quick scan of the product. Because even an analysis of public sources quickly provides a useful picture. We view websites, demos, social media, news reports... All the public information that is available. We also look at the broader context, such as the sector or industry in which the company operates and the specific challenges and trends that play a role there. After this analysis, we know which questions we need to get answers to in the next steps.
Step 3 is a kick-off with the buyers and sellers stakeholders, including both CTOs, to explain the process and make follow-up agreements.
This is followed step 4: a technical session with the selling party's CTO (or someone in a similar position) to get a detailed picture of the application landscape. To do this, we create an IRL (Information Request List, a prioritized questionnaire) with all the information we need. Think of certifications, ISO and other labels, specific development processes and all other issues that are specific to the software, scalability, maintainability and architecture.
In the fifth step we interview the CTO, product owner and developers about the software and the development process. We also organize these interviews to discuss the vision, product philosophy and roadmap to better understand the company. Based on the collected knowledge, we assess what more in-depth information we need.
Step 6 is the technical analysis of the product on criteria of reliability, maintainability, cybersecurity and compliance. We scan the source code very closely for a number of properties. This is clear and easy to do for small applications; for extensive systems with dozens of applications that are not all equally important, it is good to set priorities in the first phase and focus on the core of the application. We do not give a subjective opinion but test against standards that apply in the market. On each part, we give a score from A to E.
The last and seventh steps is a completion of a full reporting of the foregoing, provided with advice. The purchasing party uses reports and advice to determine the further strategy and to make decisions with certainty and peace of mind about whether or not to enter into major financial obligations.
Why we've already carried out over 50 TDDs
One reason that tech investors come to Blis Digital is our knowledge and experience in devising, developing and maintaining mission critical software. Because we have been working on this every day for over 17 years, we know the market and the challenges better than anyone. We know what customers will run into when they decide to develop further.
One Technical Due Diligence does not necessarily mean that we will also do development and maintenance, although that is usually an option. We always do a TDD in such a way that it is a very valuable briefing to the party that is going to do this. In my opinion, a TDD is successful if our report provides insight and understanding and really helps the customer and stakeholders in the decision process of purchase or acquisition, or in assessing an application.
Want to know more about Technical Due Diligence?
Are you investing in software companies or are you facing a major takeover? Or do you want to know how future-proof your internal IT landscape still is? With this unique service, we give you quick and detailed answers to all questions about software quality. Read more about our TDD approach here.
.jpg)
