What Technical Due Diligence Actually Covers

Every software acquisition, investment round, or merger eventually reaches a moment where the financial and legal teams have done their work, the commercial case looks sound, and someone asks a version of the same question: has anyone actually looked at the technology? Technical due diligence is the answer to that question. It is the structured process of independently assessing a target company's software, infrastructure, and engineering organization before money changes hands, so that the buyer or investor understands what they're actually getting — not just what the pitch deck or the sales narrative described.

Done well, technical due diligence is one of the more consequential parts of a transaction's preparation, because software assets are unusually opaque from the outside. A building can be inspected by walking through it. A balance sheet can be audited against established accounting standards. A codebase, by contrast, can look identical from a demo or a screenshot whether it's built on a clean, well-tested foundation or on years of unmanaged shortcuts — and the difference between those two states can represent a large, hidden cost that only surfaces after the deal closes. This guide sets out what a rigorous technical due diligence review should actually cover, how the findings get used, and how to tell a substantive review from one that only checks boxes.

Why technical due diligence exists as its own discipline

Financial and legal due diligence answer questions about historical performance, liabilities, and contractual obligations. They are essential, but they are largely backward-looking and they are not designed to answer engineering-specific questions: can this system handle ten times the current user load without a rebuild? Does one engineer hold knowledge that would take months to reconstruct if they left? Is there a known security vulnerability sitting unpatched in a payment flow? Does the company actually own the code it's selling, or did a departed contractor never sign an assignment agreement?

These are forward-looking, technical questions that require someone who can read code, evaluate architecture decisions, and talk to engineers in their own terms. That's the gap technical due diligence fills. It doesn't replace financial or legal review — it runs alongside them, and its findings often feed directly into both.

It's also worth being clear about who commissions this kind of review. It isn't only acquirers. Investors evaluating a funding round, two companies structuring a merger, and even large enterprise customers evaluating whether to build a long-term dependency on a vendor's platform all have a legitimate interest in understanding the technical reality behind a piece of software before they commit. The framework below applies across all of these scenarios, with the scope and depth adjusted to the size and stakes of the decision.

The seven core areas a thorough review covers

A rigorous technical due diligence engagement is built around a consistent set of areas. Skipping any one of them leaves a real blind spot, because problems in one area frequently explain or compound problems in another — a codebase with poor test coverage, for instance, is often also the codebase where knowledge is concentrated in one anxious engineer who is afraid to change anything without them in the room.

Codebase health

This is the most literal reading of "looking under the hood." A reviewer examines the actual source code, not just a description of it, for signals that predict how expensive the codebase will be to maintain and extend going forward. Key questions include:

• Test coverage and quality. Is there automated testing on business-critical logic, or does quality rely on manual QA and hope? Coverage percentage matters less than whether the tests that exist actually catch regressions in the paths that generate revenue.
• Technical debt. Are there known shortcuts, deprecated patterns, or half-finished migrations sitting in the code? Every non-trivial codebase carries some debt — the question is whether it's understood, tracked, and manageable, or whether it's accumulated silently to the point of slowing every new feature down.
• Dependency freshness and security posture. Are third-party libraries and frameworks reasonably current, or is the system running on end-of-life versions with known, unpatched vulnerabilities? A dependency audit is one of the faster, more objective checks a reviewer can run, and it often surfaces risk that isn't visible anywhere else.
• Code consistency and structure. Does the codebase follow discernible conventions, or does it read like the work of many people who never agreed on an approach? Inconsistency itself isn't disqualifying, but it's a reliable predictor of onboarding cost for any new team that inherits the system.

Architecture and scalability

Codebase health describes the present. Architecture describes whether the present can support the future the transaction is being priced around. A reviewer needs to understand not just how the system is built, but whether it was built for the scale the business is projecting — and if not, what it would cost to get there.

This typically involves examining how the system handles growth in users, data volume, and transaction throughput; whether the architecture supports the kind of change the acquirer or investor is planning, such as new markets, new product lines, or integration with another system; and whether critical components are single points of failure. A system that works well at current scale but was never designed to scale further is not automatically a red flag — plenty of profitable businesses run on architectures that were never meant to be elegant — but it is a cost that needs to be identified and priced in, rather than discovered after the transaction closes.

Team and knowledge concentration

Software is built and maintained by people, and a technical review that only looks at code without assessing the team is incomplete. The central question here is often described as "bus factor": how many people would need to leave before the organization lost the ability to maintain, debug, or extend a critical part of the system?

A reviewer typically looks at how ownership is distributed across the codebase, whether documentation exists independently of any one person's memory, how the team handles onboarding, and whether there are systems that only one engineer has ever touched. Low bus-factor risk in the systems that generate the most revenue is a meaningfully different finding than low bus-factor risk in a peripheral internal tool, so this assessment needs to be weighted by business criticality, not treated as a flat headcount exercise.

Infrastructure and operational maturity

