Technical Due Diligence: What Investors and Acquirers Actually Check Before Funding or Buying a Software Company

Two of our earlier guides already cover the foundational material this guide builds on. Our guide on software ownership, repository rights, and vendor lock-in covers what repository ownership actually requires and the open-source license obligations a codebase can carry. Our guide on production-grade software and technical debt covers what technical debt is and what it costs. Neither explains what happens when someone — an investor before a funding round, an acquirer before a purchase — actually sits down to verify all of that firsthand. This guide covers that process directly: what gets checked, who checks it, how much weight it now carries in a real deal, and how to prepare before anyone asks to look.

What Technical Due Diligence Actually Checks

A real technical due diligence engagement is broader than a single code review, and it's worth naming each component explicitly since founders are often surprised by how many separate threads get pulled at once. Bain & Company, which runs a dedicated technical due diligence practice for private equity clients, and West Monroe, which describes running diligence across integrated technology, cybersecurity, operations, commercial, compliance, and people tracks on more than 500 transactions a year, both frame the process as multi-disciplinary rather than a single engineering audit (Bain & Company, Tech Due Diligence Consulting; West Monroe, Due Diligence & Transaction Advisory).

Code quality and architecture review examines the codebase itself — not just whether it works, but whether its structure will hold up under continued growth, new hires, and feature velocity, distinct from the technical-debt cost mechanics our production-grade software guide already covers. Security and vulnerability scanning checks for known exploitable weaknesses, exposed credentials, and whether basic security hygiene (patching cadence, access controls, encryption practices) is actually in place. IP ownership verification confirms the legal chain of title on the code actually holds — whether every contractor, employee, and dependency's contribution is properly assigned or licensed, which is the exact mechanics our software ownership guide covers in depth. Bus-factor or key-person risk assessment, covered in its own section below, checks how concentrated critical knowledge is in one or two individuals. Technical debt assessment quantifies how much of the team's ongoing capacity is consumed servicing past shortcuts rather than building new value. Infrastructure and cloud cost review checks whether spend is efficient or bloated, and whether the architecture creates the kind of vendor lock-in our ownership guide covers. Open-source dependency and license audits check for exactly the kind of unexpected disclosure obligations — GPL, AGPL — our ownership guide details. And scalability assessment asks the forward-looking question: will this architecture survive 10x the current load, or does it need a rebuild the investor should be pricing in now.

The security and infrastructure layer

Security scanning in a real diligence engagement goes well beyond running an automated vulnerability scanner and reading the output. A thorough review checks how access is actually managed — whether production credentials are shared casually across the team or tightly scoped to the people who need them, whether former employees and contractors still have live access to systems months after leaving, and whether encryption is applied consistently to data at rest and in transit rather than inconsistently depending on which engineer built which feature. Infrastructure cost review looks at this from a different angle: whether cloud spend tracks proportionally with usage, or whether it's been quietly growing through unused resources, over-provisioned capacity, or architectural choices nobody has revisited since the system was much smaller. Both checks matter to an investor for the same underlying reason — they reveal whether engineering discipline exists as an ongoing practice, or whether the product has simply worked well enough, so far, that nobody has been forced to look closely.

The IP and licensing layer

IP ownership verification in a real diligence process is more granular than confirming a single company-wide policy exists — it typically involves reconstructing the actual chain of contribution, contributor by contributor, and checking each one against a signed assignment or an appropriate license. This is exactly why the mechanics in our software ownership guide matter well before diligence starts: a diligence team doesn't take a founder's word that IP is clean, it checks git history against a roster of every person who has ever committed code, cross-references that against signed agreements on file, and flags any gap. Open-source license auditing works the same way at the dependency level — running automated composition-analysis tooling against the full dependency tree, not just the packages a team remembers including, since the riskiest license conflicts are often several layers deep in a dependency of a dependency that nobody on the current team ever consciously chose.

Data room hygiene: the unglamorous prerequisite

