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:

StageBusiness FocusDue Diligence Focus
Seed / ABuildPotential
A / B / CGrowScalability, ability to adapt quickly
C / D +Expand and MatureMaintainability, 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.

Leave a Comment