Technical Due Diligence for Software Acquisitions: The Complete Guide for Investors

• Introduction
• What Traditional Due Diligence Misses
• Understanding Key Person Dependencies
• Assessing Contributor Engagement
• Evaluating Knowledge Distribution
• The Organization Health Score
• Red Flags That Should Affect the Deal
• Questions for Target Management
• Integrating Findings into Deal Structure
• Post-Acquisition Integration Planning
• Conclusion

Introduction#

When acquiring a software company, financial due diligence tells you about revenue, costs, and contracts. But software companies carry a unique risk that financial audits miss: the code is maintained by people, and the knowledge that makes maintenance possible exists primarily in their heads.

Traditional technical due diligence focuses on architecture quality, security vulnerabilities, and technical debt. These matter. But they assume someone will be there to maintain the code after the deal closes. They don't answer the questions that often determine post-acquisition success: What if the lead architect leaves? How much of the codebase does the current team actually understand? Are there systems that only one person can safely modify?

This guide covers the human factor in technical due diligence, specifically the engineering team risks that often determine whether an acquisition succeeds or struggles.

What Traditional Due Diligence Misses#

Standard code audits examine architecture quality, looking at how scalable and well-designed the systems are. They identify security vulnerabilities and compliance gaps. They assess technical debt and code maintainability. They evaluate the technology stack and dependencies for currency and supportability.

These assessments answer an important question: "Is the code good?" But they don't answer the equally important question: "Will anyone be able to maintain this code after we close?"

Every line of code requires someone who understands it to fix bugs, add features, apply security patches, and manage integrations. When that understanding walks out the door (whether to a competitor, retirement, or simply a new opportunity), you're left with code that nobody can safely modify. The architecture might be beautiful, but if no one knows how it works, the beauty is academic.

Understanding Key Person Dependencies#

The first dimension of engineering team due diligence assesses which individuals hold critical, irreplaceable knowledge. In software companies, knowledge often concentrates in ways that create significant acquisition risk.

Start by calculating bus factor for each repository in the target's codebase. Bus factor measures how many people would need to leave before a system becomes unmaintainable. Identify repositories where the bus factor is 1, as these are systems where a single departure creates immediate problems.

Map critical systems to specific contributors. Note whether those contributors are founders (who might have earnout incentives to stay but often leave once requirements are met), long-tenured employees (who may have outside options), or key technical leaders (who might be recruited away post-acquisition).

Red flags include bus factor of 1 on revenue-critical systems, key knowledge holders who aren't part of retention agreements, and single contributors who account for more than 30% of commits across the codebase.

During management interviews, ask directly: "Which engineers have the deepest knowledge of your billing system?" "If your lead architect left tomorrow, what would be at risk?" "Who is the backup for your most critical systems?" The answers often reveal concentration that the target may not have consciously recognized.

Assessing Contributor Engagement#

Beyond identifying who holds knowledge, understand whether those knowledge holders are likely to stay. Contributor lifecycle analysis reveals engagement patterns that signal retention risk.

Peak contributors show consistent, high activity relative to their historical baseline. They're engaged and productive. Ramping Up contributors are new and building context, which is normal and expected in growing organizations.

The concerning signal is Winding Down, which identifies contributors whose recent activity is significantly lower than their prior patterns. This declining engagement often precedes departure. If key contributors are Winding Down and aren't part of retention agreements, you face immediate post-close risk.

Departed contributors, those with no recent activity, represent knowledge that has already left the organization. Understand what systems they owned and whether successors were established.

A healthy target has most contributors at Peak with a reasonable Ramping Up population. Multiple key contributors classified as Winding Down, high departed count relative to total contributors, or very few Peak contributors all warrant deeper investigation.

Evaluating Knowledge Distribution#

How evenly is knowledge spread across the team? This question matters because concentrated knowledge creates fragile organizations.

The Gini coefficient measures commit distribution inequality on a 0-to-1 scale, where 0 is perfect equality and 1 is total concentration. Coefficients below 0.5 suggest healthy distribution. Between 0.5 and 0.7 indicates moderate concentration worth investigating. Above 0.7 signals significant key person risk that should affect both valuation and retention planning.

Single-author file percentage measures how much of the codebase has been modified by only one contributor. When more than 25% of files fall into this category, you have extensive code that's one departure away from becoming orphaned.

Orphaned file percentage measures code where no active contributor has meaningful ownership, meaning knowledge has already been lost. More than 20% orphaned files indicates significant maintenance risk.

