Technical Due Diligence Checklist: What Investors Really Check

A technical due diligence checklist covers nine areas: architecture and scalability, code quality and technical debt, security, infrastructure and cloud cost, data and privacy, IP and open-source licenses, team and delivery process, AI usage, and roadmap feasibility. Investors are not grading your code for elegance. They are testing whether this product, this team and this infrastructure can carry the business plan they are about to fund, and they are looking for anything that changes the price, the terms or the first 100 days after closing.

This guide is written from the assessor's side of the table. You get the checklist area by area, the grading logic that turns findings into deal terms, what a good report contains, and a 90-day plan to prepare before anyone asks for repository access.

What Is Technical Due Diligence, and When Does It Happen?

Technical due diligence (tech DD) is an independent assessment of a company's software, infrastructure, security and engineering organization, commissioned before an investment or acquisition closes. It runs alongside financial, legal and commercial diligence and answers one question: what will it cost, in money and time, for this technology to deliver the plan?

Technical due diligence is not a code audit. A code audit judges the code; tech DD judges the business risk that the code, the infrastructure and the team create together. Depth scales with the size of the check and how much control changes hands.

| Deal type | Typical depth | What gets requested | Typical duration | | --- | --- | --- | --- | | Seed and pre-seed | Conversation | Architecture walkthrough, team, IP basics | A few days | | Series A | Light review | Diagrams, security basics, key metrics | 1 to 2 weeks | | Series B and growth | Evidence-based | Read-only code and cloud access, scans, interviews | 2 to 4 weeks | | M&A and buyouts | Full audit | All of the above plus license audit and security testing | 3 to 6 weeks |

These durations are typical, not rules. A prepared data room shortens them; missing documents and slow access stretch them.

The Technical Due Diligence Checklist, Area by Area

Treat every bullet below as an evidence request. Assessors trust git history, CI logs, cloud bills and postmortems far more than slides, and each area ends with the red flag that carries the most weight.

1. Architecture and Scalability

Assessors compare the load the system handles today with the load the plan requires in 24 months, then ask where it breaks first. The answer is usually the primary database, and the real test is whether the team already knows that.

A current architecture diagram that matches what is deployed, not what was planned
Peak production load, largest tenant, data growth rate and any load-test results
Tenant isolation model, single points of failure and critical third-party dependencies
Coupling: whether one service can ship without redeploying five others

Red flag: the plan assumes ten times the customers, but the design has a hard ceiling (hand-managed single-tenant deployments, one database instance near its largest size) that nobody has measured. Our breakdown of what breaks as a SaaS scales maps the usual ceilings stage by stage.

2. Code Quality and Technical Debt

Global coverage percentages say little. Assessors look for tests around money, identity and data integrity, and for hotspots: files that change constantly and are hard to read.

Tests on billing, authentication, permissions and data migrations
Linting, type checking and static analysis enforced in CI rather than left optional
Frameworks and runtimes past the end of vendor support, and whether an upgrade is planned
A debt register or architecture decision records (ADRs) that explain past trade-offs

Red flag: a core module the team is afraid to touch, where the only safety net is one engineer's memory.

3. Security Posture

Security findings carry the most deal weight because they can create liability, not just cost. Assessors want proof of controls, not a policy PDF.

SSO and MFA on code hosting, cloud, email and admin tools, plus a working offboarding process
No secrets in repositories, including history, and a real secrets manager in use
Dependency scanning with fix timelines, and the date and outcome of the last penetration test
An honest incident history with postmortems and any required notifications
Application controls measured against a public benchmark such as the OWASP Application Security Verification Standard

Red flag: an undisclosed breach, or credentials that leaked into git history and were never rotated. If you have never been tested, check what a penetration test costs and how a SOC 2 roadmap for startups produces the evidence both investors and enterprise buyers ask for.

4. Infrastructure, Reliability and Cloud Cost

