The short answer
Technical due diligence is not a code review, and treating it like one is how deals get mispriced. A code review asks whether the code is well written. Technical due diligence asks a different, harder question: can this engineering organization and its output support what you're about to do with it? If the thesis is "scale this to 10x the customer base," diligence has to test whether the architecture and the team can actually get there. If the thesis is "integrate this into our existing platform," diligence has to test whether the codebase, the data model, and the people are integration-ready. If the thesis is "acquire and operate mostly as-is," diligence has to test whether what's under the hood is stable enough to run without a founder-engineer holding it together by hand.
Most of the real risk in a software acquisition or funding round doesn't show up in a demo. It hides in categories buyers routinely skip because they don't know to look: accumulated technical debt that isn't visible until someone tries to ship a feature, a single engineer who is the only person who understands how the billing system actually works, architecture that was never documented because the two people who built it never left, and security or compliance gaps that only surface when someone asks for evidence rather than assurances. A thorough technical due diligence pass finds these things before close, not after — which is the entire point.
The seven categories that actually matter
Technical due diligence frameworks vary by firm, but the substance converges on the same set of questions. Below is the backbone we use, grouped into practical clusters.
1. Strategy and roadmap alignment
Before touching a line of code, diligence has to check whether the technical roadmap actually supports the business plan the deal is built on. A target can have excellent engineers and a clean codebase and still be the wrong bet if their roadmap assumes a rewrite that will consume eighteen months right when the acquirer needs growth. This means reading the actual roadmap documents (not the pitch deck version), talking to engineering leadership about what's realistically shippable in the next two to four quarters, and cross-checking that against the revenue or integration timeline the deal assumes. Misalignment here isn't a red flag on its own — it's a pricing and timeline input.
2. Team and organization
Software is built and maintained by people, and people are the least liquid asset in any acquisition. This category covers skill distribution across the team (is there real depth in the languages and systems that matter, or is expertise concentrated in one or two people), key-person dependency (who leaves and the product stops shipping, or worse, breaks and nobody can fix it), and retention risk specifically tied to the transaction. Engineers who joined a startup for equity and autonomy often have real reasons to leave once an acquisition closes, and losing the two or three people who hold institutional knowledge about undocumented systems can quietly erase a meaningful share of the deal value within the first year. A serious diligence pass maps org charts against system ownership, not just against headcount.
3. Software architecture
This is the category most people think diligence is entirely about, and it's important, but it's not sufficient on its own. The questions here are about design patterns, whether the system was built to scale in the direction the buyer actually needs (more users, more data volume, more concurrent tenants — these are different scaling problems), and, critically, how much technical debt has accumulated and where it's concentrated. Every codebase has debt. The question diligence has to answer is whether that debt is understood and managed or invisible and compounding. A system with known, documented shortcuts is a manageable risk. A system where nobody can say with confidence what happens if you touch the payment reconciliation module is a different kind of risk entirely.
4. Infrastructure and DevOps maturity
This covers cloud versus on-premise footprint, how deployments actually happen (manual, ad hoc, and person-dependent versus automated and repeatable), and disaster recovery — not whether a DR plan exists on paper, but whether it has ever been tested. Diligence should ask for evidence of actual recovery drills, actual deployment logs, and actual infrastructure cost trends, not just architecture diagrams. A target that deploys by SSHing into a production box on a Friday afternoon is telling you something important about operational risk, regardless of how good the product looks in a demo.
5. Product quality and testing
Test coverage numbers get thrown around in data rooms constantly, and they are one of the most commonly misleading metrics in the whole process. The real question isn't "is there a coverage percentage," it's what kind of coverage exists and whether it covers the paths that matter to the business. A bug backlog also tells a story: its size matters less than its age and severity distribution. A backlog of 400 low-priority cosmetic issues is a very different signal than a backlog of 40 issues, three of which are data-integrity bugs that have been open for a year because nobody wants to touch the module they live in.
6. Security and compliance
This category has gotten more scrutiny in every deal over the last several years, and for good reason. Diligence needs to look at actual security policies (not a policy document written once and never updated), vulnerability and incident history, and whether the target holds or needs the compliance frameworks relevant to its market — SOC 2, GDPR, PCI DSS, HIPAA, depending on who the customers are. A prior breach isn't automatically disqualifying, but an undisclosed one, or one with no documented remediation, is a very different conversation. Buyers should ask directly whether there has ever been a security incident and request the incident report, not just a verbal assurance that "nothing serious happened."
7. IP ownership and carve-out readiness
This is the category that gets skipped most often and causes the most expensive surprises. It has to establish, with actual documentation, that the company owns the code it's selling — that contractor and former-employee IP assignment agreements exist and are signed, that no open-source license obligations (copyleft licenses in particular) have quietly attached themselves to proprietary code in a way that creates disclosure obligations, and that the technology can actually stand on its own if it needs to be carved out of a parent company or platform. A codebase that's deeply entangled with a seller's internal infrastructure and can't be separated without months of untangling work is a real integration cost that needs to be priced into the deal, not discovered after signing.
Technical debt is a valuation lever, not just an engineering concern. Debt that gets found during diligence gets priced — as a purchase-price adjustment, an escrow holdback, or a post-close remediation clause written into the deal. Sellers who audit themselves before going to market, and fix or at least document what they find, negotiate from a materially stronger position than sellers who let the buyer's diligence team find it first.
What buyers assume versus what actually gets found
The gap between the pitch and the reality is consistent enough across deals that it's worth laying out plainly.
| Category | What buyers usually assume | What actually gets found |
|---|---|---|
| Test coverage | Coverage exists and reflects real confidence in the system | Coverage is high on unit tests, near-zero on the integration and end-to-end tests that would actually catch a production incident |
| Documentation | Architecture and onboarding docs exist somewhere in a wiki | Docs are stale, cover an earlier version of the system, or never existed because the two founding engineers never needed them |
| Team resilience | Any competent engineer could pick up the codebase | One or two people hold undocumented knowledge of critical subsystems, with no succession plan |
| Open source usage | Third-party code is minor and well managed | Dozens of dependencies with no tracked license obligations, some under copyleft terms nobody reviewed |
| Security posture | Standard practices are in place | No formal incident response process, and the last real security review was informal or years old |
| Technical debt | Manageable and roughly what any startup accumulates | Concentrated in a small number of core modules that the team actively avoids touching |
SBOM and software supply chain: the diligence request that's now routine
One request that used to be reserved for defense contractors and highly regulated industries has become close to standard in technical due diligence: a software bill of materials. An SBOM answers a question that sounds simple and isn't — what open-source and third-party code is actually inside this product, down to the version and license of every dependency. Without one, a buyer is taking the seller's word for it, and "we're not sure, we'd have to check" is not an answer anyone wants to hear three weeks before close.
This is exactly the kind of gap our software supply chain hardening work is built to close, both for sellers preparing to go to market and for buyers who need an independent read before they sign. Generating an accurate SBOM, flagging license conflicts, and identifying components with known vulnerabilities is a bounded, well-defined engagement — and it's far cheaper to run before a deal than to discover a licensing landmine after the ink is dry. Where the audit turns up a codebase that's genuinely aging or architecturally stuck, that's a separate but related conversation, and it's usually where legacy modernization work comes in: remediating what diligence found rather than just documenting it.
Running the process
A real technical due diligence engagement combines document review, code and infrastructure access, structured interviews with engineering leadership and a sample of individual contributors, and hands-on verification — actually attempting to reproduce a deployment, actually reviewing a sample of the codebase rather than trusting a summary, actually checking whether the disaster recovery plan has been tested. The output should be a written report with findings ranked by severity and, ideally, an estimate of remediation cost and time for anything that would materially affect the deal thesis. That report becomes a direct input into either the purchase price, the deal structure, or the walk-away decision — which is why it needs to happen early enough in the process to actually move any of those levers.
Preparing for a raise or a sale?
Whether you're the buyer trying to see clearly or the seller who wants to know what diligence will find before it's found for you, an independent technical audit changes the negotiation.
Frequently asked questions
Who should actually run technical due diligence — the buyer's own engineers or an outside firm?
Both, ideally, but for different reasons. Internal engineers understand how the target will need to integrate with existing systems and can spot fit issues an outsider would miss. An independent firm brings an unbiased read, deal-specific experience across many prior diligence engagements, and — importantly — no incentive to either rubber-stamp a deal their own leadership wants to close or protect a codebase they didn't build. Most serious deals use both.
How long does a real technical due diligence pass take?
For a small to mid-sized software company, a thorough pass typically runs two to four weeks once access to code, infrastructure, and key personnel is granted. Larger or more complex targets, or ones with multiple product lines and acquired components of their own, can take six weeks or more. Rushing this to fit a tight deal timeline is one of the most common ways serious issues get missed.
What's the single most common deal-breaker finding?
Undisclosed key-person dependency combined with poor documentation. It's rarely a single catastrophic bug that kills a deal — it's discovering that the entire system depends on institutional knowledge held by one or two people who have no obligation to stay past close, and that knowledge was never written down anywhere.
Does this apply to a Series A raise or only to acquisitions?
It applies earlier than most founders expect. Series A and B investors increasingly run a lightweight technical diligence pass before wiring funds, focused on architecture scalability, key-person risk, and whether the roadmap can support the growth plan the raise is funding. It's rarely as deep as acquisition-stage diligence, but the same categories apply, just at lower intensity.