Before any of the substantive checks above can even begin, a diligence team needs a well-organized data room — the collected repository access, documentation, contracts, and records the review actually runs against. This sounds like a purely administrative detail, but it functions as an early, informal signal in its own right: a founder who can produce a complete, well-organized set of IP assignments, architecture documentation, and infrastructure inventories within days signals a company that already runs with real operational discipline. A founder who takes weeks to assemble the same materials, or who discovers gaps in the process of trying to assemble them, signals the opposite — not necessarily because the underlying technology is worse, but because the data room itself is often the diligence team's first real look at how the company actually organizes and tracks its own critical information. Treating data room preparation as a low-priority administrative task, rather than as the first substantive test of the diligence process, is a mistake that costs founders credibility before a single line of code has even been reviewed.

How long a real diligence process actually takes

Founders going through this for the first time consistently underestimate the calendar time involved. A technical diligence process for a meaningful funding round or acquisition typically runs several weeks from initial data-room access to a final report, not the few days a founder might assume from how quickly a demo or a pitch conversation moves. That timeline stretches further, sometimes substantially, when the diligence team's early findings raise follow-up questions — a gap in IP assignment records, an unexplained spike in cloud spend, a security scan result that needs a documented remediation plan before the process can close out. This is precisely the dynamic the SRS Acquiom/Mergermarket survey data below captures at scale: diligence timelines are lengthening industry-wide, and technical findings specifically are a major reason why.

Technical debt and scalability, assessed together

Technical debt assessment and scalability assessment are closely related in a real diligence process, even though they answer different questions. Technical debt assessment is backward-looking: it quantifies how much of the team's current capacity is already being consumed servicing past shortcuts, which a diligence team typically estimates by reviewing code quality metrics, the ratio of bug-fix commits to feature commits over time, and direct conversations with the engineering team about where they're currently spending time they'd rather not. Scalability assessment is forward-looking: it asks whether the current architecture can absorb meaningfully more load — more users, more data, more transaction volume — without a fundamental rebuild, and if not, what that rebuild would cost and how long it would take. The two matter together because they compound: a codebase already carrying significant technical debt is generally the same codebase least equipped to scale cleanly, since the same shortcuts that created the debt in the first place (skipped tests, tightly coupled components, undocumented assumptions) are usually the specific things that make a system brittle under new load. An investor reading both assessments together isn't just pricing today's codebase — they're pricing the cost of the company's next stage of growth, which is often the more consequential number of the two.

Who Performs Technical Due Diligence

Crosslake Technologies is a real, named example worth knowing specifically because it's built entirely around this function: founded in 2008 and based in Charlotte, North Carolina, it specializes exclusively in technology due diligence for private equity investors and their portfolio companies, describing relationships with more than 100 PE firms and a proprietary dataset it calls “Measurable TechIndicators,” built from thousands of prior technology M&A transactions it has worked on (Crosslake Technologies). Falfurrias Capital Partners took an investment position in Crosslake, a detail confirmed via both Falfurrias's and Meridian Investment Bank's own published announcements — a useful signal that technical due diligence has become substantial enough as a business category to attract private equity investment in the diligence firms themselves. Quandary Peak Research is a second specialist worth naming: a dedicated software and technical due diligence firm that publishes its own case studies (covered in more detail below), and FossID specializes narrowly in open-source composition analysis for diligence specifically — exactly the license-audit function covered above.

Alongside these specialist firms, fractional CTOs and independent technical advisors are commonly brought in as a complementary layer — someone who can sit in the room, interpret a specialist firm's findings for a non-technical investment committee, and ask the specific follow-up questions a generic checklist might miss. For smaller deals or earlier-stage rounds, a VC firm's own in-house technical partner, where one exists, often performs a lighter version of this process directly rather than commissioning an external firm; for larger acquisitions, the acquirer's own engineering leadership typically takes an active role in reviewing the target's systems before the deal closes, working alongside whichever external specialists are engaged.