Cloud cost flows straight into gross margin, and gross margin drives valuation. Startup credits hide the real run-rate, so assessors rebuild the bill as if the credits did not exist.

Infrastructure as code: whether production can be rebuilt from the repository
Backups with a dated restore test and a measured recovery time, not a declared one
Monitoring, alerting, on-call ownership, uptime history and incident records
Cloud accounts owned by the company, with root credentials locked down
Run-rate without credits, cost per customer or per transaction, and any committed-spend contracts

Example: a company shows a monthly cloud bill of $6,000 after $4,000 of credits and serves 200 customers who each pay $250 a month. The true infrastructure cost is $10,000 a month, or $50 per customer: 20% of revenue, not the 12% the net bill suggests. Assumptions: usage is flat month to month and the credits expire within the year. The fixes are usually mechanical, and our AWS cost optimization guide lists them.

Red flag: cost growing faster than revenue with no unit metrics, or production built by hand in a console that nobody can reproduce.

5. Data and Privacy

Assessors map where personal data lives and whether your contracts and privacy policy describe reality. Gaps here turn into regulatory exposure that transfers to the buyer.

A data map: what personal data you hold, where it lives by region, who can access it, how long you keep it
Data processing agreements with customers and sub-processors
Whether production data is copied into staging, laptops or third-party tools
Working export and deletion flows for data subject requests
Encryption in transit and at rest, with managed keys

Red flag: full production dumps sitting in developer environments and analytics tools, with no agreement covering them.

6. IP Ownership and Open-Source Licenses

This is where deals stall. An investor is buying rights to the code, so every contributor's work must be assigned to the company, and every dependency's license must permit the way you ship.

Signed IP assignments from every employee, contractor, agency and pre-incorporation founder who wrote code
Repositories, domains, cloud accounts and app store accounts registered to the company
A software bill of materials (SBOM), the machine-readable inventory of every component you ship, as described in CISA's SBOM guidance
Copyleft exposure: GPL code in software you distribute, modified AGPL code in a network service, and source-available licenses (such as BSL or SSPL) that restrict or attach conditions to offering the software as a service
Commercial licenses and API terms that may not survive a change of control

Red flag: the core product was written by an outside agency or freelancer whose contract never assigned the IP. This article is not legal advice; license and assignment questions need counsel who can read your actual contracts.

7. Team, Process and Delivery

Assessors measure the engineering organization from its tools, not its org chart. Git history shows who really built what, and delivery metrics show how the team performs under normal load.

Org chart, tenure, contractor share and a hiring plan
Key-person risk, measured from commit history per critical module
Branch protection, mandatory review, CI on every change and a practiced rollback
DORA's five software delivery metrics (change lead time, deployment frequency, change fail rate, failed deployment recovery time and deployment rework rate), as defined at dora.dev
Secure development practices that map to NIST's Secure Software Development Framework (SP 800-218)

Red flag: one engineer holds both the production knowledge and the only admin credentials, with no documented backup.

8. AI Usage and AI-Generated Code

AI now appears twice in diligence: in the product and in how the code was written. Older checklists miss both. In the product, assessors check:

Which model providers receive customer data, and under what retention and processing terms
Cost per AI request against what customers pay, and a fallback if a provider reprices or retires a model
Evaluation sets, prompt-injection defenses (see our explainer of the OWASP Top 10 for LLM applications) and exposure under the EU AI Act, whose obligations for stand-alone high-risk systems the 2026 AI Omnibus moved to 2 December 2027

In the development process, they check:

A written policy for AI coding assistants covering approved tools, review rules and what may never be pasted into a prompt
Provenance: which modules were largely generated, and whether generated code is scanned for license matches

Ownership deserves a careful look. The U.S. Copyright Office's 2025 report on copyrightability concluded that prompts alone do not give a human enough control over the output to be its author, while AI-assisted work remains protectable where a human determines sufficient expressive elements. Code that is heavily generated and lightly reviewed may therefore carry thinner IP than the pitch deck implies.

