Skip to main content
Checklist · Updated July 2026

The technical due diligence checklist investors actually use

Technical due diligence examines seven areas: architecture & scalability, code quality & delivery, team & key-person risk, security & compliance, IP & open-source licensing, data & AI exposure, and roadmap credibility. This is the working checklist, every item, what "good" looks like, and the red flags that reprice deals. Written from both sides of the table, across 20+ companies.

Need it run for a live deal? Book a scoping call NDA-first · SOC 2 Type I · Fits deal timelines · Buy-side and sell-side

Architecture & scalability

The question is never "is the architecture modern?" It's "does the architecture survive the business plan?"

  • ☐ System diagram exists, matches reality, and an engineer other than its author can walk through it.

  • ☐ Load headroom is known: what breaks first at 10× current volume, and has anything like that scale been tested or reasoned about.

  • ☐ Single points of failure are identified, databases, queues, third-party APIs, with a stated tolerance for each.

  • ☐ Infrastructure cost per customer/transaction is known and doesn't quietly destroy gross margin at plan targets.

  • ☐ Build-vs-buy decisions look sane: no hand-rolled auth, payments, or crypto where proven services exist; no vendor lock-in that blocks the roadmap.

  • Red flags: "only Dave understands that service" · a rewrite already underway without a migration plan · architecture chosen to pad résumés, not serve load.

Code quality & delivery pipeline

Code quality is not aesthetics, it's the cost of the next feature.

  • ☐ A new engineer can run the system locally and ship a small change in under a week, the single best proxy for codebase health.

  • ☐ Tests exist where they matter: revenue paths, data integrity, integrations. Coverage percentage is less telling than what's covered.

  • ☐ CI/CD is real: automated builds, repeatable deploys, a rollback story that has been exercised, not a wiki page of manual steps.

  • ☐ Delivery metrics trend visibly: deployment frequency, lead time, change-failure rate. Teams that don't measure these usually can't answer "when will it be done."

  • ☐ Technical debt is inventoried and priced, not denied. Every codebase has it; mature teams know where theirs is.

  • Red flags: deploys require a specific person · long-lived feature branches merged quarterly · "we'll add tests after the raise."

Team & key-person risk

  • ☐ Bus factor: for each critical system, at least two people can operate and extend it. A bus factor of one anywhere critical is a valuation problem, not a staffing note.

  • ☐ Ownership is legible: who decides architecture, who owns production, who is accountable for delivery, answered identically by the CEO and the engineers.

  • ☐ Retention risk is assessed: vesting cliffs near the transaction, key people whose equity outcome makes them flight risks at close.

  • ☐ Contractor and agency work is contractually clean: IP assigned, access revocable, knowledge transferred, not living in a departed freelancer's head.

  • Red flags: the founder is still the only person who can deploy · interviews where engineers contradict the CEO's technical story · a team that describes the roadmap as "whatever comes in this week."

Security & compliance

  • ☐ Access control basics: SSO/MFA on critical systems, least-privilege on production, offboarding that provably revokes access.

  • ☐ Secrets management: no credentials in the repository or its history; rotation is possible without a war room.

  • ☐ Incident history is documented, including the embarrassing ones. Zero recorded incidents means nobody's looking.

  • ☐ Backups exist AND restores have been tested. An untested backup is a hope, not a control.

  • ☐ Compliance posture matches the market: SOC 2 / ISO 27001 where enterprise buyers demand it; GDPR / PIPEDA / CCPA data handling where users are; sector rules (HIPAA, PCI-DSS) where applicable.

  • Red flags: shared admin accounts · production data in developer laptops · a pen test that was never remediated · "we're too small to be a target."

Why this section reprices deals: the average data breach costs USD 4.44 million (IBM Cost of a Data Breach Report, 2025), and in an acquisition that bill lands on the buyer after close, not the seller. An unremediated vulnerability or compliance gap found post-signing is a cost you inherit, which is exactly why a clean security and compliance posture is worth real basis points on the valuation.

IP & open-source licensing

  • ☐ Every contributor, employee, contractor, agency, co-founder's friend from 2019, has signed IP assignment. Gaps here stall closings.

  • ☐ A dependency inventory exists with licenses classified. Copyleft licenses (GPL, AGPL) linked into proprietary code are a legitimate deal-stopper; permissive licenses (MIT, Apache-2.0, BSD) need attribution hygiene.

  • ☐ Nothing proprietary was published publicly by accident, and nothing public is passing as proprietary.

  • ☐ Trademarks, domains, and app-store accounts are owned by the company, not a founder's personal account.

  • Red flags: "we forked it years ago, license unclear" · a core algorithm copied from a previous employer · AGPL in the backend of a SaaS.

Data & AI exposure, the 2026 additions

Two years of AI-assisted building created a new diligence category. Most checklists haven't caught up.

  • ☐ AI-generated code provenance: how much of the codebase was AI-written, and was it reviewed by someone who understands it? Unreviewed generated code is unaudited code.

  • ☐ Model and provider dependencies: which product features die if a model provider changes pricing, deprecates an API, or bans the use case? Is there a fallback?

  • ☐ Customer data and third-party AI: what leaves the boundary, under which data processing agreements, and does the privacy policy actually permit it?

  • ☐ Prompt-injection and abuse surface for user-facing AI features: has anyone tried to break it before a customer does?

  • ☐ Unit economics of AI features: inference cost per user at plan scale, margins have quietly inverted on this line item.

  • Red flags: "the AI part was built by a contractor with ChatGPT and he's gone" · customer PII in fine-tuning sets · demo features that cost more per use than the product's price.

