Investment activity has fallen now, but it’s likely to pick up in 2023. And as investment increases, so do mergers and acquisitions. Will your organization and your code pass technical due diligence when it’s your turn?

Let’s start with the positives: if an investor performs technical due diligence (TDD), you are likely to succeed. You passed the tests for product-market fit, financial data and competitive differentiation well enough that they now want to look under the hood.

Here’s the bad news: companies can pass the business test, but fail TDD. Especially for non-technical executives, the code investigation process can feel like… an audit… conducted in another language… with a loud clock ticking incessantly. Not fun.

Our company has analyzed the code of hundreds of billions of dollars worth of deals, from three-member software companies to companies with thousands of developers. We looked at the contributions of more than 200,000 developers who collectively wrote 4 billion lines of code.

We distilled eight questions from that dataset that you can now ask yourself. Even if TDD isn’t on the horizon, having good answers to these questions will keep your codebase healthy.

A quick introduction to TDD

Before we go any further, here’s some more context about software technical due diligence:

• TDD applies to traditional software companies and non-software companies enabled by custom software.
• It involves examining code written by employees or contractors.
• TDD is carried out by internal experts or by specialized consultancies.
• Investors and acquirers, especially the larger and elite, may request that a quantitative code scan be performed in addition to qualitative interviews. In fact, such a code scan is mandatory if the investor is looking for Representatives and Warranties (RWI) for the deal.

The goals of TDD are:

1. Take the risk out of the deal by determining whether the codebase is safe enough for investment.
2. Identify opportunities for improvement if the transaction goes through.

We say “codebase” because it is more than just the source code under the magnifying glass. Your documentation, processes and especially the software developers are also examined. The functional scope of TDD includes code quality, code security, intellectual property, DevOps, IT and sometimes product management.

Because it’s more than just the quality of the code, we’re talking about codebase health to encompass all these areas.

Question 1: What have you been working on?

Making sure the organization is working on the software products that matter most is an important part of making the deal risk-free.

This may sound obvious, but sometimes a company will claim that it is working on a new product, but in reality will spend most of its time custom development for large customers or not working on anything at all.

Take this example of a company’s software development over two years. Not only is there a cyclicality in work (higher in summer), but it has decreased significantly over time, especially in 2022.

Image Credits: sema

Important point: here, and for all questions in TDD, any answer can be enough to clear the exam.

This leads us to TDD Theme #1: The most important part of TDD is to ensure that the codebase state is aligned with the organization’s business objectives. For example, U.S. education software companies typically see cyclical software development — higher in the summer and lower in the fall — to minimize disruption to customers when school starts.

Question 2: How much unit testing does your codebase have?

We like to distinguish between underlying code quality to include measures such as maintainability or the ability to extend, and the functional code quality — how the product works for users.

“Technical fault” is another way of describing any lack of perfection in the underlying code.