Technical due diligence: what investors and acquirers actually check

Technical due diligence compares a product’s claims with evidence: its architecture, delivery history, operating costs, access controls and dependence on individual people. It can help an Indian startup prepare for an investor review or help an SME understand a software business it is considering acquiring.

This checklist is a preparation guide. The scope and time required depend on the system, access available and questions the decision-maker needs answered. A technical review does not replace legal, financial or independent security advice.

How a diligence team spends its two weeks

A well-run technical diligence has the same shape whether the buyer is a private equity fund, a strategic acquirer, or a Series C lead. NDA first, then least-privilege read-only access — repositories, CI, cloud console, issue tracker — plus a document set and interview slots. The evidence request lands on day one, and it looks something like this:

Evidence request — technical due diligence, day 1

Access:     read-only repos, CI/CD, cloud console, issue tracker (revocable)
Documents:  architecture diagram, ADRs, runbooks, last pen test + remediation
Data:       12 months of cloud invoices, deploy history, incident postmortems
People:     45 minutes each — CTO, tech leads, whoever owns production deploys

Notice the ratio: mostly artifacts, very few meetings. That is deliberate. Interviews tell the team what you believe; artifacts tell them what is true. Commit history, CI logs, and cloud bills are nearly impossible to stage on short notice, which is exactly why they get read first and trusted most.

The output is a written report with a risk register — findings ranked by severity, each priced as a cost to fix or a risk to carry, so the deal team can adjust numbers instead of arguing adjectives. Agree the scope and timeline after confirming access. If the review is time-limited, its report should identify what was sampled and what remains unexamined.

The five checks that decide the report

Ask what diligence covers and you will get a two-hundred-line checklist. Ask what actually changes the outcome and it collapses to five checks.

Architecture honesty

The first substantive task is a diff between the architecture diagram and the running system. Not because anyone expects a perfect match — there never is one — but because the size and direction of the gap is the best available proxy for engineering culture. A team that says "this module is a mess, here is why, here is the containment plan" reads as low risk. A team whose diagram shows services that do not exist reads as a team that may be wrong about other things too.

Buyers do not penalize monoliths, either — that surprises founders every time. A boring monolith the team fully understands is a better asset than a microservice estate nobody can explain. What gets penalized is unacknowledged complexity.

Diligence does not price your code. It prices the gap between your story and your evidence.

Bus factor

Commit history is an organizational X-ray, and diligence teams read it as one. Concentration analysis on the repositories answers a question no org chart can: when a single engineer has authored the majority of commits to the core billing service and has no retention agreement anywhere in the deal, that finding moves real money. The buyer's underlying question is blunt: if two named people resign the week after closing, does the roadmap survive the quarter?

Where knowledge accumulates is a structural decision made long before it becomes a diligence finding — we walked through the mechanics in dedicated teams vs. staff augmentation — and a commit graph dominated by contractors on six-month contracts gets read with exactly that risk in mind.

Security posture, in evidence

Nobody on a diligence team reads your security policy PDF as proof of anything; policies are aspirations with headers. What gets checked is the trail. The last penetration test and, more important, the remediation tickets it produced. Access reviews that actually ran, with offboarding tickets showing that revocation happens within days, not quarters. Dependency update cadence visible in lockfile history. Secrets management that does not involve a shared document. A SOC 2 letter answers one question; the trail answers all the others.

Cost of goods

For a software business, infrastructure spend per unit of revenue is a valuation input, and the first check is whether anyone at the target can even compute it. If resources lack usable ownership tags, finance may see a large monthly bill without knowing which product line owns the cost. Our cloud cost work starts with this attribution question. For an acquirer, that is not a cost problem. It is a "the margin model cannot be verified" problem, and it gets priced accordingly. The inverse also holds: a unit cost that is attributable and trending down is one of the most underused positive signals a data room can contain.

Delivery metrics that can be verified

"We ship fast" is a claim; a deploy log is a fact. Deploy frequency and change failure rate come straight out of CI history. Lead time comes from merge-to-production timestamps. Incident honesty comes from postmortems — and a company with zero recorded incidents is not a company with zero incidents, it is a company that does not write things down. Verified mediocre numbers beat unverifiable great ones, every single time.

The red flags that kill deals

Very few findings kill a deal on their own. What kills deals is surprise — the discovery that surfaces in week two of diligence when it should have surfaced in the first management meeting. Issues worth investigating include:

• A diagram that contradicts the code. The finding itself is usually minor. The credibility damage is not, because it attaches a question mark to every other claim in the data room.
• An irreplaceable engineer with no retention plan. The buyer is acquiring a system that lives in one person's head, and that person has no reason to stay past closing.
• License contamination. A copyleft dependency compiled into the proprietary core — or no dependency inventory at all, which forces the buyer to assume the worst and price it.
• Shared production credentials. Beyond the direct risk, it means the access story cannot be audited, so every departed employee is a hypothetical insider.
• A test suite that does not run. Tests that exist but fail, skipped in CI with an apologetic comment from two years ago, are worse than absent tests — they show the team has learned to live with broken signals.
• The undisclosed incident. A breach or a customer-facing outage the team hoped nobody would ask about. Someone always asks. Former employees answer.

None of these is automatically fatal when disclosed early with a plan attached. All of them are dangerous when discovered late, because late discovery converts a technical issue into a trust issue — and trust is the thing the whole deal is resting on.

How to prepare, starting six months out

Preparation is not staging, and diligence teams can smell staging. Preparation is doing the real work early enough that the evidence has time to accumulate — because the trail, not the snapshot, is what gets read.

Six months out: run the diligence on yourself

Use the same checklist a buyer will. Fix cost attribution first, because tagging discipline takes months before the historical data looks like anything but a cleanup. Start writing architecture decision records if you have none: a six-month ADR trail reads as culture, a two-week one reads as decoration. Build the dependency and license inventory now, while there is still time to replace anything radioactive.

Three months out: fix the bus factor and the access story

Write runbooks for every system that has exactly one expert, and rotate deploy duty so the expertise spreads. Run a genuine access review and close the offboarding gaps it finds. Commission the penetration test now — the valuable artifact is not the report, it is the remediation trail behind it, and real remediation takes a quarter. A pen test dated three weeks before diligence, findings unaddressed, reads worse than no pen test at all.

One month out: write the known-issues list yourself

Assemble the data room, make the diagram match the system, and — the step almost everyone skips — write down your own skeletons, each with a containment plan and a cost estimate. You are choosing to present your weaknesses with context instead of letting a stranger present them without it.

What good looks like from the buyer's side

A useful preparation standard is straightforward: the diagram matches the system, the known-issues list arrives before anyone asks for it, the metrics come with the queries that produced them, and the CTO answers hard questions with evidence instead of fluency. That preparation gives the reviewer a clearer basis for assessing uncertainty; it does not guarantee an investment outcome or valuation.

If you are on either side of a deal right now — buying, raising, or six months from either — our IT consulting practice can scope a technical review with an agreed evidence checklist and a written findings register. And if you would rather find your own skeletons before anyone else does, the same method works just as well pointed at yourself.