How to write a technical due diligence report

A technical due diligence report is a structured assessment that tells an acquirer or investor whether the engineering side of a company is worth the price on the term sheet. It covers nine areas: architecture, scalability, tech debt, security, team and bus factor, IP cleanliness, open-source license compliance, infrastructure cost trajectory, and concentration risks like founder dependency or single-vendor lock-in. The output is a 1 to 3 page executive summary backed by a 15 to 40 page appendix of evidence.

Most founders see their first tech DD report when a buyer's CTO sends one back full of red flags. By then the deal is wobbling. This post walks through how to write the report yourself, six to twelve months before you need it, so the buyer's version confirms what you already wrote.

Why founders write the report themselves

Buyers commission tech DD from firms like Crosslake, West Monroe, or a deal-specific contractor for $15k to $80k. Investors above $5M check size usually do it in-house with a technical partner. Either way, the report you do not write is being written about you.

When you write the same report first, three things change. You fix the obvious problems before anyone sees them. You control the framing of trade-offs you knowingly made. When the acquirer's report lands, you can compare line by line instead of negotiating in the dark.

A self-written tech DD also doubles as your engineering operating manual. The bus factor section forces you to write the runbook you should have written two years ago. The IP section forces you to clean up contractor contracts you signed on Upwork in 2023. None of this work is wasted.

The nine sections every report covers

A defensible tech DD report has the same skeleton regardless of deal size. What changes is depth, not structure.

1. Architecture overview

One diagram, one page of prose. The diagram shows every runtime component (web, API, workers, databases, queues, third-party services) and the data flow between them. The prose explains the three or four non-obvious choices: why Postgres and not DynamoDB, why a monolith and not microservices, why Render and not AWS.

Buyers want to see that the architecture matches the company's stage. A 10-person startup with 14 microservices is a red flag. A 200-person company on a single Rails monolith is also a red flag. Match the architecture to the headcount and the load.

Include a tech stack inventory: languages, frameworks, primary database, queue, cache, CDN, observability stack, CI/CD provider, hosting provider. Be specific. "Node.js" is not a stack; "Node 20 on Render, Next.js 15 app router, Postgres 16 with Prisma, BullMQ on Redis, Vercel for marketing site" is a stack.

2. Scalability assessment

How many requests per second does the system handle today? What breaks first at 10x load? At 100x? An honest answer here scores higher than a defensive one. Every system has a breaking point. Naming yours shows the buyer you have thought about it.

The good version of this section names the bottleneck (usually the primary database or a single hot table), the migration path (read replicas, partitioning, a queue in front of the write path), and the rough cost of executing it. The bad version says "the system scales horizontally" without numbers.

3. Tech debt audit

List the debt. Quantify it. A buyer who sees a list of 18 known issues with effort estimates trusts you more than one who sees a clean slate. Clean slates are lies.

Format it as a table:

Issue	Severity	Effort	Why it exists
Auth code copy-pasted into 4 services	High	2 weeks	Shipped pre-Series A, never consolidated
Migration framework 2 majors behind	Medium	1 week	Avoided breaking changes during last raise
17% test coverage on billing module	High	3 weeks	Original engineer left before tests landed
Custom CSV export logic instead of a library	Low	2 days	Pre-dates pandas integration

Total the effort. If the number is more than 30% of one year of engineering capacity, that is a finding the buyer will want priced into the deal. If it is under 10%, you are in good shape.

4. Security posture

Cover seven things: authentication, authorization, secrets management, dependency vulnerabilities, data encryption (at rest and in transit), backup and disaster recovery, and incident history. Be specific about controls. "We use OAuth" is not a control; "All user auth runs through Clerk, with SOC 2 Type II inherited; service-to-service uses signed JWTs with 5-minute expiry" is a control.

Include the last penetration test result if you have one. If you have not had one, say so and budget for one before the close.

The fastest red flag in a buyer's report is a Snyk or Dependabot scan showing 200 high-severity CVEs in production dependencies. Run that scan yourself, fix what is fixable in a week, document the rest with mitigations. A clean Snyk report attached to your DD wins more goodwill than any architecture diagram.

5. Team capability and bus factor

For each engineer: name, role, tenure, three primary areas of code ownership, and whether that ownership is shared or singular. Singular ownership of a critical system is a bus factor of 1 and the most common finding in tech DD reports.

Acquirers care less about headcount and more about concentration. A 5-engineer team where every system has 2 owners scores better than a 12-engineer team where 4 systems are owned by 1 person each.

If you are the founder and you wrote 60% of the codebase, that is your single largest deal risk. Write the section honestly. Then start a six-month plan to transfer ownership. We have a separate playbook on how to prepare technical due diligence as a founder that covers this in depth: prepare technical due diligence as a founder.

