Consulting
Technical Due Diligence Before Investment or Acquisition
A codebase red flag rarely kills a deal outright — more often it changes the price, the escrow terms, or the post-close commitments. What gets reviewed, and why rushing it under deal pressure produces worse findings.
In short
Technical due diligence is a one-off, deal-timed review of a company’s technical state before an investment or acquisition: codebase, architecture, bus factor, security, infrastructure and the real cost of continuing to develop the product. Unlike an ordinary code review, the goal is not code style, it is risk to the deal — a finding does not always kill it, more often it adjusts the price, the escrow, or the post-close remediation terms.
Who needs this, and when
Three typical clients: an investor before a funding round who wants to understand what they are actually investing in technically, not just the pitch deck; a business or product acquirer, for whom technical state directly affects deal price; and, less often, the founder themselves ahead of raising, preferring to find problems and fix them ahead of time rather than have an investor find them at an inconvenient moment.
This is fundamentally a one-off engagement tied to a deal timeline, not ongoing consulting. The report is produced against a specific decision window, not at the relaxed pace of a routine technical audit.
What actually gets reviewed
| Area | What gets checked |
|---|---|
| Codebase | Quality, test coverage of critical logic, accumulated technical debt |
| Architecture | Scalability, single points of failure |
| Bus factor | How many people understand the system end to end, what happens if a key developer leaves |
| Security | Baseline checks: password storage, secrets in the repository, access rights |
| Infrastructure and dependencies | Currency, licensing, vendor lock-in |
| Cost to continue | A real estimate of what continuing to develop the product will cost after the deal |
Red flags that show up disproportionately often
Some findings recur from review to review often enough to name concretely rather than abstractly. The entire system understood by one person who is not staying with the company after the deal, not a hypothetical risk but a direct threat to business continuity in the very first weeks after close. Zero tests on payment or other business-critical logic means any change to that part of the system is made blind.
Actively unmaintained dependencies with known vulnerabilities, a quiet risk that stays invisible until someone exploits the known hole. Undocumented "temporary" architecture decisions from three years ago that quietly became load-bearing, a classic sign of a system whose actual shape nobody fully remembers any more, including the people who built it.
How findings translate into deal terms
This is the part worth understanding from the founder’s side of the table too: a red flag almost never means an automatic deal failure. Far more often it becomes a specific, negotiable term: a price adjustment reflecting the real cost of fixing the problem; part of the sum held in escrow until a specific finding is resolved; or a seller commitment to fix the issue within an agreed window after close.
Understanding this mechanism eases some of the anxiety on both sides: the point of the review is not to find a reason to walk away, it is to give both parties an accurate risk picture so the deal terms honestly reflect it.
What the target company needs to provide, and the timeline
A proper review needs repository access with full commit history, deploy logs, incidents from the last 6 to 12 months and, ideally, a short conversation with the current technical team. A realistic timeline is 1 to 2 weeks, synchronised with the overall deal schedule rather than the pace of ordinary consulting.
Rushing under deal pressure is a direct threat to the quality of the findings. A review compressed into two or three days under closing pressure physically cannot reach the less obvious problems, it only finds what sits on the surface, and the most expensive risks almost never sit there.
How this differs from a standard code review
An ordinary code review asks "is this code well written." Technical due diligence asks "what risk does this system’s state pose to this specific deal." The difference is not terminological: due diligence might judge stylistically imperfect code as low deal-risk if, say, that part of the system will be rewritten entirely in year one regardless, and conversely flag formally tidy code as high risk if the entire thing is understood by one departing developer.
Frequently asked questions
Does a technical red flag always kill the deal?
Almost never automatically. A finding usually turns into a specific, negotiable term: a price adjustment, part of the sum held in escrow until the issue is fixed, or a seller commitment to fix it within an agreed window after close. The point of the review is to give both sides an accurate risk picture, not to find a reason to walk away.
How long does technical due diligence take?
Realistically 1 to 2 weeks, synchronised with the overall deal schedule. That requires repository access with full commit history, deploy logs and incidents from the last 6 to 12 months. Compressing the review to two or three days under deal pressure directly reduces the quality of the findings, only surface-level issues get found.
How is this different from a regular code review or audit?
A regular code review or general technical audit assesses code and system quality on its own terms. Due diligence assesses risk specifically to this deal: a finding might be non-critical for the product to keep running, but critical for the investor in the context of the deal itself, for instance if the entire codebase is understood by one developer who is leaving after the sale.
Who typically commissions technical due diligence?
Most often an investor before a funding round or a buyer before acquiring a business or product. Less often the founder themselves ahead of raising, to find and fix problems ahead of time rather than have an investor surface them at an awkward moment in negotiations.
Need a hand with this?
We do this work, not just write about it. Describe the task and we will scope it and send a staged estimate.
Related services
- CTO as a serviceAn early-stage startup often cannot afford a full-time technical director, but without a technical voice in the room, the company risks the wrong stack, the wrong hires, or a product pitched badly to an investor. CTO as a service fills that role part time, at exactly the level the company needs right now.
- IT consulting and product auditThe most expensive mistakes in software happen before the first line of code: a misread problem, a stack chosen out of a contractor’s habit, and a specification that does not exist. Consulting exists to settle all of that before the development meter starts running: what to build, out of what, at what cost and in which order. The result is a document, not an opinion on a call.
Read next
- CTO as a Service: When a Startup Needs Technical LeadershipA non-technical founder regularly makes technical decisions with no margin for error. CTO as a service is not a Series A luxury, it is a way of not paying for those mistakes later.
- How to Choose a Development Contractor: The Question List and the Red FlagsA practical guide to choosing a development vendor: who needs a freelancer and who needs an integrator, the 25 questions for the first call, how to verify portfolio cases and what belongs in the contract.
- How to Choose a Tech Stack: Criteria That Outlive the HypeA stack is a five-year commitment usually made in a single call. Here is the order the decisions should be taken in, the criteria that carry real weight, working stacks for six project archetypes and what a wrong choice costs.