Technical Due Diligence: What Investors Actually Check

What technical due diligence actually is

Most founders who have been through technical due diligence for the first time describe a version of the same experience: they expected something like a code review, and received something considerably more involved. Technical due diligence is not primarily an assessment of code quality. It is a risk assessment framed around a business question, and the business question is always some variation of: does this technology support or undermine the value of what I am buying?

That framing matters, because it determines what gets looked at and why. An investor or acquirer is not looking for perfect code. They are trying to understand what they are taking on, and specifically where the surprises are likely to come from. A clean, well-tested codebase can still raise serious concerns if the architecture cannot scale, if one engineer holds most of the institutional knowledge, or if there is a licensing issue that creates legal exposure. Conversely, genuine technical debt is not automatically a deal-killer; it tends to become a negotiation point, with the question being whether the debt is quantifiable and whether the cost of addressing it is manageable within the deal structure.

We have been through this from both sides: conducting technical due diligence on behalf of investors assessing acquisition targets, and having our clients' technology assessed as part of funding rounds. The founders who handle the process most effectively, in our experience, are the ones who come in with a clear-eyed view of their own weaknesses rather than hoping those weaknesses will go unnoticed. Experienced reviewers have seen a great many codebases, and the gaps tend to surface regardless.

What actually gets scrutinised

The areas that a thorough technical due diligence covers follow a reasonably consistent pattern across deals, though the depth of investigation varies with the deal size, the nature of the technology, and how much time the reviewing team has been given.

Codebase quality and technical debt is usually where the process starts, because it is the most immediately legible. Reviewers look at code structure, test coverage, documentation, the consistency of development patterns across the codebase, and what the recent commit history reveals about how engineering time has been spent. What they are trying to establish is not whether the code is elegant but whether it is maintainable by someone who was not involved in writing it, and what it would cost to bring it to the standard the acquiring team requires. Technical debt that has been consciously managed and documented sits in a very different category from debt that has accumulated silently and is now load-bearing in ways nobody quite understands.

Architecture and scalability is, in some ways, the more consequential area. The question is whether the system can handle the growth the investment is intended to fund. A product doing 10,000 requests per day built on architecture that will require a full rewrite at 1,000,000 is a material risk if the investor's thesis depends on growth. Reviewers typically want to understand whether the architecture is genuinely modular or merely organised to look that way, where the single points of failure sit, and how the system behaves under load. They will ask for architecture diagrams and then compare those diagrams against the actual codebase. Discrepancies between the two are one of the more reliable early signals that documentation is aspirational rather than descriptive.

Security posture is now treated as a baseline expectation rather than a positive differentiator, and the standard has risen considerably. Reviewers look at whether penetration testing has been conducted and when, how secrets are managed (environment variables committed to version control remain a more common finding than they ought to be), what access controls exist across the organisation, and how known vulnerabilities in the dependency tree are tracked and addressed. A company that has never conducted a penetration test, has no formal process for managing CVEs, and has given no apparent thought to data access controls will raise significant concerns. A company that has done all of those things, found issues in the process, addressed them, and documented the outcome is actually better positioned than one claiming a clean record without any evidence of having looked.

Infrastructure and DevOps covers the operational maturity of the engineering organisation: can the team deploy without a manual process; do they have meaningful monitoring and alerting; is there a disaster recovery plan, and has it ever been tested. These questions reveal whether a team can operate at scale or whether growth will expose operational debt that does not yet exist at current usage levels. CI/CD pipeline maturity, environment parity between staging and production, and the presence of runbooks are all reasonable proxies for how seriously the team treats reliability as an engineering concern.

Key person risk is the area that tends to surprise founders, because it has very little to do with the code itself. It concerns whether the business depends on one or two people understanding how everything works. A codebase where 80% of the commits come from a single engineer, and where that engineer has written no documentation, is a business risk as much as a technical one. Reviewers look at contribution history and team structure, and form a view on what happens to the product if a key individual leaves, a scenario that acquisitions, by their nature, make considerably more probable.

