8 questions to answer before your startup faces technical due diligence • ZebethMedia

Matt Van Itallie
Contributor

Matt Van Itallie is the founder and CEO of Sema, which provides codebase analytics for M&A.

Investment activity is down now, but it’s likely to pick up in 2023. And when investments ramp up, so does M&A. Will your organization and your code pass technical due diligence when it’s your turn?
Let’s start with the positives: If an investor is proceeding with technical due diligence (TDD), you’ll likely pass. You’ve passed the tests for product-market fit, financials and competitive differentiation well enough that they now want to look under the hood.
Here’s the not-so-good news: Companies can pass the business test, but fail TDD. Especially for non-technical executives, the code-examination process can feel like … an audit … conducted in another language … with a loud clock ticking away incessantly. Not fun.
Our firm has analyzed the code of hundreds of billions of dollars worth of deals, from three-person software companies to firms with thousands of developers. We’ve looked at the contributions of over 200,000 developers who have collectively written 4 billion lines of code.

Poor codebase health is more often than not “caused” by other teams rather than by engineering.

From that dataset, we’ve distilled eight questions that you can ask yourself now. Even if TDD is not on the horizon, having good answers to these questions will ensure your codebase is healthy.
A quick primer on TDD
Before we go any further, here’s a bit more context on technical due diligence for software:

TDD applies to traditional software companies and non-software companies enabled by custom created software.
It involves the examination of code written by employees or contractors.
TDD is conducted by in-house experts or by specialist consultancies.
Investors and acquirers, especially the larger and elite ones, may ask to conduct a quantitative code scan to supplement qualitative interviews. Such a code scan is effectively mandatory if the investor is seeking reps and warranties insurance (RWI) for the deal.

The goals of TDD are to:

De-risk the deal by determining if the codebase is safe enough for investment.
Identify opportunities for improvement if the transaction goes through.

We say “codebase” because it’s more than just the source code that’s under the magnifying glass. Your documentation, processes and most importantly, the software developers will also be under examination. 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 talk about codebase health to encompass all of these areas.
Question 1: What have you been working on?
Making sure that the organization is working on the software products that matter most is an important part of de-risking the deal.
This may sound obvious, but sometimes, a company claims to be working on a new product, but will actually be spending the majority of their time on custom development for major clients or not working much on anything at all.
Consider this example of a company’s software development over two years. Not only is there a cyclicality in the work (higher in summer), but it has declined significantly over time, especially in 2022.
Image Credits: Sema
Important point: Here, and for all questions in TDD, any answer might be sufficient to clear the examination.
This leads us to TDD Theme #1: The most important part of TDD is ensuring the state of the codebase is aligned with the organization’s business objectives. For example, U.S. education software companies typically see cyclical software development — higher in summer and lower in fall — to minimize disruption for customers when school starts.
Question 2: How much unit testing does your codebase have?
We like to distinguish between underlying code quality to include such measures as its maintainability or the ability to be extended, and the functional code quality — how the product works for users.
“Technical debt” is another way of describing any lack of perfection in the underlying code.