8 Issues PE Firms Find in Software Due Diligence

The eight problems PE firms most often uncover in software due diligence: key person risk, IP gaps, security debt, infrastructure decay, and engineering team disengagement.

Key Takeaway

Across software due diligence engagements, eight findings recur with striking regularity. Most are invisible from financials, and most are not solved by a code audit alone. Understanding the pattern lets PE firms plan diligence resources, structure earnouts, and avoid the deals where post-close engineering risk swamps the purchase discount.

Issue 1: Bus Factor of 1 on Revenue-Critical Systems

The single most common finding. One engineer is the sole substantive author and reviewer for a system that generates a meaningful share of revenue. Often this is the original technical co-founder, sometimes a long-tenured senior engineer who quietly absorbed the work as the team grew.

Why it matters: Post-close, this engineer becomes the single point of failure for integration, customer-driven changes, and incident response. Voluntary departure within 12 months is common, especially after vesting acceleration cliffs.

How to detect: Repository-level bus factor analysis using Degree of Authorship on the seller's code. See our full bus factor guide.

How to mitigate: Retention agreement with vesting acceleration contingent on close + structured knowledge transfer plan + an earnout component tied to retention through month 24.

Issue 2: Missing IP Assignment from Past Contributors

A former contractor or contributor wrote significant code under an ambiguous agreement that did not transfer IP to the company. The contributor may have moved on, or worse, may be aware of the gap and waiting for a liquidity event.

Why it matters: Without clean IP, the buyer inherits litigation exposure. In extreme cases, the IP gap can be used to extract a settlement that materially impacts deal economics.

How to detect: Git blame walks. Every author email in the commit history should be cross-referenced against the seller's employee and contractor agreement records. Any author who is not covered is a finding.

How to mitigate: Seller obtains a retroactive IP assignment from the former contributor before close. If not possible, escrow a portion of consideration against the contingency.

Issue 3: Open Source License Violations

The codebase incorporates AGPL, GPL, or SSPL-licensed components in ways that would obligate disclosure of proprietary source code. The seller is usually unaware.

Why it matters: Public discovery post-close forces a costly choice: disclose proprietary code, remove and reimplement the components, or settle with the upstream community.

How to detect: Run a license scanner (FOSSA, Snyk License Compliance, ScanCode) on the full dependency tree.

How to mitigate: Seller remediates pre-close (typically by replacing the offending components). Buyer reserves a portion of consideration in escrow against remediation completion.

Issue 4: Undocumented Security Debt

Hardcoded secrets in git history, untested incident response runbooks, default credentials in production-adjacent environments, or unpatched known-vulnerable dependencies.

Why it matters: A breach in the months following close is attributed to the buyer, not the seller. SOC 2 or ISO 27001 certifications obtained in the past 12 months may have audited around the issues rather than fixing them.

How to detect: Independent penetration test commissioned by the buyer (not the seller). Secrets scan of full git history (TruffleHog, GitLeaks). Review of last 24 months of incident postmortems.

How to mitigate: Pre-close remediation requirements as a closing condition. R&W insurance specifically covering cybersecurity findings.

Issue 5: Deferred Infrastructure Maintenance

The infrastructure was built for a fraction of current scale and has been patched, not rebuilt. Critical services run on EOL OS versions. Database replication has not been tested in months. Backups exist but restore procedures have never been validated.

Why it matters: A failure forces an emergency rebuild during the integration window, when the seller's engineering team is least available. The cost shows up as a one-time capex line that was not modeled in the deal.

How to detect: Infrastructure-as-code coverage review. Last-tested-on dates for backup restore and disaster recovery procedures. Cloud account age and reserved instance utilization patterns.

How to mitigate: Independent infrastructure assessment by a specialist firm. Budget a 12-month infrastructure modernization plan into the integration model.

Issue 6: Undisclosed Technical Co-founder Dependency

The technical co-founder has gradually disengaged. They show up to the diligence calls, they answer questions, and their LinkedIn lists them as CTO. But git history shows their meaningful commits stopped 14 months ago. The substantive work has shifted to two senior engineers, neither of whom is on the executive comp plan.

Why it matters: The two senior engineers are doing the work. They are also undercompensated for the responsibility they carry. Post-close, the CTO often exits within six months (vesting cliff plus disengagement plus a liquidity event), at which point the two senior engineers become both critical and likely flight risks.

How to detect: Cross-reference the executive team's git activity against their nominal roles. A CTO whose last substantive commit was 14 months ago is a signal, not a finding by itself. Combine with structured interviews of the senior engineers actually doing the work.