6. IP cleanliness

Every line of code in production needs a clear paper trail back to a contract. For employees, that is the employment agreement with an IP assignment clause. For contractors, it is the contractor agreement with the same. For open-source dependencies, it is the license file.

The places this goes wrong: contractors hired on Upwork or Fiverr without a custom agreement (the platform default usually grants you usage rights but not full assignment), founders who wrote code before incorporating (file an assignment from yourself to the company, dated and signed), and acqui-hire candidates whose previous employers might claim moonlighting IP (review their last employer's contract).

List every contributor to the codebase, the agreement type, and the date of assignment. If anything is missing, fix it before you start DD, not during.

7. OSS license compliance

Run a Software Composition Analysis tool (Snyk, FOSSA, GitHub's built-in dependency graph) and produce a license inventory. Flag every copyleft license (GPL, AGPL, LGPL) in your direct or transitive dependencies. An AGPL package in your backend that you have modified can force you to open-source your entire product. Most buyers will not close a deal with unresolved AGPL exposure.

Permissive licenses (MIT, Apache 2.0, BSD, ISC) are fine. Document them, attribute them in a NOTICE file if you ship a binary or distributable, and move on.

8. Infrastructure cost trajectory

Show 12 months of monthly infra spend, broken down by provider. Then project the next 12 months at 2x and 5x current usage. Buyers care about the slope, not just the level.

A SaaS company spending $4,800/month today and trending to $7,200 next year is fine. The same company on a usage curve that hits $40,000 next year, with a single contract renewal that triples a vendor cost, is a finding. Name the renegotiation levers (commitment discounts, reserved instances, vendor swaps) and the breakeven point of each.

9. Concentration risks

This is the section most self-written DD reports skip. The buyer's report will not skip it. Three risks deserve their own subsection.

Founder dependency. If the technical founder disappears tomorrow, what stops working? What slows down? What knowledge is in their head and nowhere else? Quantify it as a percentage of the codebase, list the systems, and name the planned mitigation.

Single-vendor lock-in. Anything that would be a six-month migration if the vendor changed pricing or got acquired. Common offenders: payment processors, auth providers, primary databases, AI model providers, observability stacks. Name each, name the cost of the swap, name the contractual protections you have (price-lock terms, exit clauses).

AI model dependency. New as a category, but every buyer in 2026 is asking. If your product calls OpenAI, Anthropic, or Google models, what happens when they raise prices 40%, change rate limits, or sunset a model? Have you abstracted the call site so you can swap providers? Do you have evaluations to compare quality across models? If not, the answer to "what happens" is "we get a finding."

A 1-page summary template

The full report runs 15 to 40 pages. Most readers will only read page 1. Spend disproportionate time on it.

COMPANY: [Name]
REPORT DATE: [YYYY-MM-DD]
PREPARED BY: [Internal author or external firm]

HEADLINE: One sentence on overall engineering health.
"The engineering org is sized appropriately for $4.2M ARR, with two structural risks (founder dependency on the billing system, AGPL exposure in one dependency) that should be priced into the deal."

KEY STRENGTHS (3 bullets)
- Architecture: simple, matches stage, no premature complexity
- Security: SOC 2 Type II in progress, clean Snyk report
- Bus factor: 8 of 11 systems have 2+ owners

KEY RISKS (3 bullets, ranked)
- HIGH: Founder owns 60% of billing module code
- MEDIUM: AGPL dependency in PDF generation, needs swap
- LOW: 17% test coverage on legacy export module

FINDINGS BY SECTION
| Section | Score (1-10) | Top finding |
| Architecture | 8 | Clean, well-matched to stage |
| Scalability | 7 | DB bottleneck at ~15x current load |
| Tech debt | 6 | 11 weeks of debt logged and prioritized |
| Security | 8 | SOC 2 Type II in audit window |
| Team / bus factor | 5 | Founder concentration on billing |
| IP cleanliness | 9 | All assignments signed and dated |
| OSS licenses | 6 | 1 AGPL dependency requires action |
| Infra cost | 8 | Trajectory matches revenue curve |
| Concentration risks | 5 | Single-vendor lock-in on auth and model |

RECOMMENDED DEAL CONDITIONS
1. 6-month founder transition with documented handover
2. AGPL dependency swap completed pre-close
3. Escrow 5% of consideration against billing module rewrite

OVERALL: GREEN with conditions / YELLOW / RED

Keep it to one page. If you cannot fit a finding on page 1, it is not a top finding.

Report depth by deal size

Not every deal needs a 40-page report. Match the depth to the check size and the buyer profile. Most founders over-prepare for seed-stage acquihires and under-prepare for strategic acquisitions.

Deal size	Report length	Typical effort	What buyers actually read
Acqui-hire ($1M to $5M)	5 to 8 pages	1 to 2 weeks	Team capability, IP cleanliness
Small strategic ($5M to $20M)	12 to 20 pages	3 to 5 weeks	All 9 sections, light depth
Mid-market ($20M to $100M)	25 to 40 pages	6 to 10 weeks	Full report, deep on architecture and security
PE buyout ($100M+)	40 to 80 pages	10 to 16 weeks	Full report plus financial model integration

A common founder mistake at the smaller end is writing a 40-page report no one reads, then missing the IP assignment that kills the deal. A common founder mistake at the larger end is writing 12 pages of marketing copy and waiting for the buyer's $80k Crosslake report to find the holes.

How to actually produce the report

You need an author who can talk to engineers, read code, and write English. That is a rare combination in any one person. Three paths work.

The CTO writes it. Cheapest, but the founder is the worst person to assess founder dependency. Honest self-assessment is hard. Use this path only if you have a non-founding CTO with at least 12 months of tenure.

External firm. Crosslake, West Monroe, or a specialist like Software Improvement Group. Cost: $15k to $80k. Timeline: 4 to 8 weeks. The output is credible to buyers because the firm has no incentive to flatter you. The downside: you are paying market rate for work you could have done internally in half the time.

Booked engineer on Cadence. Bring in a senior or lead for 4 to 6 weeks to author the report alongside your team. Every engineer on Cadence is AI-native by default, vetted on Cursor and Claude Code fluency before they unlock bookings, which matters here because the bulk of the work is reading code and producing structured prose. A senior at $1,500/week for 5 weeks is $7,500. A lead at $2,000/week for 4 weeks is $8,000. Either is roughly a tenth of the external-firm cost with similar output quality for sub-$20M deals.

The 48-hour free trial earns its keep here: hand the engineer the architecture diagram and 2 days later see if they ask the questions a buyer's CTO would ask. If not, replace with no notice. Our Series A engineering hiring playbook covers the broader version of this engagement.

For founders running a parallel fundraise or acquisition process, our guidance on common founder mistakes when hiring developers flags the patterns that produce the worst DD findings later.

What to do this week

If you are 6 to 12 months from a likely transaction, start now. Block half a day this week to draft the 1-page summary template above from memory, before reading any of your own code. The gaps between what you wrote and what is actually true are your first round of findings.

Then run Snyk on production. Run a contractor agreement audit. Map every system to its primary owner. None of these tasks need a full report to start. If you want a structured way to schedule the work, book a senior engineer on Cadence for a week to produce the gap analysis, then decide whether to extend.

If you are inside 90 days of a likely term sheet and the report does not exist yet, the highest-ROI move is to start writing the 1-page summary today. Cadence engineers can ship a defensible draft of all nine sections inside 6 weeks at $9,000 total, which is faster and roughly 80% cheaper than the external-firm path. Start with a 48-hour trial.

FAQ

How long does writing a technical due diligence report take?

Between 1 week (acqui-hire scope) and 16 weeks (large PE deal). For a typical $20M to $50M strategic acquisition, plan on 6 to 10 weeks of focused work from one senior engineer plus part-time input from the CTO and founders.

What is the difference between technical due diligence and a code audit?

A code audit is a subset. It assesses the codebase: quality, debt, security. A technical due diligence report covers the codebase plus team, IP, licenses, infrastructure costs, vendor risks, and concentration risks. Code audits feed into DD reports but are not substitutes.

Should we hire an external firm or write the report ourselves?

External firms make sense above $50M deal size or when the buyer specifically requests an independent third-party report. Below that threshold, an internal author or a booked senior engineer produces a credible report at 10 to 20% of the cost. Many sub-$20M deals close on internally authored reports without issue.

What is the most common finding in technical due diligence reports?

Bus factor concentration, usually on the founding CTO or the original lead engineer. Second most common: incomplete IP assignment from early contractors. Third: at least one copyleft (GPL/AGPL) dependency that the team did not know about.

How much does technical due diligence cost?

External firms charge $15k to $80k for sub-$50M deals and $80k to $250k for larger transactions. An internally authored report costs the time of one senior for 4 to 10 weeks. A Cadence senior at $1,500/week for 6 weeks is $9,000.

When should we start writing the report?

6 to 12 months before a likely transaction. The first draft surfaces problems that take 3 to 6 months to fix (IP assignments, dependency swaps, ownership transfer). Starting 30 days before the term sheet is too late to fix anything.