The choice of who performs diligence also shapes how a founder should prepare for it. A specialist firm like Crosslake or Quandary Peak arrives with a standardized methodology and a benchmark dataset built from hundreds of prior engagements — which means the questions they ask, and the format they expect answers in, are relatively predictable and can be prepared for in advance by reviewing what these firms publish about their own process. A fractional CTO or independent advisor brought in for a single deal is more likely to tailor their focus to whatever the specific investor or acquirer is most concerned about, which makes their process less predictable from a template but often more directly responsive to the actual deal terms on the table. Knowing which kind of reviewer you're dealing with is itself useful information: a founder facing a specialist firm can reasonably anticipate a comprehensive, checklist-driven review across every category above, while a founder facing a single technical advisor should expect a more targeted, deal-specific set of questions shaped by whatever that particular investor cares about most.

Why It Carries More Weight Than Ever

This data comes from a real, named, dated survey: SRS Acquiom, an M&A data and settlement services firm, partnered with Mergermarket to publish “2026 Best Practices in M&A Due Diligence” in late 2025 (SRS Acquiom & Mergermarket, “2026 Best Practices in M&A Due Diligence”). Beyond the headline figures above, the survey found 73% of respondents expect due diligence overall to become more complex over the next 12–24 months (with 15% expecting it to become “much more complex”), and that one in five respondents reported diligence timelines had already extended over the past two years — with 57% of those saying the extension added one to three months to the process. Read together, this is a clear, well-sourced signal that technical scrutiny specifically, not diligence in general, is the fastest-growing part of how a deal actually gets evaluated — and that a founder who treats technical readiness as a box to check the week before a term sheet is systematically underestimating how much this specific area now matters to the people on the other side of the table.

It's worth being direct about a few widely circulated statistics on this topic that this guide could not independently verify to the standard it holds itself to, and are therefore deliberately excluded: claims that technical due diligence “re-trades 30–40% of software-heavy deals” or that “85% of tech deals fail without it” appear across marketing and SEO content without a traceable primary source, and a claim that due-diligence findings account for “46.6% of broken letters of intent” likewise could not be confirmed against a citable original study. The SRS Acquiom/Mergermarket figures above are the ones this guide is confident citing, precisely because they trace to a real, named, dated survey rather than an unattributed statistic repeating across marketing content.

Bus Factor: Assessing Key-Person Risk

The concept has a real, traceable origin worth knowing precisely, since it's often treated as vague industry folklore rather than a term with an actual history. One of the earliest documented instances comes from 1994: Michael McLay publicly raised the question of what would happen to the Python programming language if its creator, Guido van Rossum, were “hit by a bus” — the origin of the phrase itself, applied to a real, still-thriving open-source project (“Bus factor,” Wikipedia). The underlying pattern — a single point of failure in institutional knowledge — was further formalized in the software engineering literature through James O. Coplien and Neil B. Harrison's book Organizational Patterns of Agile Software Development (2004), which documents this exact dynamic as a recurring, named pattern in real software teams. The term has several informal variants that mean the same thing — “truck factor,” “lottery factor,” “circus factor” — all pointing at the identical underlying risk.

In a real diligence engagement, assessing bus factor isn't a subjective judgment call — it's checkable directly against the same repository data a due-diligence firm already has access to. Commit history reveals exactly what percentage of a codebase's meaningful changes trace back to a single contributor; a codebase where one person authored the overwhelming majority of commits to the most critical systems is a very different risk profile than one with broadly distributed contribution, even if both codebases look identical in a demo. Documentation coverage — or its absence — is the second check: a system that only one person can operate, deploy, or debug because nothing about it is written down anywhere else is a bus factor of one wearing a disguise, regardless of how many names appear in the commit log. For a founder, the practical takeaway is direct: if your most critical system depends entirely on one engineer's memory, that is precisely the kind of risk a serious technical diligence process is specifically built to surface — and precisely the kind of risk worth fixing well before a term sheet, not during the diligence process itself.

When Diligence Fails: The HP-Autonomy Lesson

