Technical Due Diligence — Content and procedure for Startups

As a CTO, I am frequently asked by investors whether I can support them in technical due diligence reviews. These reviews are carried out as part of an acquisition or expansion of investment.

Technical due diligence is specifically designed to identify divergences that could impact further scaling and provide insights into the system's integrity and processes. In most startups, the technology, and therefore the systems and teams behind it, is the key value driver.

While there are various standard frameworks and methods for other audits, for example, legal and financial due diligence, no process model has been established for technical due diligence. As a result, the company to be audited usually has little opportunity to prepare for the audit and its actual business operations.

Based on my experience, I have developed a standardized approach to how I conduct tech due to diligence and which areas I look at in more detail.
This article is intended to help both investors and companies to perform or prepare for an audit better.

Contents

So what areas should be covered in a technical due diligence review?
I usually divide my analysis into the following:
- System and software architecture
- Code quality & infrastructure design
- Development, testing, and deployment process
- Information security & privacy
- Team building & collaboration
- Product roadmap & vision

System and software architecture

A high-level overview of the entire system landscape and in detail of the individual components provides an overview of the existing application landscape. This makes it possible to see how the systems and applications are interlinked and the extent to which they fit in with the company’s overall strategy. Particularly in the case of companies that have grown considerably, this indicates whether the architecture and the systems have also grown in context. The following exemplary questions arise here:
- Does the architecture fit in with the company’s plans?
- Are the components documented?
- Is there a fully documented API?
- According to which pattern are architecture decisions made?
- How are/can external systems be integrated into the architecture?

Code quality & infrastructure structure

Quality is characterized by the fact that the concrete application architecture and the underlying code are easily understandable and structured according to certain standards. A specific standard doesn't have to be used, but it must be followed through once a standard is agreed upon. A static code analysis (SCA) can give a first impression.
- Which programming languages & frameworks are used?
- Which code and architecture standard is used?
- Which tooling is used?
- How is the hosting done?
- Which database is used?
- How is the monitoring set up?

Development, test, and delivery processes

Special attention is paid to the degree of automation of the entire development, test, and deployment process. Nowadays, complete automation is essential for the development process, if only for efficiency reasons. The process set up here also shows how advanced and integrated software development is within the company.
- How is collaborative development done?
- How is the source code managed?
- How are changes merged?
- Can changes be traced back based on ticket/user stories?
- How is deployment done?
- How are bugs and support handled?

Information Security & Data Protection

The security of information systems is a major topic in itself. Within due diligence, different points should be queried to get a picture of how this topic is dealt with in the company:
- Are common security code standards being followed?
- How are authentication mechanisms implemented?
- Are internal and external penetration tests carried out regularly?
- Does a regular external data protection audit take place?
- How are security incidents handled?

Team building & collaboration

In most investments, the existing team should continue to exist and even be expanded. Especially in software development, it is difficult to find good people and familiarize them with the systems. The following questions arise in the composition of the teams:
- How are the teams structured?
- Who leads the teams?
- Who makes decisions within the teams?
- To what extent is there communication between business/product/tech?
- How is recruiting done? Who decides on new hires?
- What is the churn rate?
- What is the composition between senior and junior developers?

Product Roadmap & Vision

In addition to the technical aspects, there is also a focus on the product team, usually reflected by a business or product owners. The following questions are relevant here:
- How is the product(s) developed? Which KPIs are the basis for this?
- What capabilities are available in the product unit?
- Is there a roadmap in place?
- How is the roadmap planning going? To what extent are the technical teams involved here?
- How much influence do technical teams have on the roadmap?

The procedure of a Due Diligence

A Tech DD goes through the following phases:
- Familiarize yourself with the business model
- Gather Tech DD information
- Questions & Answers (Q&A)
- Final report & assessment

Familiarize yourself with the business model

Basic knowledge about the company and the business model is essential to evaluate the due diligence's answers. For example, architectural decisions should be made based on the purpose of the company. A classical company presentation or a conversation with the CEO will help to evaluate the business model.

Gathering information

Using a standardized questionnaire covering the upper areas, the company to be audited can collect all relevant information internally and make this available in a collected form.

Questions & Answers (Q&A)

Specific questions or questions arising from the question catalog are answered in a separate Q&A session. This Q&A session is usually limited in time.

Final Report & Assessment

The final report is made available to the investor. In this report, the evaluation of the questions from the upper sections and other facts takes place. This is done based on the following classification:
- Red Flag Item
- Potential Risk Item
- Post Closing Item
- Information only item

In addition to an individual evaluation, and overall evaluation and a management summary are also carried out.