Explainer
Technical due diligence is an independent review of a company’s technology before a transaction. It examines the code, systems, people, and engineering practices to explain the risks, opportunities, and investment needs behind the deal.
This guide is for anyone meeting the term for the first time: acquirers, investors, lenders, founders preparing for a sale, and the engineering teams on either side of the table.
Tech DNA has been doing this work since 2009. In 2014, The Washington Post reported on the rise of technical due diligence and interviewed our founder, Mike Kelly, about what these reviews find.
At a glance
What it answers
Can the technology and team support the buyer’s plans, and what will it take to get there?
When it happens
Usually during exclusivity. At Tech DNA, a Full Assessment typically takes 8–21 days from code delivery; an Early Take takes about a week.
What you receive
A plain-language executive summary, evidence-backed findings ranked by business impact, and practical next steps.
What does technical due diligence cover?
The right questions depend on the acquisition thesis. These are the starting points we use to connect the technology to what a buyer plans to do with the business.
Can the platform support the growth plan?
Evidence we examine
Architecture, performance data, database design, capacity constraints and infrastructure costs
Why it matters
Growth may require investment or engineering work that the financial model does not yet reflect.
How dependent is the business on a few people?
Evidence we examine
Code ownership, commit history, documentation, deployment access and team interviews
Why it matters
Critical knowledge concentrated in one person can create retention risk and slow development or integration.
Which technical debt actually matters?
Evidence we examine
Deferred maintenance, dependencies, test coverage, recurring incidents and difficult-to-change areas
Why it matters
Some shortcuts remain sensible. Others create costs or constraints that become material under the buyer’s plans.
Where are the meaningful security exposures?
Evidence we examine
Authentication, permissions, secrets handling, data flows and vulnerability management
Why it matters
The question is what an attacker could reach and what the business would need to do about it.
Can the team deliver the roadmap?
Evidence we examine
Release history, engineering practices, staffing, delivery bottlenecks and roadmap assumptions
Why it matters
Product commitments and growth forecasts depend on the team’s ability to ship reliable software.
Are there constraints on how the technology can be used?
Evidence we examine
Open-source dependencies, third-party services, software provenance and data usage
Why it matters
Technical findings may reveal licensing, ownership or data-rights questions for counsel to resolve.
What would integration require?
Evidence we examine
APIs, identity systems, data models, deployment environments and architectural dependencies
Why it matters
Buyers need a realistic view of integration effort and sequencing before committing to synergy assumptions.
Do differentiated technology and AI claims hold up?
Evidence we examine
The underlying implementation, external dependencies, evaluation methods and supporting evidence
Why it matters
The buyer needs to understand which capabilities are defensible, which are reproducible and what it costs to sustain them.
Timing
How does the process fit the deal timeline?
Most full assessments take place during exclusivity. An optional Early Take can inform the decision to proceed; the findings then support decisions before close and planning afterwards.
Before the letter of intent
A short first look, sometimes called an Early Take. About a week. Enough signal to walk away or to commit to a full process.
During exclusivity
The full assessment. Typically 8–21 days from receiving the code. Review of the code, the team, and the specific claims the deal rests on.
Signing and closing
Findings feed terms, closing conditions and remediation lists. Most findings change terms rather than whether the deal happens.
After close
The same findings become the integration plan and the first technical workstreams. Some buyers commission a follow-up to confirm what was fixed.
What is in the report, and what does it mean for the deal?
A technical finding becomes useful when it changes how the buyer evaluates the acquisition. These illustrative examples show how evidence can inform a decision before close.
What you receive
The report brings together an executive summary, detailed findings ranked by business impact, and practical remediation guidance. These examples show how the evidence can influence decisions before close.
The platform works today, but growth changes the equation.
Finding
The application serves current customers reliably, but a shared database becomes a bottleneck at the transaction volumes assumed in the growth plan.
Business implication
The growth target may require architectural work, additional infrastructure spending and engineering capacity that would otherwise support the product roadmap.
Decision before close
Include the investment and sequencing in the acquisition model, and test whether the proposed growth timeline remains realistic.
The code is maintainable, but critical knowledge is concentrated.
Finding
Several engineers contribute to the product, but one person understands the billing logic and performs production releases.
Business implication
That person’s departure could disrupt releases, incident response and changes to a revenue-critical system.
Decision before close
Make retention and knowledge transfer explicit priorities, with a practical plan for shared ownership and deployment access.
A useful capability may offer more upside than the presentation suggests.
Finding
A target has a well-separated processing engine that could support another product in the buyer’s portfolio, although its customer-facing application is less reusable.
Business implication
There may be a focused reuse opportunity without replacing either company’s entire platform.
Decision before close
Validate that opportunity against the buyer’s requirements and scope the interfaces, data changes and dependencies needed to pursue it.
These are illustrative scenarios, not descriptions of specific client engagements.
Practicalities
What affects the cost of technical due diligence?
At Tech DNA, engagements are fixed-fee. The fee reflects surface area (the products, codebases, and teams involved), along with scope and depth. Priorities can be refined as findings emerge, so the agreed effort stays focused on the deal.
Good shortcuts are not automatically bad technology
Lean teams make trade-offs. A monolithic application, a manual onboarding process or a deferred refactor may be the right choice for a company’s stage, customers and resources.
Technical due diligence should explain whether those choices still support the business, and whether they will support the buyer’s plans.
A potentially sensible choice
A monolithic application that a small team can understand and deploy efficiently
When to look closer
Growth, reliability requirements or multiple engineering teams demand separation the architecture cannot readily support.
A potentially sensible choice
Manual customer onboarding while the company learns what customers need
When to look closer
The acquisition model assumes rapid customer growth, but onboarding effort rises with every new account.
A potentially sensible choice
Deferred refactoring in stable, rarely changed parts of the product
When to look closer
The roadmap depends on changing those same areas quickly, and the current design makes that work expensive or unpredictable.
A potentially sensible choice
Limited automated testing around an early, fast-changing feature
When to look closer
Revenue-critical workflows change frequently without reliable checks or a safe way to recover from a failed release.
A potentially sensible choice
Deep expertise concentrated in a founder during the company’s early stages
When to look closer
The founder plans to leave, while essential knowledge and operating access remain undocumented and unshared.
Across hundreds of deals, Tech DNA has seen how these choices play out in practice. We use that experience to assess a target in the context of its stage, product and acquisition thesis.
The result is a practical distinction: what can stay, what needs attention, and what could prevent the buyer from achieving the plan.
Comparisons
How does technical diligence compare with other reviews?
Versus IT due diligence
IT diligence inventories infrastructure, licenses and vendors: what the company runs. Technical diligence reads what the company built. For a software business the product is the asset, so the code is where the value and the risk live. We do both.
Versus commercial due diligence
Commercial diligence asks whether customers want the product and will keep paying. Technical diligence asks whether the product can deliver what has been sold, and what it will cost to keep the promise.
Versus a code scan
A scanner is an input. It flags patterns, produces a grade, and misses context in both directions. We use that input to decide where to dig deeper.
Versus a security audit or penetration test
A penetration test attacks a running system to find what an intruder could reach. Diligence reads the code and the practices behind it. Deals often need both. Pairing a pen test with tech diligence often leads to more comprehensive findings for both workstreams.
Versus your own engineers
Your engineers know your stack, not theirs, and putting them in front of a seller’s code creates trade-secret exposure if the deal collapses. An independent review team keeps them clean, removes deal-team bias, and is easier for the seller to accept.
Choosing a provider
How do you choose a technical diligence provider?
Large firms bring process and headcount. Specialists bring engineers who have run these systems. The questions below separate them faster than a proposal does.
1. Do you read the code, and how much of it?
The single most important question. Some providers sample. Some rely on interviews and scans. All of it, including commit history, dependencies and deployment, is the standard to ask for.
2. Who exactly does the work?
Ask who will do the work and how the team combines its expertise. How many years have the consultants spent building and running systems? Will the people investigating the technology help shape the report and join the readout?
3. Is the conclusion a human judgment or a tool output?
A grade out of ten is not an answer. Ask how findings are ranked, and how they are contextualized in a readout.
4. Do you assess the team as well as the code?
The code is a snapshot. The team is the trajectory. A review that skips the people misses the full story.
5. How is the code protected?
Read-only access, a named project team, separate data rooms from the buyer, nothing retained afterwards. A provider who cannot describe this in one paragraph will not reassure a nervous seller.
6. Can you show a sample report, and how did the findings land?
The report is the product. Ask to see one, redacted, and ask how often the firm checks its own calls after close.
If your company is the one being reviewed
What should sellers and target teams expect?
A good diligence team asks for read-only access, respects your engineers’ time, tailors questions to your stack, and never shares your code with the buyer. If your company is the one being reviewed and you have questions, talk to us directly.
Common questions