Technical Due Diligence: How to Evaluate a Company's Technology Before You Buy

Technical due diligence is the structured examination of a target company's technology, team, and engineering practices before an acquisition, investment, or major vendor commitment, and its job is to answer one question: does the technology support the price? A rigorous review takes two to six weeks, examines seven areas ranging from architecture to open-source license exposure, and typically costs from the low tens of thousands of USD for a boutique review to several hundred thousand for a large-deal engagement, a rounding error against the cost of the failure modes it exists to catch. The problem for executives on the buy side is that a rigorous review and a checkbox exercise produce identical-looking reports, and most buyers cannot tell them apart until after the deal closes. This guide is the framework for telling the difference.

Key Takeaways

• Technical due diligence examines seven areas: architecture and scalability, technical-debt load, security posture, team and key-person risk, IP and open-source license exposure, infrastructure cost trajectory, and data quality and portability. A report that skips any of them is a checkbox exercise regardless of its page count.
• Few findings kill deals. Most findings reprice them. The deal-killers are unresolvable ownership problems: IP that does not belong to the seller, copyleft-contaminated core code, an undisclosed breach, or fraud in the technical claims. Almost everything else converts to money, time, or deal terms.
• Technical debt is not a red flag by itself; every functioning company carries it. The red flag is unmanaged debt: no inventory of it, no cost attached to it, and a team that cannot say what they would fix first. The distinction between debt as engineering complaint and debt as capital-allocation signal decides how to price it.
• AI-era diligence adds a new layer: model and provider dependencies, training-data provenance and the rights attached to it, inference cost structure, and whether claimed "AI capability" is proprietary work or a thin wrapper on a frontier API.
• Scope follows the decision, not the target. A two-week review is enough to find deal-killers and major repricing items; a six-week review is for confirming an integration plan and a technology roadmap. Buying the long version to answer the short question wastes money; buying the short version to answer the long question is how post-close surprises happen.

What Technical Due Diligence Actually Examines

A rigorous review covers seven areas, and the discipline is in covering all of them at the depth the deal requires rather than going deep on the two the reviewers find interesting.

Architecture and scalability. The question is not whether the architecture is modern; it is whether the architecture supports the growth assumptions in the deal model. A monolith serving ten thousand customers reliably is a better asset than a half-finished microservices migration, and reviewers who grade on fashion rather than fitness produce exactly the wrong signal. What matters: where the system breaks at ten times current load, what the single points of failure are, and how much of the roadmap in the pitch deck the current architecture can actually carry.

Technical-debt load. Every company carries technical debt; the term itself, coined by Ward Cunningham in 1992, describes a deliberate trade of future cost for present speed. Industry evidence puts the ongoing tax at roughly a third of engineering time spent on debt and maintenance rather than new work (Stripe, The Developer Coefficient, 2018). Diligence does not ask whether debt exists. It asks whether the debt is inventoried, priced, and managed, or invisible and compounding. The deeper argument that debt is a capital-allocation problem rather than an engineering complaint is made in Technical Debt Is a Leadership Problem, and it is the correct frame for a buyer: unmanaged debt is a hidden liability being transferred at close.

Security posture. The review covers vulnerability management, access control, incident history, and compliance certifications, but the highest-value question is the uncomfortable one: has there been a breach, disclosed or not, and would this organization know if there had been? A company with no logging, no incident-response process, and a clean incident history does not have a clean history; it has no visibility.

Team and key-person risk. Technology does not maintain itself, and in most acquisitions the asset being bought is substantially the team that built it. Diligence maps who holds the critical knowledge, what is documented versus tribal, and what happens to the system if the two or three load-bearing engineers leave at close, which is precisely when they are most likely to. Retention terms in the deal should follow directly from this map. How the team is structured relative to its data and platform responsibilities is its own signal, and the patterns are covered in the modern data team structure guide.

IP and open-source license exposure. The buyer needs to know that the seller owns what it is selling. That means employment and contractor agreements that actually assign IP, and an audit of open-source usage against license obligations. The scale of the surface is well documented: Synopsys's OSSRA report found open-source components in 96 percent of audited codebases, with 84 percent containing at least one known vulnerability (Synopsys, 2024). Most open-source usage is benign. The exposure that matters is copyleft licenses in code the company distributes, and dependencies whose licenses changed under the company without anyone noticing.

