Five red flags we look for in technical due diligence

Five red flags we look for in technical due diligence

We run technical due diligence for investors several times a year, and the findings that change a valuation are seldom the ones in the codebase metrics. Old code that is well understood and covered by tests is an asset. New code that only one person can explain is not.

The first flag is a team that cannot describe their own failure modes. The second is a deployment process that depends on a named individual. The third is a test suite that is skipped in CI more often than it is run.

Technical debt is rarely the risk. How a team talks about their technical debt almost always is.

The fourth is a roadmap with no maintenance line on it, which usually means the maintenance is happening anyway and being recorded as features. The fifth, and the most reliable, is defensiveness — a team confident in its estate will show you the worst part of it unprompted.

None of these require access to the source to detect, which is why the interviews matter more than the repository scan.