Breaking down Technical Due Diligence – Key factors

Many engineers dream of a liquidity event. When hard-earned virtual equity converts into cash. An action that often triggers this event is an acquisition.

Liquidity Event

As part of an acquisition, series funding, merging, or venture capital round, the investor will perform technical due diligence. An in-depth investigation of the software company. This includes how the company is staffed, the usage of technology, and the processes in place that allow everything to work together.

Technical Due Diligence Scope — Philip Starritt

Why is technical due diligence important?

In order to test an investment thesis, investors can access a company from the inside. This helps investors understand the product’s value, reliability, growth potential, safety, security, and risks.

Bringing together technical, and commercial diligence can clarify the investor’s view. This synergy often opens new doors and ideas. Alignment is important, as a strong technical foundation is key for performance and scalability.

For example

• Core features were tangled within a constrained legacy monolith. Which was unable to scale to future business needs. The investor needed to evaluate the required extra investment and time with the value creation plan.
• A system failed to meet data regulatory requirements within a highly regulated industry. Triggering an investor to withdraw.
• A logistics SaaS platform wanted to enter the log-aggregate market. During technical due diligence, an advanced data analytics platform was discovered. This presented an opportunity to move from data to insights. By integrating the logistics platform with data analytics services. Opening a new revenue stream.

The focus & outcome

The technical due diligence focus may be different at each investment stage.

For example, series funding TDD focus:

• Seed A, Potential
• Seed B, Growth
• Seed C+, IPO, exiting

Growth — Image from unsplash

The Core & IP

It is important to analyze in-depth the differentiating value proposition. Product and technology teams must align. Ensuring business priorities flow into the investigation.

For example

• In a platform consisting of three products, product A generates 90% of the total revenue. The other products contain supporting services. Services that customers expect to be there. But not what attracts them to do business with the company.
• Integrating with an acquired service B will create a unique selling point.

It makes sense to do an in-depth analysis around product A and service B.

It is especially important to identify risks that jeopardize the acquirer’s vision. A risk may be unacceptable in a core service, but acceptable in a supporting service.

Scope & Checklist

Architecture & Infrastructure

Are the platform’s architecture and infrastructure scalable, stable, and well-maintained?

Risks

• Scalability
  - Where are the weak links and bottlenecks?
  - Can the core handle 10x, or 100x the throughput?
• Maintenance
  - Are components kept up-to-date? Do any components need to be replaced?
• Reliability
  - Are systems reliable?
• Third-party
  - Are core features dependent on third parties?
• Integrations
  - Are APIs modern and easy to integrate with?
• Technology stack
  - Is it difficult to hire developers for the technology stack?
  - Is the core system developed on well-supported technologies?
• How and where are the systems hosted?
• Disaster recovery
  - What is the disaster recovery plan?
• Financials
  - What is the platform’s operational cost?
  - Are there any planned tech investments?
  - Software & third-party licenses

Supporting documentation & discussion points

Architecture diagrams, architecture decision records, list of third-party integrations & business risks and licenses, authentication and authorization diagrams, network & cloud infrastructure diagrams, data center services, integration points, product designs, post-mortems, service-level agreements, service metric analytics, breakdown of platform costs, protections on intellectual property

Architecture — Image from unsplash

Quality

Do teams follow good software development practices?

Risks

• Development methodology
  - Are the principles behind the agile manifesto followed?
• Low code quality
  - Are teams following best practices? E.g. Pull requests, design patterns
• Continuous delivery (see Dave Farley’s material)
  - Are teams autonomous and able to release frequently?
  - Adoption and investment into continuous delivery practices
• Technical debt
  - How do teams address technical debt?
• Over-engineering
  - Are problems challenged and simplified?
• Onboarding
  - Slow engineering or client onboarding process
• Quality assurance
  - Is there a focus on automated quality assurance and test coverage?
• Frameworks
  - Are frameworks and libraries kept up-to-date?
• Data quality
  - Are business decisions made on accurate data?

Supporting documentation & discussion points

Continuous delivery pipelines, environment workflows, the code review process, list of frameworks and library versions

Important pieces — Image from unsplash

People

Does the organization’s leadership, structure, and culture support growth?

Risks

• Key people
  - Which employees are critical to operations?
  - Who are the influential employees?
• Poor engineering culture
  - Are teams safe, supportive, and well balanced?
  - Can people focus on their strengths?
• Culture clash risk (acquisition)
  - Companies have very different cultures. How can they best work together?
  - Mixing fully remote and hybrid cultures
• Attrition rate
  - Engineers' average tenure
• In-house knowledge
  - Has all development been outsourced?
• Does team structure support agile development?
• Conway’s law

Supporting documentation & discussion points

Organizational chart, contracted roles, outsourcing agencies, salary information, workforce diversity, critical employees list, team communication structure, key employee retainment strategy

Security

Does the organization adhere to data privacy standards, regulations, and follow security best practices?

Risks

• Data
  - How is data protected?
  - Who can access sensitive data?
• Regulations
  - Is software compliant with regulations?
• DevSecOps
  - Is DevSecOps embedded within the delivery lifecycle?
• Security
  - How and when does the platform & company undergo security testing and scanning?
  - Threat mitigation
  - Authentication and Authorization
• Infrastructure
  - How is infrastructure managed and updated?
  - Ingress and egress access points

Supporting documentation & discussion points

Threat models, penetration testing reports, dependency, code and infrastructure scanning reports, agent monitoring, DevSecOps practices, security practices followed, regulations followed (E.g. GDPR), information regarding any cybersecurity tools used

Strategy

Are the product vision and technical strategy aligned with the long-term business strategy?

• Business strategy
• Product vision
• Technical strategy & roadmap
• Buy vs build
  - Is the company investing in differentiating and unique functionality?
  - Is the company building off-the-shelf solutions, and neglecting future maintenance costs?
  - Opportunity cost
• Business continuity plan
• Is the company a client feature factory with no vision?

Supporting documentation & discussion points

Business plans, product roadmap, technical strategy, buy vs build decision records, tech investments, budgets

Strategy — Image from unsplash

Tech due diligence is not only important for investors. From a company's perspective, having awareness from the outset can help streamline any future event.

I hope you have a better idea of what to expect, or what to investigate.

Philip