Infrastructure cost trajectory. Current cloud spend matters less than its slope. Diligence models how infrastructure cost scales with the revenue growth in the deal model, because an architecture whose unit costs grow linearly with usage quietly repriced the margin assumptions. The executive framing for reading a cloud bill and its trajectory is laid out in the executive guide to cloud costs.

Data quality and portability. For any company whose value story involves data or AI, diligence examines whether the data is clean enough to use, whether the company has the rights to use it for the purposes in the roadmap, and whether it can be moved. Data locked in a legacy schema with no export path, or collected under terms that do not permit the intended use, is an asset on the slide deck and a liability in the data room.

Red Flags That Kill Deals Versus Red Flags That Reprice Them

The most useful mental model for the buy side is that technical findings sort into two bins, and the bins are not "good" and "bad." They are unresolvable and priceable.

The unresolvable bin is small. IP the seller does not actually own, because contractor agreements never assigned it or a co-founder left with an ambiguous claim. Copyleft-licensed code compiled into the core distributed product, obligating source disclosure that destroys the proprietary value. An undisclosed material breach, which is both a liability of unknown size and a signal about everything else in the data room. And fabricated technical claims: benchmarks that do not reproduce, "proprietary AI" that is a thin wrapper, customer-scale numbers the infrastructure could not have served. These kill deals not because the technology is bad but because they cannot be fixed with money on a knowable schedule, and because each one impeaches the rest of the seller's representations.

Everything else is the priceable bin, and this is where undisciplined buyers destroy value in both directions. A legacy stack that needs a two-year modernization is not a deal-killer; it is a number, and the number belongs in the price. Key-person concentration is a retention package. A security program that is two years behind is a remediation budget and a warranty clause. An infrastructure bill growing faster than revenue is a margin adjustment in the model. Walking away from a priceable finding is paying a deal-search cost to avoid a discount conversation; ignoring a priceable finding is paying full price for a discounted asset. The report the buyer should demand is one that puts a cost and a timeline on every finding, not one that ranks them by severity color.

How AI Changes the Checklist

Diligence on a company with AI in its value story adds a layer that classic checklists were not built for, and buyers relying on those checklists are systematically mispricing AI-era targets in both directions.

Model and provider dependencies. If the product's core capability is a frontier API, the diligence questions are concentration questions: what happens to unit economics if the provider raises prices, changes terms, or ships the capability as a feature. Dependency is not automatically bad; undisclosed and unhedged dependency is. The honest version of this finding prices the wrapper as a wrapper: distribution, workflow, and data may still justify the deal, but "proprietary AI" premiums should not survive the discovery that the AI is rented.

Training-data provenance. If the company trained or fine-tuned its own models, the buyer inherits the provenance of the training data: what it was, where it came from, and what rights attached to it. Models trained on data the company had no right to use are a liability with the model's value attached, and unlike code, a model cannot be easily audited after the fact for what went into it. The paper trail is the asset.

Inference cost structure. AI features carry a per-use cost that classic software does not, so gross margin becomes a function of usage patterns. Diligence models inference cost per customer against pricing, because an AI feature priced flat against a cost that scales with usage is a margin time bomb with a fuse set by the most enthusiastic customers.

Evaluation discipline. The single fastest signal of AI engineering maturity is whether the company can show an evaluation harness: versioned test sets, quality metrics tracked across model and prompt changes, regressions caught before customers found them. A company that ships AI on vibes will have its first quality incident on the buyer's watch.

Who Runs It, What It Costs, and the Two-Week Versus Six-Week Decision

