Start Up

8 Questions to Answer Before Your Startup Faces a Tech Due Diligence • TechCrunch|

8 Questions to Answer Before Your Startup Faces a Tech Due Diligence • TechCrunch|

The investment activity has decreased now, but it’s likely to pick up in 2023. And as investment picks up, so does M&A. Will your organization and code pass technical due diligence when it’s your turn?

Let’s start with the positive: If an investor proceeds with technical due diligence (TDD), you will likely pass. You’ve passed the tests for product marketing, 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 managers, the code testing process can feel like … an audit … done in another language … with a tall clock ticking away incessantly. Not fun.

Our company has analyzed the code for hundreds of billions of dollars in deals, from three-person software companies to enterprises with thousands of developers. We’ve reviewed 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 engineering.

From that dataset, we’ve distilled eight questions you can ask yourself right now. Even if TDD isn’t on the horizon, having good answers to these questions will ensure that your code base is healthy.

A quick primer on TDD

Before we go any further, here’s a little more context on technical due diligence for software:

  • TDD applies to traditional software companies and non-software companies with custom software.
  • It includes examining code written by employees or contractors.
  • TDD is performed by in-house experts or by specialist consultants.
  • Investors and buyers, especially the larger and elite ones, may request to perform a quantitative code scan to complement the qualitative interviews. Such a code scan is actually mandatory if the investor is seeking representation and liability insurance (RWI) for the deal.

The goals of TDD are to:

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

We say “codebase” because there’s more than just source code that’s under the magnifying glass. Your documents, processes and most importantly, software developers will also be scrutinized. TDD’s functional areas include code quality, code security, intellectual property, DevOps, IT, and, sometimes, product management.

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

Question 1: What have you been working on?

Ensuring that the company is working on the software products that matter most is an important part of mitigating the risk.

This may sound obvious, but sometimes a company claims to be working on a new product, but will actually spend the majority of its time doing custom development for key customers or not doing much work at all.

Consider this example of a company’s software development over two years. Not only is employment volatile (higher in the summer), but it has decreased significantly over time, especially in 2022.

Development activity over time (commitments), by month

Image credit: Sema

Important point: Here, and for all questions in TDD, any answer may be sufficient to clear the exam.

This brings us to TDD Theme #1: The most important part of TDD is ensuring that the state of the codebase is aligned with the organization’s business goals. 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 code base have?

We like to differentiate underlying code quality to include such measures as its maintainability or ability to extend, and practical code quality – how the product works for users.

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

Source link

Optimized by Optimole