Start from the acquisition thesis
Before opening a repository, ask the deal team what the acquisition is for. A buyer paying for revenue needs the product to keep running and scale. A buyer paying for the team needs the people to stay. A buyer paying for technology needs it to be separable and legally owned. A buyer folding customers onto its own platform cares mainly about data migration. Each thesis points your two weeks somewhere different, and a review that spreads effort evenly answers none of them well.
Ownership changes the question too. A private-equity buyer running the company standalone wants to know whether it can grow without a rebuild. A strategic acquirer wants the integration bill. A captive-centre or carve-out deal adds the question of what the target depends on from its current parent.
Agree the rules of access early. Counsel and the deal team decide what you may see before signing, and in some jurisdictions competition rules restrict information exchange between competitors, which can mean a restricted clean team. Plan around those limits rather than discovering them on day eight.
A two-week technical due diligence plan
The schedule below is illustrative and assumes data-room access from day one, repository read access by day three, and four interview slots with the target's engineers.
| Days | Activity | Output |
|---|
| 1-2 | Read the data room: architecture documents, hosting bills, incident history, pen-test reports, org chart | A list of claims to verify |
| 3-5 | Repository and pipeline review; dependency and licence scan; commit history by component | Ownership map, licence inventory |
| 6-8 | Interviews with the CTO and three engineers; live walk-through of a deploy and an incident | Verified versus asserted claims |
| 9-10 | Scalability against the growth plan; hosting cost per customer; security controls check | Risk register with severity |
| 11-12 | Price the remediation and integration work | Cost estimate with assumptions |
| 13-14 | Write the report; brief the deal team | Recommendations per finding |
Insist on a live walk-through. Watching an engineer ship a change and explain the last incident tells you more in an hour than a week of documents, because documents in a data room are written to sell.
Six areas and the red flag in each
| Area | What you look at | Red flag |
|---|
| Architecture and scale | Peak utilisation, the component that only scales vertically, multi-tenancy model | Growth plan needs a rebuild nobody has priced |
| Security | Latest pen-test and what was fixed, MFA on production access, secrets in repositories, past breaches | Critical findings open for months; a breach not disclosed in the data room |
| People | Who commits to which component, who answers in interviews, contractor reliance | One or two people behind the core service |
| Technical debt | Unsupported runtimes and databases, test coverage of the money paths, manual deploys | End-of-support software on the critical path |
| Licences and IP | Software bill of materials, copyleft components, contractor IP assignment | Copyleft code in a distributed product; code written by contractors without assignment |
| Operations and cost | Hosting bill trend, cost per customer, on-call load, incident frequency | Hosting cost growing faster than revenue |
A SOC 2 report or an ISO 27001 certificate tells you an auditor assessed a defined set of controls, or a management system, for a stated scope. It does not tell you the product is secure, so read the scope and any exceptions or nonconformities rather than the cover page.
On licences, your job is the inventory, not the verdict. Whether a GPL or AGPL component creates obligations depends on how the software is distributed or served and on the buyer's plans. Counsel decides that, and they can only decide it if you hand them a precise list.
Key-person risk usually decides the integration plan
The seller's org chart shows reporting lines. It does not show who holds the knowledge. Commit history by component does, and so do the interviews: watch who the other engineers defer to when you ask about the billing service. If two people wrote most of the core and both hold equity that vests on close, you have found the largest risk in the deal.
Your recommendation names the risk and the people-dependent components. Retention terms are a commercial and HR decision for the deal team, so you supply the evidence and leave the figure to them.
Pricing the findings
Findings change a deal only when they carry a number. The estimate below is illustrative. It assumes a loaded cost of 15,000 per engineer-month in the deal currency; substitute the buyer's own rate.
| Finding | Remediation | Engineer-months | Illustrative cost |
|---|
| Copyleft library in the distributed client | Replace the component | 2 people x 3 months = 6 | 90,000 |
| Database on an end-of-support version | Upgrade and re-test | 4 people x 4 months = 16 | 240,000 |
| No MFA on production; secrets in repositories | Enforce MFA, rotate and vault secrets | 2 people x 2 months = 4 | 60,000 |
| No alerting beyond uptime checks | Add service-level monitoring | 1 person x 3 months = 3 | 45,000 |
| Total | | 29 | 435,000 |
The total is the input finance needs. Whether it becomes a price reduction, an escrow or a pre-close condition is the deal team's call. You also state the schedule cost: twenty-nine engineer-months are capacity the combined team cannot spend on the growth plan in the first year.
Grading the code instead of the deal
Weak diligence reads like an architecture review. It scores code style, framework choices and test coverage, then concludes the codebase is "of mixed quality". That is true of every codebase, and nobody can act on it.
Strong diligence stays tied to the acquisition thesis. "The growth plan assumes five times the customers, and the tenant model tops out well before that without a re-architecture we estimate at six months" changes a valuation. "The code is inconsistent" changes nothing. Mark each finding as verified first-hand or asserted by the seller, because the deal team must know which of your statements they can lean on.
When to recommend walking away
Few technical findings kill a deal outright, since most can be priced. The exceptions are findings that break the thesis or cannot be bounded. Examples include an undisclosed breach of customer data, IP the target does not own and cannot clearly obtain, a core product that only works through manual operator effort the seller presented as automation, and a team whose irreplaceable members have signalled they will leave. Report these on day one, not on day fourteen, so the deal team can pause before spending more on advisers.
Every finding in a technical due diligence report should answer one question for the deal team: what does this do to the price, the conditions, or the decision to proceed?
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).