Data problems are easy to under-price in a deal because they do not show up in a demo. Gartner's widely cited 2020 estimate put the cost of poor data quality at roughly USD 12.9 million a year per organization, and in an acquisition a scattered, inconsistent, or poorly governed data estate moves straight onto your balance sheet, dragging on every decision and integration that follows.

Roadmap credibility

  • ☐ The financial model's product promises are costed in engineering time by someone who has shipped comparable systems, and the two documents agree.

  • ☐ Recent delivery history supports the projected velocity. Teams do not triple their shipping rate because a deck says so.

  • ☐ The hiring plan is realistic for the market and the team can absorb it, doubling headcount halves velocity for a quarter before it helps.

  • Red flags: a roadmap with no dependencies on the debt inventory · "the rewrite will make everything after it fast" · enterprise features promised with no compliance line item.

For founders: how to prepare (sell-side)

The highest-leverage move is running this checklist on yourself before your investors do.

  • Build the data room early: architecture overview, dependency/license inventory, security policies and incident log, delivery metrics, org chart with ownership, and an honest technical-debt register with remediation costs.

  • Disclose weaknesses with plans attached. "Known, priced, scheduled" reads as operational maturity. Discovered concealment reprices the whole company, not just the finding.

  • Fix the two-week items: secrets out of the repo, MFA everywhere, an IP-assignment sweep, a tested restore. Cheap fixes that remove entire finding categories.

  • Consider a readiness review: an independent audit before the raise , here's what that looked like for one client, turns diligence from an exam into a confirmation.

FAQ

Technical due diligence, answered

What is technical due diligence?

Technical due diligence (TDD) is an independent examination of a company's technology before an investment or acquisition. It verifies that the product actually works the way the pitch says, that it can scale with the business plan, and that there are no hidden liabilities, security holes, licensing violations, key-person dependencies, or unpayable technical debt.

How long does technical due diligence take?

One to three weeks for most venture deals; two to six weeks for complex M&A. The work compresses well when the target prepares a data room in advance: architecture diagrams, dependency inventories, security policies, and metrics dashboards cut the timeline roughly in half.

Who performs technical due diligence?

Either the investor's in-house technical team or an independent firm of experienced CTOs and architects. Independence matters on both sides: founders' own engineers are invested in the story, and generalist analysts miss what operators catch, the difference between 'uses microservices' and 'split the monolith for the wrong reason and doubled their ops burden.'

What are the biggest red flags in technical due diligence?

The recurring deal-repricers: a single engineer who holds everything (bus factor of one), no reproducible deployment process, GPL or AGPL code linked into proprietary software, customer data used in ways the privacy policy doesn't cover, secrets committed to the repository, no tests around revenue-critical paths, and a roadmap whose costs contradict the financial model.

What does technical due diligence cost?

Independent TDD typically runs $15,000–$60,000 depending on deal size and system complexity, priced against rounds and acquisitions where a single missed liability can move the price by millions. Sell-side readiness reviews (getting audited before your investors do it to you) cost less and routinely pay for themselves in the negotiation.

How should founders prepare for technical due diligence?

Run the checklist on yourself first. Prepare an architecture overview, a dependency and license inventory, security and incident documentation, delivery metrics, and honest notes on known debt. Diligence rewards candor: a documented weakness with a remediation plan reads as competence; a discovered one reads as concealment.

When should technical due diligence happen?

For buyers, start during exclusivity, ideally right after the letter of intent (LOI) is signed but before terms are locked, so you still have leverage to reprice or walk if problems surface. For founders and sellers, run your own review 6 to 12 months before going to market, so you can fix issues on your own terms instead of under a buyer's deadline. Pre-LOI the goal is discovering and sizing risk; post-LOI it shifts to confirming claims and quantifying surprises.

What is the difference between buy-side and sell-side technical due diligence?

Sell-side TDD is run by the company preparing for sale, to find and fix technical issues before buyers see the codebase and to arrive market-ready. Buy-side TDD is commissioned by the acquirer or investor, to validate the seller's claims, stress-test assumptions, and decide whether the deal is worth its price. Same checklist, different lens: tidying the house before guests arrive versus checking for leaky pipes before you move in.

What system access does a technical due diligence review need?

Almost all of it read-only and under NDA: read access to the source repository (GitHub, GitLab, Bitbucket), the CI/CD pipeline config, read-only cloud and infrastructure accounts, real product accounts (not a staged demo), monitoring and logging dashboards, and the internal knowledge base. Temporary, scoped roles are standard. The aim is no black boxes: validating what the pitch deck claims against how the system actually behaves.

What is included in a technical due diligence report?

A scored assessment across the core areas (architecture and scalability, code quality and delivery, team and key-person risk, security and compliance, IP and licensing, data, and roadmap credibility), presented as a risk matrix with an executive summary and technical appendices. The part that matters most in a negotiation is the remediation roadmap: each finding costed and timelined, so issues become numbers you can bring to the table rather than a vague list of concerns.

How is technical due diligence different from financial due diligence?

Financial due diligence reviews the numbers; technical due diligence reviews the product, the codebase, infrastructure, security, and the team that maintains it, and verifies the technology can actually deliver on the business plan. The two streams run in parallel during the diligence window and both feed the final valuation decision.

What happens if technical due diligence is skipped or done poorly?

The risk does not disappear, it just lands after close, on the buyer. Weak or skipped diligence is a leading reason deals miss their targets: hidden technical debt and architecture that cannot scale stall the growth the deal was built on, undiscovered security or compliance gaps turn into breach costs, fines, and customer churn that hit the acquirer rather than the seller, and a bus-factor-of-one or an unreproducible deployment surfaces exactly when you can least afford it. Done properly and early, diligence either reprices those risks into the deal or lets you walk before they become yours.

Running a deal? We do this for a living, on either side of the table.

Book an NDA-first scoping call