Technical due diligences

Due diligences have different layers of work: financial, market value, people engaged in the company, etc.

Technical side of the due diligences have evolved a lot and now there are many recipes but some consensus about what you should cover as minimum.

The technical side of a due diligence is basically a health check of the company, where:

• You dig into the assets they have and the assets they are building.
• You try to understand the risks that the company is taking at product level and in terms of technology.
• Leadership team is evaluated,
• The teams, the processes and the organization (as a whole),
• The product/s they are building (this perspective is linked to market and technology),
• And the technology stacks they are working on, and the practices they use.

Before to start a due diligence, you should understand the type of company you are addressing. For instance this basic classification could help:

Stage	Business Focus	Due Diligence Focus
Seed / A	Build	Potential
A / B / C	Grow	Scalability, ability to adapt quickly
C / D +	Expand and Mature	Maintainability, Compliance (IPO, Exit)

A good due diligence have a good balance between the good assets and potential the company has, and the problems and high exposure risks they have (everybody has skeletons in the closet).

A basic structure of a technical due diligence process

The process itself varies depending on many things, but the basic things you should cover is:

• Preliminary work to define scope, expectations and identify the stakeholders.
• A Kick-off meeting where the process itself is reviewed and the main participants understand and agree about how things are going to work.
• Revision of the documentation,
• Interviews with the identified stakeholders, with a walkthrough.
• Build the report and ask for final questions.
• Deliver the report.

Usually this side of the due diligence work is integrated in the whole due diligence process.

Due diligence is a very contextual process

and by that reason the topics you cover can vary a lot. The basis are:

• The market fit they have found or they are exploring
• The business model the company implements to take advantage of the context where they compete.
• The strategy they are using to advance in the environment where they work.
• The product side of the company.
• The leadership team.
• The development processes and the practices used.
• The infrastructure.
• The deployment process.
• The architecture of the solutions
• The quality assurance and testing processes
• How people work with other teams.
• How aligned they are to the compliance requirements of their context.
• Security.
• The horizontal processes (human resources, finance, marketing, etc)
• How decisions are done (for instance which technical components are build or consumed from other vendors).

The list can be extended, but I will stop here.