It's important to frame this case correctly, since it's frequently cited with the framing reversed. HP acquired Autonomy at $42.11 per share — roughly a 60% premium — valuing the company at $10.3 billion in 2011 (CIO.com, “The HP-Autonomy lawsuit: Timeline of an M&A disaster”). HP later wrote down $8.8 billion of that value, alleging that more than $5 billion of the writedown was attributable to accounting improprieties at Autonomy — reportedly including selling hardware at a loss and booking the revenue as higher-margin software licensing, which materially misrepresented the business's real economics. The critical detail for this guide's purposes: this was not a case where a rigorous technical or financial due diligence process caught the problem and either killed the deal or renegotiated the price. It was, by most public reporting, a case where due diligence was inadequate — HP's own CFO reportedly never read the preliminary due diligence report in full, and KPMG's review was the primary external diligence commissioned before a deal of this size closed. The lesson isn't “due diligence caught Autonomy” — it's the opposite: an $8.8 billion writedown is what inadequate due diligence can cost, even at the scale of one of the largest technology companies in the world.

It's also worth being direct about the limits of what real, verifiable, named case data exists beyond this one. Several due-diligence firms, including Quandary Peak Research, publish their own case studies describing engagements that surfaced serious problems — but consistently anonymize the target companies (described only as, for instance, “a Fortune 20 company” or “an unnamed German startup”), which is a real and understandable confidentiality practice but means these accounts can't be verified as specific, named, dated cases the way HP-Autonomy can. Treat those anonymized accounts as credible illustrations of the kinds of issues diligence surfaces in practice, sourced honestly to the firms that published them, rather than as independently verifiable case studies with a named company behind them.

“HP alleged that Autonomy had used improper accounting practices, including selling low-margin hardware at a loss and booking it as high-margin software revenue, to inflate its financial results prior to the acquisition.”

— Paraphrased summary of HP's allegations, as reported in CIO.com's timeline of the HP-Autonomy dispute

The most common founder mistake during diligence itself

Beyond preparing the codebase and documentation ahead of time, how a founder actually behaves once a diligence process is underway matters more than most founders expect. The single most common mistake is treating a diligence team's questions as adversarial rather than genuinely informational, which produces defensive, incomplete, or slow answers exactly when a fast, complete answer would reflect best. A diligence team asking a pointed question about a specific architectural decision usually isn't trying to catch a founder in a lie — it's trying to understand a real system it doesn't have the context a founder's own team has built up over months or years. A founder who responds with a direct, technically honest answer, including an honest “we know this isn't ideal, and here's our plan to address it,” reads as far more credible than one who responds evasively or insists everything is fine when the underlying data plainly shows otherwise. The second common mistake is treating diligence as something to survive rather than something to actively participate in — founders who proactively organize their own data room, pre-answer the questions they know are coming, and flag their own known issues before being asked consistently report a smoother, faster process than founders who wait passively for each new request to arrive.

Red Flags That Reduce Valuation

A consistent set of technical red flags recurs across the industry sources describing what actually moves a valuation number or kills a deal outright during diligence: unpatched critical security vulnerabilities discovered during scanning; low or nonexistent automated test coverage, which signals that every future change carries hidden regression risk; a bus factor of one on a system central to the product, exactly as covered above; undocumented architecture that only survives because specific individuals still remember how it works; missing or lapsed security certifications like SOC 2 or ISO 27001, particularly for a product selling into enterprise customers who require them contractually; unresolved GDPR, HIPAA, or other compliance gaps relevant to the product's actual data handling; inefficient or unbounded cloud spend that signals either poor engineering discipline or an architecture that doesn't scale economically; and unresolved open-source license conflicts — precisely the GPL/AGPL disclosure-obligation risk our software ownership guide covers in depth, which can create real, quantifiable legal exposure a buyer has to price in.

A few of these flags are worth singling out because their downstream cost is easy to underestimate at the moment they're found. Low or nonexistent automated test coverage doesn't just describe current code quality — it's a forward-looking cost multiplier, since an acquirer has to price in the higher likelihood that every future change introduces a regression, which translates directly into slower post-acquisition integration and a higher ongoing engineering cost than the current team's velocity might suggest. Unresolved open-source license conflicts carry a similarly disproportionate downstream cost: a single AGPL-licensed dependency buried in a codebase can, in principle, create a disclosure obligation for the acquirer's entire combined product line post-close, which is why a buyer's counsel treats this category with outsized seriousness relative to how small the underlying technical fix (swapping one library for a permissively-licensed alternative) usually is. And missing security certifications matter most not as an abstract security concern but as a concrete, near-term revenue risk: a product that can't demonstrate SOC 2 compliance may already be blocked from closing specific enterprise deals its own sales pipeline depends on, which an acquirer will read directly as a cap on near-term revenue growth, not just a technical gap.