Red flag: customer data sent to a model provider under consumer terms, or an "AI moat" that turns out to be a prompt with no proprietary data, evaluations or workflow behind it.

9. Roadmap Feasibility

The final area joins everything above: can this team ship the plan the round is paying for? Assessors compare promises with measured history.

Delivered throughput over the last two to four quarters against the roadmap
Hiring plan and a realistic ramp time for new engineers
Platform work hidden behind feature bullets: SSO, audit logs, SOC 2, data residency
Assumptions about third-party APIs, partners or regulatory approvals

Red flag: a plan that needs three times the historical throughput from the same team, or enterprise revenue that depends on a SOC 2 report nobody has started.

How Do Assessors Grade Findings, and What Does Each Grade Cost You?

A finding is only useful to an investor once it has a severity, an owner and a price. Most assessors use some version of the four-level rubric below. The right-hand column is the one that matters, because it tells you which problems to fix before the process starts.

| Grade | Definition | Example | Typical deal consequence | | --- | --- | --- | --- | | Critical | Threatens ownership, legality or continuity | Core code with no IP assignment | Deal paused, special indemnity or escrow, sometimes a walk-away | | High | Material cost or risk the plan did not price in | Backups never restored | Price adjustment, holdback or pre-closing covenant | | Medium | Bounded and fixable by the current team | End-of-life framework | Item in the 100-day plan | | Low | Hygiene gap | Inconsistent linting | Noted in the report, no deal impact |

Ordinary technical debt rarely lands in the Critical row. The findings that stall or reprice deals are ownership gaps, undisclosed incidents and license contamination, because writing more code does not fix them. Disclosed debt with a remediation plan reads as maturity; the same debt discovered by the assessor reads as a trust problem.

Illustrative scenario: a Series B SaaS review produces four findings. A modified AGPL library runs inside the backend (High), backups have not been restored in 18 months (High), one engineer authored nearly all billing commits in the past year (High), and 40 dependencies carry known critical vulnerabilities (Medium). The assessor estimates 3 engineer-weeks to replace the library, 1 for a restore drill and runbook, 4 for pairing and documentation on billing, and 6 for dependency upgrades: 14 engineer-weeks in total.

At an assumed fully loaded cost of $4,000 per engineer-week, that is $56,000. The investor might fund it from the round, hold part of it back, or require the license fix before closing. Assumptions: the estimates are the assessor's, not vendor quotes, and real costs vary by team, stack and location.

What Should a Technical Due Diligence Report Contain?

A good report lets a non-technical partner decide in ten minutes and lets an engineer verify every claim. If it does neither, it is an opinion, not diligence.

Executive summary: an overall rating, the top five risks and a plain answer on whether the technology can carry the plan.
Scope and limits: what was reviewed, at what access level, and what was not reviewed.
Scorecard: a grade for each of the nine areas above.
Findings register: every finding with severity, evidence (file paths, scan output, metrics), business impact and a remediation proposal.
Effort estimates: engineer-weeks per finding, totaled by severity, with pre-closing items marked.
Team assessment: key-person risk, capability gaps and hiring realism.
100-day plan: the post-close sequence, owners and checkpoints.
Appendices: SBOM, license report, raw scan output, architecture diagrams and the interview list.

Watch for the weak version: generic best-practice lists, no evidence, no effort estimates and no statement of what the assessor could not see. A report that never says "we did not review X" is overstating its coverage.

How to Prepare: A 90-Day Plan for Founders

Start about 90 days before you expect a term sheet, earlier for an acquisition. Order matters: prove ownership first, fix cheap critical issues second, and produce evidence last, because documented evidence of an unfixed problem is still a finding.

| Window | Focus | Deliverables | | --- | --- | --- | | Days 1 to 30 | Inventory and ownership | Asset register, IP assignments, SBOM and license report, secret scan, architecture diagram | | Days 31 to 60 | Fix cheap criticals | SSO and MFA everywhere, restore test, critical CVEs patched, copyleft issues resolved, cost per customer | | Days 61 to 90 | Evidence and rehearsal | Data room, DORA baseline, pen test report, debt register, mock review |