Three models exist for staffing the review. Specialist diligence firms bring pattern recognition across hundreds of deals and produce reports investment committees are comfortable with. The buyer's own senior engineers bring context on integration reality that no outsider has. The hybrid, a specialist firm paired with two or three of the buyer's engineers embedded in the review, is the strongest configuration for acquisitions, because the outsiders bring the benchmark and the insiders bring the "we have to live with this" test. What does not work is assigning it to whoever is free, or to advisors with an incentive to see the deal close. Market rates as of 2026 run from roughly 30,000 to 80,000 USD for a boutique two-to-three-week review of a mid-sized target, to several hundred thousand for a large-deal engagement with security testing included; against a deal measured in the tens or hundreds of millions, diligence spend is insurance priced at well under one percent of the exposure.

The scoping decision is a two-week review versus a six-week review, and the choice follows from the decision the review must support. A two-week review answers "is there a reason not to do this deal, and what should it reprice": it finds the unresolvable items, sizes the major priceable ones, and interviews the load-bearing people. It is the right scope for competitive processes with compressed timelines, for smaller checks, and for vendor commitments. A six-week review answers "what exactly are we buying and what is the plan for it": it adds code-level sampling, an infrastructure cost model, security testing rather than security questionnaires, and an integration roadmap with sequencing and cost. It is the right scope when the deal thesis depends on the technology itself rather than the market position, and its structure has more in common with a disciplined software evaluation than most buyers expect; the same time-boxed method described in how to evaluate enterprise software in 30 days applies with the stakes raised.

The scoping mistake that matters is not choosing the short review; it is choosing the short review and then treating its output as if it were the long one. A two-week review that found no deal-killers has cleared the deal, not the integration plan.

The Executive's Test for a Rigorous Review

A buyer who cannot read the codebase can still audit the review itself. Four tests separate rigor from theater. First, findings carry costs and timelines, not just severity colors; a finding without a number is an opinion. Second, the reviewers talked to engineers, not just executives, and the report quotes what the engineers said about what they would fix first. Third, the report says what was not examined and why; a report with no stated limitations examined nothing deeply enough to find its own edges. Fourth, at least one finding is inconvenient for the deal. Diligence that returns only comfort was scoped, staffed, or incentivized to return comfort, and it is the most expensive kind of cheap.

FAQ

What is technical due diligence?

Technical due diligence is the structured evaluation of a company's technology before an acquisition, investment, or major vendor commitment. It examines architecture, technical debt, security, team risk, IP and open-source exposure, infrastructure cost, and data quality, and converts what it finds into deal terms: price adjustments, warranties, retention packages, and remediation budgets. Its purpose is to verify that the technology supports the price and the roadmap being paid for.

How long does technical due diligence take and what does it cost?

A focused review takes about two weeks and identifies deal-killers and major repricing items; a comprehensive review takes four to six weeks and adds code sampling, security testing, cost modeling, and an integration plan. As of 2026, boutique reviews of mid-sized targets typically run from roughly 30,000 to 80,000 USD, with large-deal engagements reaching several hundred thousand. Against typical deal sizes, that is under one percent of the exposure it protects.

What red flags kill a deal in technical due diligence?

The genuine deal-killers are ownership and honesty problems: IP that was never assigned to the company, copyleft-licensed code in the core distributed product, an undisclosed breach, or technical claims that turn out to be fabricated. Most other findings, including heavy technical debt, key-person risk, and weak security programs, are priceable: they convert into price adjustments, deal terms, or remediation budgets rather than reasons to walk away.

How is due diligence different for AI companies?

AI targets add four questions to the classic checklist: how dependent the product is on a frontier model provider and what that dependency does to margins, where training data came from and what rights attached to it, how inference cost scales against pricing, and whether the company has real evaluation discipline or ships on intuition. The most common finding is "proprietary AI" that is a thin wrapper on a rented model, which reprices the premium without necessarily killing the deal.

Who should perform technical due diligence?

The strongest configuration pairs a specialist diligence firm, which brings cross-deal pattern recognition, with senior engineers from the buyer, who bring integration context and have to live with the result. Avoid staffing it with whoever is available or with advisors whose fees depend on the deal closing. Independence of judgment is worth more than any particular methodology.

Related reading on FinTekCafe

• Technical Debt Is a Leadership Problem, Not an Engineering One
• How to Evaluate Enterprise Software in 30 Days
• The Executive Guide to Cloud Costs
• How to Structure a Modern Data Team