Diligence rarely kills a deal outright. It moves price, it adds escrow, it adds conditions, and it adds weeks — and it does all of that most effectively when the finding is a surprise to you as well.
A technical diligence review is not looking for elegant code. The reviewer has a few days, a checklist and one question: what could go wrong here that we would own after the money moves?
That question has a consistent shape. Is there a security exposure we would inherit? Does this fall over, and would they know? Do the unit economics improve with scale or get worse? Can the team ship without one specific person? Do you actually own the code and have the right to use the data?
All of it can be checked in about two weeks by your own team. Doing so converts findings from leverage against you into a credible plan you hand over — and the difference in how the same issue reads is substantial. Below are the seven areas, in the order reviewers actually open them.
Area 1 — Security, where the deal-risk findings live
This is opened first because it is the only area that can genuinely stop a transaction. Most findings elsewhere move price; a live credential in a public repository or an unreported breach changes the conversation entirely.
Scan git history, not just the current tree — secrets that were committed and later removed are still in the history, and still valid if nobody rotated them. Then test tenant isolation deliberately: authenticate as tenant A and try to read tenant B's records by changing an identifier. That single test finds more real problems than any automated scanner, and a failure is exactly the class of issue diligence is looking for.
Then the unglamorous list: is multi-factor enforced on cloud and source control, do departed staff still have access, are dependencies with known critical vulnerabilities patched, and — the one almost everybody fails — has a backup actually been restored recently? An untested backup is not a backup, and “we have automated backups” is not an answer to “when did you last restore one?”
If a credential has ever been committed, treat it as compromised and rotate it — removing it from the current tree does nothing. “It was only in history for two days” is not a position anyone defends successfully.
# Secrets anywhere in history, not just in the current files
gitleaks detect --source . --log-opts="--all" --redact
trufflehog git file://. --only-verified
# Dependencies with known critical vulnerabilities
npm audit --audit-level=critical
pip-audit
# or your platform's equivalent, run in CI from now on
# Who can reach production, and is MFA actually enforced
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d \
| column -t -s,
# The one nobody does: restore a backup into a scratch environment
# and run a query against it. Time it. Write the number down.
# That number is your real RTO, and diligence will ask for it.Area 2 — Reliability, and whether you would know
The reviewer wants to know what single failure takes the product down, how long recovery takes, and whether recovery has ever been rehearsed. They are also reading how you talk about past incidents, because a team with written postmortems is a team that learns.
Map the single points of failure honestly. One database with no tested failover. One region. One queue everything depends on. One third-party API with no fallback and no timeout. Each is acceptable at your stage if it is known and priced — what reads badly is not knowing.
State your recovery objectives as numbers and then prove them. Recovery time objective and recovery point objective are meaningless as aspirations; they are meaningful as measurements from a rehearsal you did last quarter. Add a short incident history with what changed afterwards, and this area stops being a risk and starts being evidence of competence.
| Question | Weak answer | Strong answer |
|---|---|---|
| What happens if the primary database fails? | “We have automated backups.” | “Multi-AZ failover, rehearsed in July, 4 minutes measured, here is the runbook.” |
| What is your RTO and RPO? | “We aim for an hour.” | “RTO 35 minutes measured, RPO 5 minutes by continuous backup, last tested August.” |
| What was your worst incident this year? | “Nothing major.” | A dated postmortem, the root cause, and the change that prevents a repeat. |
| How do you know the product is down? | “Customers tell us.” | Synthetic checks on the critical path, alerting to an on-call rota, with response times. |
| What is your biggest single point of failure? | “I don't think we have one.” | A named component, why it is acceptable today, and what would trigger fixing it. |
Area 3 — Unit economics, the number they actually want
For an investor, the technical question underneath the architecture is commercial: does gross margin improve as you grow, or does infrastructure scale linearly with customers? The metric that answers it is infrastructure cost per active tenant, tracked over the last six to twelve months.
Falling cost per tenant as volume grows means leverage, and it is one of the most persuasive charts in the data room. Flat is acceptable and expected early. Rising is the finding you want to catch yourself, because it says something in the architecture does not scale — per-tenant infrastructure, a cost that tracks data volume rather than value, or an AI feature priced below what it costs to serve.
Bring the workings, not just the number. Cost by service, the share attributable to non-production, the effect of any commitments, and your largest single line with a sentence on whether it is fixed or variable. A founder who can explain their own bill in five minutes changes the tone of the whole session.
- Infrastructure cost per active tenant, monthly, for a year: One chart. The trend matters far more than the absolute value, and this is the chart they will screenshot.
- Know what scales linearly with customers: Per-tenant databases, per-tenant environments, per-seat licences, AI inference. Each is a margin question disguised as an architecture decision.
- Separate production from everything else: If a third of the bill is staging and demo environments, say so before they work it out — it reads as control rather than waste.
- Price the AI features specifically: Cost per action against what that plan tier earns. This is the newest question in diligence and the one most teams cannot answer.
Area 4 — Delivery and key-person risk
The reviewer is estimating how fast the team will move after the round, and how much of that speed lives in one person's head. Four measurements cover it, and they are all things you can pull from your own tooling this week.
Lead time for a typical change and deploy frequency describe the engine. Change failure rate describes whether it is safe at speed. Bus factor — how many people can deploy, restore a backup, or work in the payments module — describes what happens if someone leaves, which from an investor's seat is a live risk on a small team.
Test coverage comes up, and the number matters far less than where it is. Ninety percent coverage of view helpers with none on billing is worse than forty percent concentrated on the paths where money and permissions live. Say which paths are covered and why those, and the conversation moves on quickly.
| Measure | How to get it | What it signals |
|---|---|---|
| Lead time, commit to production | Median over the last 90 days, from your CI | Under a week is healthy at this size; over a month invites questions about process. |
| Deploy frequency | Count of production deploys per week | Frequent small deploys read as lower risk than infrequent large ones. |
| Change failure rate | Deploys needing a fix or rollback, as a percentage | Under 15% is fine. Over 30% suggests missing tests or missing staging. |
| Bus factor, per critical area | Name the people who can do each thing alone | Any area with a bus factor of one is a named risk — and cheap to fix with pairing and documentation. |
Area 5 — Data, privacy and the compliance questions
For a B2B product this area decides how quickly you can sell upmarket after the round, so investors care about it commercially as well as legally.
Start with a data map: what personal data you hold, where it physically lives, who can access it, how long you keep it, and how it is deleted when a customer asks. Writing this down is a day of work and it answers perhaps half of any security questionnaire you will face in the next two years.
Then the list of subprocessors — every third party that touches customer data, including the AI providers — with the agreement in place for each. Check that your own terms permit what you are actually doing, particularly if customer data flows to a model provider. And if you are selling to enterprises, be honest about certification status: “SOC 2 Type II, audit window starts in March” is a plan; “we are SOC 2 ready” means nothing and reviewers know it.
- A written data map: What personal data, where it lives, who can see it, how long you keep it, how you delete it. One page, and it pre-answers most questionnaires.
- A current subprocessor list: Every vendor touching customer data, AI providers included, with the data-processing agreement for each.
- Check your terms cover your AI usage: If customer data reaches a model provider, your contracts must permit it and you must know whether it can be used for training. This is now a standard question.
- Prove deletion works: Run a real deletion request end to end, including backups and analytics copies, and time it. Most teams discover a gap.
Area 6 — IP hygiene, the cheapest thing to fix in advance
This one is pure paperwork and it stops more deals than bad code does. The question is whether the company unambiguously owns what it is selling.
Every founder, employee and contractor who has written code needs a signed IP assignment. Contractors are the usual gap, particularly early agency work or an overseas developer hired before the company had a template contract. A missing assignment from someone who wrote a core component in year one is a genuine problem, and it takes weeks to resolve once counsel is involved — which is exactly the week you do not have during diligence.
Then open-source licences. Run a licence scan and look for copyleft licences in anything you ship or host, because those carry obligations that may be incompatible with a proprietary product. And have a stated position on AI-generated code: which tools the team uses and under what policy. Nobody expects a ban; they expect you to have thought about it.
# What licences are you actually shipping?
npx license-checker --summary
# or: pip-licenses, go-licenses, cargo-deny
# Flag the ones that carry obligations in a hosted product
npx license-checker --onlyAllow \
"MIT;ISC;Apache-2.0;BSD-2-Clause;BSD-3-Clause;CC0-1.0;Unlicense"
# Everyone who has ever contributed — reconcile against signed agreements
git log --all --format='%aN <%aE>' | sort -u
# Any name on that list without an IP assignment on file is an action
# item for counsel today, not a discovery during diligence in six weeks.Area 7 — AI exposure, the newest section of the checklist
If the product uses AI, expect a dedicated section. Reviewers are looking for four things, and most teams have thought hard about only the first.
Dependency: what happens if your model provider changes pricing, deprecates a model, or declines to serve you? A provider-agnostic boundary in the code and a tested fallback is a two-line answer to a question that otherwise runs long.
Then data rights — whether customer data reaches the provider and whether it can be used for training, which must match your own terms. Then quality evidence: an evaluation set, a pass rate, and a record of it running in CI, because “it works well” is not diligence-grade. And finally cost exposure: cost per action against the revenue of the tier that includes the feature, plus the per-tenant limits that stop one customer's automation consuming a month of budget.
| Finding | How diligence reads it | Typical remedy |
|---|---|---|
| Live credential in git history | Deal risk. Rotate and disclose immediately. | Hours to rotate, plus a disclosure conversation. |
| Tenant isolation flaw | Deal risk. The single worst thing to be found by someone else. | Days, plus notification obligations if it was exploited. |
| Backups never restored | Deal risk if the data is the product. | One rehearsal, one documented number. |
| Contractor IP unassigned | Deal risk. Slow to fix, involves lawyers. | Weeks. Start before diligence, not during. |
| Single points of failure | Price and conditions. Acceptable if known and planned. | Document, cost, and schedule it. |
| Cost per tenant rising | Price. It shapes their model of your margins. | One quarter of focused work usually reverses the trend. |
| Bus factor of one on a core system | Price and retention terms. Often drives earn-out structure. | Pairing, documentation, a second owner per area. |
| No AI evaluation evidence | Doubt about the headline feature. | An eval set and a CI report — about a week. |
The output: one page they can act on
Two weeks of checking produces a list. The artefact that matters is a single page: every finding, ranked by severity, each with an owner, an estimated effort and a status. Fixed items say fixed. Accepted risks say accepted, with the reasoning.
This is the document you hand over at the start of technical diligence, and it changes the entire dynamic. A reviewer who is given a credible, self-assessed risk register stops hunting and starts verifying — which is faster, calmer, and finds less, because the things they would have found are already on the page with a date next to them.
Then keep it. Re-run the checks each quarter, because all of these decay: dependencies age, contractors come and go, cost per tenant drifts, and the backup you restored in March has not been restored since. An hour a quarter keeps you permanently ready for a conversation you cannot always schedule in advance.
The difference between a finding you disclose and a finding they discover is roughly the difference between a note in the diligence report and a line in the purchase agreement.
Frequently asked questions
What does technical due diligence actually look at?
Risk rather than code quality. Security exposures the buyer would inherit, reliability and whether recovery has been rehearsed, unit economics and whether margin improves with scale, delivery speed and key-person risk, data and privacy posture, IP ownership, and — increasingly — AI dependency, data rights and cost exposure. Elegant code is barely mentioned; an unrotated credential is a deal event.
When should we run our own audit before a raise?
Eight to twelve weeks before you expect diligence. Some findings are hours of work, but the slow ones — unassigned contractor IP, a certification audit window, reversing a rising cost-per-tenant trend — take weeks or a quarter. Running it late means disclosing problems you have not had time to fix, which is the worst of both positions.
What single finding most often causes a problem?
Credentials in git history and tenant isolation flaws are the two that change a conversation, because both are security exposures the buyer inherits. Close behind is unassigned contractor IP, not because it is severe but because it is slow to resolve and involves lawyers on both sides at exactly the wrong moment.
Do we need SOC 2 before raising?
Usually not for the raise itself, and often yes for the enterprise sales that follow it. What matters in the room is honesty about status: a named auditor and an audit window reads as a plan, while “SOC 2 ready” reads as nothing at all. Investors care about it as a gate to your upmarket motion rather than as a box to tick.
How much technical debt is acceptable?
More than founders expect, provided you can name it. Reviewers are comfortable with debt that is known, bounded and prioritised — it is evidence of judgement. What reads badly is debt discovered by the reviewer, or a team that cannot say what would break first under three times the load.
Can we run the audit ourselves or do we need someone external?
The checklist here is entirely runnable in-house and that is the right default. An external pair of eyes helps in two situations: where the team is too close to judge its own architecture, and where an independent write-up carries more weight with an investor than a self-assessment. Either way, the findings matter more than who produced them.