This area covers how the system is actually run day to day, not just how it's built. It includes deployment practices — is releasing a change a routine, low-risk event, or a stressful, manual, rarely-rehearsed process — as well as monitoring and alerting, incident response history, and how infrastructure is provisioned and managed.

A useful signal here is the incident history itself: not whether incidents have happened (they happen everywhere) but how they were detected, how quickly they were resolved, and whether the same category of incident recurs. An organization that discovers outages from customer complaints rather than from its own monitoring is telling a reviewer something important about its operational maturity, independent of anything in the codebase.

Security posture

Security deserves its own line item distinct from general codebase health, because the consequences of getting it wrong are disproportionate and often only materialize after a transaction closes. A reviewer typically assesses how sensitive data is handled and encrypted, what access control looks like for both customer data and production systems, whether authentication and authorization are implemented soundly, and whether there is a history of security incidents — including ones that were handled internally and never disclosed publicly.

It's also worth distinguishing between security posture and formal security certification. A company might have strong day-to-day security practices without holding a certification such as SOC 2 or ISO 27001, and conversely, holding a certification doesn't guarantee that every practice underneath it is current. A thorough review looks at actual practice, using any existing certifications as one input rather than a substitute for direct assessment.

Intellectual property clarity

This is the area most likely to surprise both sides of a transaction, because IP problems are often invisible until someone looks for them specifically. Three questions matter most:

• Open-source license compliance. Does the codebase depend on open-source components with licenses that impose obligations incompatible with how the software is being sold or distributed — for example, a copyleft license that could require releasing proprietary code under some circumstances?
• Clear ownership of custom code. Was all of the code written by employees under standard employment agreements that assign IP to the company, or does some of it trace back to founders, early contractors, or agencies whose relationship with the company was never formalized?
• Contractor and IP assignment gaps. Early-stage companies frequently bring in contractors or freelancers before formal processes exist. If one of those contractors never signed an IP assignment agreement, the company may not have clean legal title to code that a customer or engineer would assume it owns outright.

None of these issues are necessarily deal-breakers, but they are exactly the kind of finding that needs to surface before closing rather than after, because resolving an IP gap becomes far harder once the original contractor has no remaining incentive to cooperate.

Data practices

The final area concerns what data the system collects, how and where it's stored, who can access it, and what regulatory exposure follows from those practices. This overlaps with security but is distinct from it — a system can be reasonably secure against unauthorized access while still handling data in ways that create compliance exposure, such as retaining personal data longer than a stated privacy policy allows, transferring data across jurisdictions without an adequate legal basis, or lacking the technical means to fulfill a data deletion request under applicable privacy law.

For companies operating in regulated sectors, or handling categories of data subject to specific regulatory frameworks, this assessment needs enough depth to identify not just current compliance gaps but the cost of closing them.

How the areas interact: a summary framework

How findings actually get used

A common misconception is that technical due diligence produces a binary verdict — the technology either passes or it doesn't. In practice, a well-run review rarely ends there, because very few software assets are perfect and very few are so compromised that a transaction becomes impossible. Instead, findings typically flow into three distinct outcomes.

The first is valuation and deal terms. If a review identifies significant reinvestment needs — a scalability ceiling that will require a costly replatforming effort, a backlog of unpatched vulnerabilities, or licensing exposure that needs remediation — that cost can and often should be reflected in the price or structure of the deal, rather than absorbed silently by the buyer after closing.

The second is post-transaction integration planning. Technical due diligence often runs in parallel with, or just ahead of, integration planning, and the findings directly shape it: which systems can be merged cleanly, which need to be replaced, where the acquiring company will need to reinforce a team that's currently too thin, and roughly how long meaningful integration will take. A review that stops at identifying problems without informing this planning leaves significant value on the table.

The third is specific remediation requirements, which can be built into the transaction itself as closing conditions or post-closing obligations. A known vulnerability might need to be patched before close. An unresolved IP assignment might need to be obtained from a former contractor. A single-person knowledge risk might need a documented handover plan or a hiring commitment within a defined period after closing. Framing findings this way — as specific, assignable, trackable actions — is what turns a review from a report that gets read once into one that actually changes the outcome of the transaction.

Surface-level checklist review versus a substantive one

Not all technical due diligence is equal, and the difference between a shallow review and a rigorous one is usually visible in the method, not just the output.

A checklist-style review typically relies on a standardized questionnaire sent to the target company's leadership, a review of whatever documentation already exists, and a summary of the target's own answers. It's fast, it's inexpensive, and it produces a document that looks thorough at a glance. Its weakness is that it depends almost entirely on what the target chooses — consciously or not — to disclose. A company doesn't need to lie for a checklist review to miss something; it only needs to describe its own system slightly more favorably than the code actually supports, which is a natural human tendency, not necessarily bad faith.