IP and licensing often carries the most significant legal exposure, because the issues it surfaces are not always remediable quickly. Reviewers check that the company owns its own code outright (a genuine issue at early-stage companies where contractors were engaged without appropriate intellectual property assignment clauses), that there are no open source licences in the dependency tree creating unexpected obligations (GPL licences can be particularly problematic depending on the commercial context), and that data handling practices meet the regulatory requirements for the jurisdictions in which the product operates. GDPR compliance is a standard agenda item on any European deal.

Red flags versus amber flags

Not all findings carry the same weight, and understanding the distinction between something that stops a deal and something that becomes a negotiation point is useful whether you are conducting the process or being assessed by it.

Red flags are findings that represent legal exposure the buyer cannot readily accept, fundamental architectural problems requiring a rewrite before the product can scale, or evidence of deliberate concealment. An unresolved critical vulnerability in a dependency handling payment data, a codebase containing material copied from a third-party source without a licence, or a claim in the pitch materials directly contradicted by the codebase are all examples of findings that tend to stop or substantially reshape transactions. The common thread is that they cannot be addressed after close without significant cost or legal risk.

Amber flags are findings that are real and material but manageable with the right deal structure. Technical debt with a clearly scoped remediation plan is a negotiation point, not a veto; so is a security posture that is actively improving, a deployment process that is manual but controlled and documented, or an architecture with sensible seams that could be refactored without starting from scratch. Experienced reviewers know the difference between a codebase that is imperfect and one that is genuinely unmanageable, and they expect to find the former.

What to expect from the process itself

A technical due diligence engagement typically runs between one and three weeks, depending on the complexity of the system and the scope the investor has defined. Access requirements vary, but they generally include read access to the codebase or a representative portion of it, architecture documentation, access to deployment and infrastructure configuration, and time with at least one senior engineer to walk through the system and answer questions. The output is a written report structured around the areas above, with findings assessed by severity and supported by evidence from the review.

The report will be shared with the investor's deal team and will often inform the deal terms directly. A significant finding may result in an escrow arrangement, a price reduction, or a remediation schedule that becomes a condition of close. Founders should not expect the review to return an entirely clean result even when the technology is genuinely good. The reviewer's job is to identify and document risk, and a report that finds no issues is usually a report that did not look particularly hard.

From the engineer's perspective, the process is not as adversarial as it can feel from the inside. Reviewers are trying to understand, not to catch anyone out. Honest answers to direct questions are considerably more useful than defensive ones, and experienced reviewers can tell the difference with some reliability. The CTO who says "yes, the deployment process is manual and we know it, here is what we plan to do about it" leaves the process in a better position than the one who says it works fine for current scale and hopes that ends the conversation.

How to prepare

The most effective preparation is not cosmetic: you will not persuade a competent reviewer by tidying the commit history or updating the README the week before the process begins, and attempting to do so wastes time that could go towards things that actually matter.

What matters is making the genuine state of your technology legible. If you have technical debt, document it: where it lives, why it exists, and what addressing it would require. If your deployment process is manual, write the runbook so the reviewer can see it is at least controlled and understood rather than ad hoc. If you have not conducted a penetration test, arrange one before the process starts, or be prepared to offer one as a condition of close. If your architecture diagrams do not reflect the current state of the system, update them. The gap between documentation and reality is a larger flag than imperfect architecture that is honestly described.

The key person risk question is worth addressing in advance if it applies. If you are the technical co-founder and also the person who understands how everything fits together, spend the weeks before a process writing things down: system overviews, deployment procedures, the reasoning behind decisions that are not obvious from the code. Documentation written last month will not fully satisfy a sceptical reviewer, but it signals an awareness of the problem and a degree of seriousness about addressing it, which is a rather different thing from a team that has not considered it at all.

Technical due diligence is a process through which a buyer builds a picture of what they are taking on, not a test you pass or fail. The goal is not a perfect picture; it is an honest one, and founders who understand this early tend to be better served by the process than those who approach it as something to be managed.