The Organization Health Score#

For executive-level comparison and decision-making, composite health metrics provide a single number that captures multiple dimensions of engineering team risk.

ContributorIQ's Organization Health Score combines bus factor analysis, single-author file tracking, Gini coefficient measurement, and recent activity assessment into a score from 0 to 100.

Scores between 70 and 100 indicate healthy organizations with low acquisition risk. Scores between 50 and 69 suggest moderate risk requiring attention during integration planning. Scores between 30 and 49 are concerning, as significant concentration risk exists. Scores below 30 represent critical risk and warrant either walking away or major repricing.

Red Flags That Should Affect the Deal#

Some findings should make you seriously consider walking away or significantly repricing. These critical red flags include bus factor of 1 on revenue-critical systems, organization health scores below 30, key knowledge holders classified as Winding Down who aren't in retention agreements, more than 30% orphaned files, and single contributors owning more than 40% of commits across the codebase.

Moderate red flags warrant price adjustment or careful earnout structuring. These include bus factor of 2 on important systems, health scores between 30 and 50, high Gini coefficients above 0.6, limited documentation culture, and key contributors approaching vesting cliffs.

Yellow flags don't necessarily affect the deal but should inform integration planning: several contributors in Ramping Up stage (normal for growing teams), bus factor of 3-4 on secondary systems, moderate single-author percentages between 15% and 25%, and documentation that exists but isn't well maintained.

Questions for Target Management#

During management presentations and interviews, engineering team due diligence should include specific questions.

About knowledge distribution: "Which engineers have the deepest knowledge of your core platform?" "What is your onboarding process for new engineers on legacy systems?" "How do you handle knowledge transfer when someone leaves?" "Are there any systems that only one person can deploy or modify?"

About team stability: "Have you lost any engineers in the past 12 months? What systems did they own?" "Which team members have been here the longest?" "Are there any key contributors whose equity is fully vested?" "What is your current hiring pipeline for engineering?"

About documentation: "How do you document architectural decisions?" "Where would a new engineer go to understand how your core platform works?" "When was your architecture documentation last updated?"

The goal is validating quantitative findings with qualitative understanding. Data shows patterns; interviews explain them.

Integrating Findings into Deal Structure#

Engineering team risk should affect deal terms. Knowledge concentration represents real post-close risk that has financial implications.

For valuation adjustments, consider discounting for low health scores, since a score of 30 versus 70 represents meaningful integration risk. Factor in retention risk if significant knowledge lives in people without retention agreements. Budget for knowledge transfer costs, as undocumented systems require investment to stabilize.

For earnout design, structure payouts to protect against knowledge loss. Tie payments to retention of specific named individuals, not just headcount. Include knowledge transfer milestones such as identifying secondary contributors for critical systems by specific dates, achieving minimum bus factors on critical repositories, and completing documentation for key systems. Consider linking earnout portions to health score improvement.

For representations and warranties, include engineering-specific provisions: "No material systems have a bus factor of 1" (or require disclosure of those that do), "Key Employee Schedule is accurate and complete," "No key contributor has indicated intent to leave," "All material systems have documentation sufficient for a competent engineer to maintain."

Post-Acquisition Integration Planning#

Findings from due diligence should drive integration priorities.

In the first 30 days, run fresh contributor analysis to establish a baseline and identify changes from due diligence findings. Confirm all bus factor of 1 systems and verify that key contributors are settled into their retention arrangements. Begin documenting undocumented critical systems while knowledge holders are still engaged and motivated.

During the first quarter, implement pair programming on at-risk systems to begin building backup expertise. Start cross-training secondary owners for systems with concentrated knowledge. Establish documentation standards and begin improving health score metrics.

Over the first year, achieve bus factor of at least 2 on all tier-one systems. Reach target health scores established during deal structuring. Complete knowledge transfer from any contributors who will be departing. Integrate the acquired engineering team into parent company practices and culture.

Conclusion#

Technical due diligence for software acquisitions must extend beyond code quality to assess the human factor. The questions that determine post-deal success are fundamentally about people: Who understands this code? Will they stay? What happens if they don't?

By systematically analyzing bus factor, contributor lifecycle, and knowledge distribution, you can identify risks that traditional technical diligence misses, price deals appropriately for engineering risk, structure earnouts to protect against knowledge loss, and plan integration with eyes open to the real challenges.

The best acquisitions are those where buyers understand what they're acquiring, including the risks that don't show up on the balance sheet but can determine whether the deal succeeds.