None of these red flags is individually fatal to a deal on its own — a real diligence process is designed to surface issues, price them, and often structure around them (an escrow holdback, a purchase-price adjustment, a remediation covenant written into the closing conditions) rather than simply walking away. What consistently does more damage than any single red flag is the discovery that a founder already knew about the issue and didn't disclose it proactively. A diligence team that finds an undisclosed problem doesn't just price that specific problem into the deal — it reasonably starts questioning what else wasn't disclosed, which is a far more expensive credibility problem than the original technical issue ever was.

How findings actually get structured into a deal

Most real technical findings don't kill a deal outright — they get priced into it through one of a few standard mechanisms, and understanding these ahead of time changes how a founder should react when a diligence team surfaces a problem. A purchase-price adjustment directly reduces the agreed valuation by an amount tied to the estimated cost of remediation — the cleanest and most common response to a well-quantified issue like a specific security vulnerability or a scoped rebuild. An escrow holdback sets aside a portion of the purchase price, released to the seller only after a defined period passes without the flagged risk materializing into an actual cost — commonly used for risks that are real but hard to price precisely at the time of closing, like an unresolved open-source license question whose actual exposure depends on facts that aren't fully known yet. A remediation covenant requires the seller to fix a specific issue — closing a bus-factor gap by documenting a system, for instance — before or shortly after closing, as a condition of the deal rather than a price adjustment. And in the most severe cases, a finding simply kills the deal, though this is less common than founders often fear, precisely because the mechanisms above exist to let a deal proceed around a real but quantifiable risk rather than requiring perfection as a precondition to closing.

Preparing Before Anyone Asks to Look

Bringing the process above together into what a founder can actually do ahead of time:

1. 1

   Get a real license and dependency scan on your own schedule

   Open-source license conflicts are common enough (as our software ownership guide covers) that finding and fixing one before diligence, rather than during it, is a straightforward, inexpensive step.

2. 2

   Identify and document your bus-factor-of-one systems

   Ask directly: which systems would stall if one specific person left tomorrow? Documenting those systems is one of the highest-leverage, lowest-cost fixes available before a diligence process starts.

3. 3

   Confirm every contributor's IP assignment is actually on file

   Not just current employees — past contractors, early freelancers, and anyone who touched code before your company had a formal process. A gap here is exactly the kind of finding that stalls a deal.

4. 4

   Prepare a clear, honest account of known technical debt

   A diligence team will find your technical debt regardless — being able to describe it accurately, with a credible remediation plan already underway, changes how that finding gets read entirely.

One last practical point worth naming: the relationship between the founder and whoever performs the diligence rarely ends when the report is delivered. For an acquisition specifically, the same technical leadership that ran diligence often becomes directly involved in post-close integration — reconciling the acquired codebase's architecture, tooling, and practices with the acquirer's own. A diligence process that was collaborative and transparent tends to set a materially better tone for that integration period than one that was adversarial, since the acquiring team's early impression of how forthcoming a founder and their engineers were during diligence carries forward directly into how much trust they extend during the harder, higher-stakes work of actually combining two engineering organizations. Treating diligence well isn't just about getting through it — for an acquisition, it's the first chapter of a working relationship that, if the deal closes, is going to continue for years.

Frequently Asked Questions

None of the categories covered here should feel unfamiliar by the time an investor or acquirer actually asks to look — a founder who has read this guide, our software ownership guide, and our production-grade software guide already knows what a serious technical diligence process checks, because it's the same list of things a well-run engineering organization should already be paying attention to regardless of whether a deal is on the table. The founders who find diligence stressful are usually the ones encountering these questions for the first time, under deadline pressure, with a term sheet waiting on the answer. The founders who find it routine are the ones who already knew what their own bus factor was, what licenses their dependencies carried, and what their technical debt actually consisted of — because they'd already asked themselves the same questions a diligence team is about to ask.