How to mitigate: Promotion and compensation correction for the senior engineers tied to close. Stay bonuses for the actual technical leadership, not just the nominal CTO.

Issue 7: Fabricated Engineering Velocity

The seller presents engineering metrics suggesting high velocity. Closer inspection shows the metrics are gamed: PRs are split to inflate count, work is back-dated, or the metrics period was cherry-picked.

Why it matters: The deal model includes assumptions about post-close feature throughput. Inflated velocity numbers mean those assumptions are wrong and the integration timeline slips.

How to detect: Pull raw git data and recompute the metrics yourself. Compare to the seller-provided numbers. Look for unusual PR-size distributions (many tiny PRs that should have been one), authorship patterns (a sudden burst of commits in the diligence period), and trend discontinuities.

How to mitigate: Independent recomputation of all engineering metrics. Lock the buyer's deal model to independently-verified numbers.

Issue 8: Disengaged Senior Engineers Planning Post-Deal Exits

Two or three senior engineers have decided privately that they will leave 12-18 months after close, once their acceleration vests. They have not told the seller's executive team. They sometimes have not told each other.

Why it matters: The buyer pays for the team and inherits the systems. Eighteen months later, the team is gone and the systems are still there with no maintainers.

How to detect: Contributor lifecycle classification. Engineers in the "winding down" stage (declining commit frequency, declining review participation, declining presence in design discussions) flag the pattern. Combine with structured retention interviews focused on motivation and post-close interest.

How to mitigate: Identify the flight risks before close. Structure retention packages that pay out over 24-36 months, not 12. Make a portion of the partner's investment thesis explicitly contingent on retention of the named engineers.

How These Issues Compound

Individually, most of the eight are manageable. The deal-killer is the compounding pattern: a bus factor of 1 (Issue 1) on a system held together by deferred infrastructure (Issue 5), maintained by a disengaged engineer (Issue 8), under a nominal CTO who stopped contributing months ago (Issue 6). When the diligence team surfaces three or four of the eight in one company, the cumulative integration burden often exceeds any plausible price discount.

The pattern PE firms most often miss is that Issues 1, 6, and 8 are not visible in the materials sellers prepare. They emerge only from independent analysis of git history and structured interviews. Allocating diligence budget to those activities is the difference between a clean post-close integration and a 24-month value erosion.

How ContributorIQ Surfaces Issues 1, 6, and 8

The three engineering team risk findings (bus factor concentration, technical co-founder disengagement, and senior engineer disengagement) are the ones automated platforms can quantify in days rather than weeks. ContributorIQ ingests read-only git history and produces:

  • Bus factor by repository, using DOA.
  • Per-contributor lifecycle classification (ramping, peak, plateau, winding down).
  • Activity trend analysis for named executives and senior engineers.
  • An Organization Health Score that combines these signals.

PE diligence teams use ContributorIQ to baseline these risks before the live interviews, so the interview time is spent confirming hypotheses rather than discovering them. See our M&A due diligence use case for example outputs.

Frequently Asked Questions

What are the most common issues uncovered in software PE due diligence?

The eight most common issues PE firms uncover during software due diligence are: bus factor of 1 on revenue-critical systems, missing IP assignment from past contributors, open source license violations, undocumented security debt, deferred infrastructure maintenance, an undisclosed technical co-founder dependency, fabricated engineering velocity, and disengaged senior engineers planning post-deal exits. All eight are largely invisible from financials and require dedicated technical and engineering team review.

Which due diligence finding most often kills a software deal?

The deal-killer is almost never a single dramatic finding. It is the cumulative weight of compounding risk: a bus factor of 1 plus undocumented architecture plus a key engineer flight risk plus deferred infrastructure debt. Individually each is manageable; together they signal that the post-close integration burden exceeds the price discount the buyer can negotiate.

How early in the process should PE firms surface technical issues?

Engineering team risk metrics (bus factor, key person dependency, contributor lifecycle) can be quantified from read-only git access within days of LOI. Surfacing these early in the diligence window gives operating partners time to negotiate retention agreements, plan integration, and structure earnouts contingent on key engineer retention. Waiting until week five of diligence eliminates these levers.

Conclusion

The eight issues above account for the vast majority of post-close value erosion in software acquisitions. None of them are exotic. All of them are detectable with the right combination of structured interviews, independent code review, and quantitative analysis of git history. The PE firms that consistently outperform on software integration are not the ones that find every issue. They are the ones that surface Issues 1, 6, and 8 early enough to use the findings as leverage in deal structuring.

Support Chat
Support team currently unavailable. Leave a message and be sure to include your email address and we will follow up with you shortly!

Enter your email so we can follow up (optional):

Send a message to start a conversation with our support team.