A substantive review differs in three specific ways. First, it involves direct access to the actual codebase, not just descriptions of it — a reviewer reading real code will notice a missing test suite or an outdated dependency regardless of how the company describes its own engineering practices. Second, it involves structured interviews with engineers who work in the system day to day, not only with the CTO or a single technical leader — individual contributors often surface details, informal workarounds, and honest concerns about technical debt that a leader summarizing the system from a higher altitude wouldn't think to mention. Third, it cross-checks documentation against observed reality — if an architecture diagram says the system is built one way, a substantive review confirms that the deployed system actually matches it.

The trade-off is straightforward: a substantive review takes longer and requires reviewers with real engineering depth rather than generalist consultants working from a template. For any transaction where the technology represents a meaningful share of the value being priced, that additional time is generally the more defensible choice, since a checklist review's speed comes directly at the expense of the independent verification that makes technical due diligence worth doing in the first place.

Red flags experienced reviewers look for

Certain patterns recur often enough across technical due diligence engagements that experienced reviewers actively look for them rather than waiting to stumble across them:

• A system only one person truly understands. Especially when that person is not in a leadership role and their departure isn't contractually or financially discouraged from happening soon after a transaction closes.
• No automated tests on business-critical logic, particularly around billing, payments, or any workflow where a silent regression would be expensive or damaging to customer trust.
• Unpatched, publicly known vulnerabilities in dependencies or infrastructure — these are objectively verifiable and their presence often signals a broader pattern of deferred maintenance.
• Unclear intellectual property ownership stemming from early-stage contractor or agency work done before formal IP assignment processes were in place.
• Architecture that was never intended to reach current scale, especially when the deal thesis depends on rapid growth in usage or transaction volume.
• Manual, undocumented deployment processes that depend on a specific person's knowledge to execute correctly.
• A gap between what documentation describes and what the deployed system actually does, which suggests either the documentation is stale or the system has drifted without anyone tracking it.

None of these findings automatically kills a deal. What they do is shift the conversation from an abstract sense that "the technology seems fine" to a specific, priceable, and often solvable list of issues that both sides can negotiate around with open eyes.

Structuring a technical due diligence engagement

A well-structured engagement tends to follow a consistent sequence, regardless of the size of the transaction.

Scope definition comes first. Before any access is granted, both sides should agree on what's actually being assessed — the entire technology estate, or a specific product line; a full architectural review, or a targeted look at a known area of concern; a security-focused engagement, or a broader one. Scope should be informed by what the transaction actually depends on: a review doesn't need to be exhaustive everywhere, but it does need to be exhaustive wherever the deal's value is concentrated.

Document and code access requirements follow directly from scope. At minimum, a substantive review needs architecture documentation, access to the source code repository (ideally with commit history, which reveals a great deal about how the system evolved and who has contributed to which parts), dependency manifests, infrastructure and deployment configuration, and any existing incident or postmortem records. Access arrangements — read-only, time-boxed, conducted in a controlled environment — can be negotiated to satisfy the target company's confidentiality concerns without sacrificing the reviewer's ability to verify claims independently.

Interview structure should reach beyond a single conversation with the most senior technical leader. A useful structure typically includes one conversation focused on architecture and technical strategy with engineering leadership, and separate, shorter conversations with individual engineers who work directly in the parts of the system most relevant to the deal. These conversations are most productive when they're structured around specific, open-ended questions — "walk me through what happens when this breaks," or "what part of this system would you least want to touch," tend to surface more honest and specific information than a generic "how healthy is the codebase" question.

Reporting is where a technical review either becomes useful to the people making the actual decision, or doesn't. Most of the people reading a due diligence report — investors, board members, deal counsel — are not engineers, so the report needs to translate technical findings into business terms: what does this finding mean for cost, timeline, or risk, and what would it take to address it. A report organized purely around technical categories, without translating each finding into its practical consequence, forces a non-technical reader to do that translation themselves, and that's precisely the step a good technical due diligence engagement exists to do on their behalf. The most useful reports pair each significant finding with a plain-language description of the risk, a rough sense of the effort required to address it, and — where relevant — a recommendation on whether it should affect deal terms, be addressed before closing, or be scheduled as a post-closing priority.

What this framework is useful for beyond a single transaction

It's worth noting that this same structure is useful even outside a live deal. Engineering leaders sometimes commission an internal version of this review — sometimes described as a technical health check or architecture review — specifically to understand their own organization's exposure before entering a fundraising process or a sale, so that surprises are caught and addressed on their own timeline rather than discovered by a counterparty's reviewer during active negotiations. The questions are the same either way: is the codebase healthy, does the architecture support where the business is going, is knowledge dangerously concentrated, is the operational and security posture sound, is the IP position clean, and are data practices defensible. Answering them honestly, on a schedule the organization controls, is generally the more comfortable way to encounter this framework for the first time.

This is the kind of structured technical assessment that a technical discovery engagement is built to support — reading the actual codebase and architecture, talking directly with the engineering team, and translating findings into terms a non-technical decision-maker can act on, whether that assessment is happening ahead of a transaction or simply as part of understanding where a system stands today.