The Step-by-Step Version

Build an asset register: repositories, cloud accounts, domains, DNS, app store accounts and SaaS tools, with the legal owner of each.
Collect signed IP assignments from every current and past contributor, including agencies and freelancers.
Generate an SBOM and a license report, and send copyleft and source-available findings to counsel.
Scan the full git history for secrets and rotate every hit; deleting the commit is not enough.
Draw the current architecture and write down the three places it will break first.
Enforce SSO and MFA everywhere and remove stale accounts.
Run a timed restore from backup and record the result.
Patch or formally document every critical dependency vulnerability.
Tag cloud resources and compute cost per customer without credits.
Pull twelve months of DORA metrics from your tooling.
Commission a penetration test if the last one is more than a year old, and fix the high-severity findings.
Write a debt register with estimates, assemble the data room, and run a mock review with someone outside the team.

Run the Self-Audit Before the Assessor Does

These commands reproduce the first days of an evidence-based review. Assessors run the same class of tools, and you want to see the output before they do.

# 1. SBOM of everything you ship (CycloneDX JSON)
syft . -o cyclonedx-json=sbom.cdx.json

# 2. License risk: forbidden and restricted licenses first
trivy fs --scanners license --severity CRITICAL,HIGH .

# 3. Known vulnerabilities in dependencies
trivy fs --scanners vuln --severity CRITICAL,HIGH .

# 4. Secrets anywhere in git history (rotate every hit)
gitleaks git --report-path gitleaks.json --report-format json .

# 5. Key-person risk: who wrote the last 12 months of a critical module
git shortlog -sn --no-merges --since="12 months ago" HEAD -- src/billing

# 6. Hotspots: the files that changed most often in the last year
git log --since="12 months ago" --no-merges --name-only --pretty=format: \
  | grep -v '^$' | sort | uniq -c | sort -rn | head -20

None of this replaces judgment. A hotspot list is only a finding when the same files also lack tests or have a single author, and a license flag is only a finding once counsel reads it against how you ship.

How Agentixly Approaches Technical Due Diligence

Agentixly runs technical due diligence on both sides of a deal: for investors and acquirers who need an independent view, and for founders who want a readiness review before the process starts. The method is the same because the evidence is the same.

Scope and access (first days): NDA, read-only access to repositories, cloud accounts, CI and incident history, and a written list of what is out of scope.
Automated evidence (first week): SBOM, license, vulnerability, secret and infrastructure-as-code scans, plus repository analytics for ownership, churn and key-person risk.
Interviews and walkthroughs: the CTO, two or three engineers and whoever carries the pager, plus a live deploy and rollback.
Deep dives where risk concentrates: security testing by our cybersecurity team, scalability against the plan, cloud unit economics and AI data flows.
Report and readout: graded findings with evidence, engineer-week estimates and a 100-day plan, walked through with the decision makers.

Two things shape how we read a codebase. Agentixly's team is made up of veterans of Israel's elite technology units (Unit 8200, Unit 81), so we start with how a system fails or gets attacked, not how it looks in a demo. And because we build multi-tenant SaaS platforms ourselves, remediation estimates come from engineers who do remediation work. When a review shows that a codebase needs more than a 100-day plan, our guide to rescuing a failing software project covers what comes next.

The Bottom Line

Technical due diligence rewards companies that already know their weaknesses. Run the checklist on yourself, fix whatever threatens ownership and security, put a price on the rest, and hand the assessor a data room that answers questions before they are asked.

If a raise or an acquisition is on your calendar, Agentixly can run an independent review or a sell-side readiness assessment, drawing on software, cloud and security engineering in one team, from architecture reviews to security audits. Talk to our team about scope and timing; we answer every inquiry within 24 hours.