Technical Due Diligence in 2026: What I Actually Look At (Checklist Included)

TL;DR: What Technical Due Diligence Is

Most technical due diligence reports are 40 pages of things that don't change the deal. Linting complaints. Framework opinions. "Consider migrating to microservices" (please don't). The version that matters answers three questions: what breaks under growth, what breaks under attack, and what breaks when one specific person quits.

Technical due diligence is the structured review you run on a company's technology before committing money to it — as an acquirer, an investor, or a founder about to bet a raise on your own product's credibility. It covers code, architecture, infrastructure, security, data, team, and IP. As of 2026, it also has to cover a question that didn't exist on any 2023 checklist: how much of this was written by AI, and can the humans explain it?

The Checklist: Eight Areas That Actually Move Deal Prices

• 1. Code quality & tests. Not style — substance. Is there test coverage on the money paths (auth, billing, data writes)? Can the team deploy on a Tuesday without a prayer circle?
• 2. Architecture & scale honesty. What actually happens at 10x current load? "It's on AWS" is not an answer. Simple architectures that scale boringly beat clever ones that scale theoretically — I've written about how I evaluate a product's build quality and boring wins every time.
• 3. Security posture. Secrets in the repo, auth that trusts the client, missing rate limits, dependency vulnerabilities. My 20-point security checklist is the self-audit version; diligence is the adversarial version.
• 4. Infrastructure & run cost. What does it cost to keep the lights on, and does that number survive growth? A product with 80% margins on paper and a runaway cloud bill in reality is a repricing event.
• 5. Data practices. What PII is held, where, encrypted how, deletable how. Compliance exposure is a liability you're buying, not a footnote.
• 6. Team knowledge concentration. For each critical system: who understands it? If the answer is one name — or worse, no name — the acquisition includes a hostage situation.
• 7. IP hygiene. Licenses of every dependency, contractor agreements, anything copied in. Boring until it isn't.
• 8. AI-code provenance (the 2026 addition). How much of the codebase was generated, with which tools, reviewed by whom? Full section below, because this is where deals move now.

The AI-Code Question Nobody Was Asking in 2023

A large share of the codebases I look at now were built partly or mostly with Lovable, Cursor, Replit Agent, or Claude Code. That's not a defect — it's how I'd start a new product too. But diligence's oldest shortcut just died: you can no longer infer code quality from team quality, because a two-person team can now ship a codebase with the surface area of a fifty-person org.

So I run the provenance checks — the tells that code was written by AI are readable in an afternoon: five different patterns doing one job, dependency bloat, comments that describe instead of explain, auth that works until two people log in. What those tells add up to has a name: Vibe Debt — the gap between "it demos" and "someone here can fix it at 2am." The follow-up post on AI technical debt breaks down its three flavors and what each costs.

The diligence question is never "did AI write this?" It's "can the people I'm about to pay explain what the AI wrote?" Comprehension is the asset. Code is just its container.

Red Flags vs. Repricing Events

Not every finding kills a deal. Most just change its price. My rough sort:

• Fix-it findings (negotiate a credit): thin tests, stale dependencies, no staging environment, single-region everything.
• Repricing events: secrets in git history, client-side auth, one-person knowledge monopolies on the money path, GPL code in a proprietary product, a codebase nobody present can walk through.
• Walk-away signals: the demo works but the team can't run it locally; "our contractor has the AWS credentials"; resistance to letting anyone read the code at all.

Who Needs This (and When)

Acquirers, obviously. Investors past the idea stage. But the group I see most: founders running diligence on themselves — before a raise, before a big enterprise customer's security review, or right after realizing their AI-built MVP now has paying users and nobody's senior eyes have ever read it. Finding your own problems costs a repo audit. Having a buyer's engineer find them costs valuation.

What It Costs

My on-ramp is free by design: a 20-minute Loom repo audit with a written summary, no strings. If it surfaces real problems and you want them fixed, the rescue is fixed-price — $25K–$50K for most production codebases, lighter cases from $15K, complex SaaS $60K–$100K, 4–8 weeks, cash only. If you need ongoing senior judgment instead of a one-time review, fractional CTO work runs $5K–$15K/month for about a day a week. I don't bill diligence hourly; an open-ended meter pointed at "keep looking" is not an incentive structure you want aimed at your wallet.

What to Do Next

Micro-action for today: open your repo and try to answer question 6 alone — for each critical system, write one name that truly understands it. Any blank line is your diligence report, self-served, free.

If you'd rather have real eyes on it: request the free repo audit or book a strategy call and tell me what you're buying, funding, or about to launch.

Related guides: how to tell if code was written by AI, AI technical debt, how I evaluate a product project, fractional CTO cost, Vibe Debt.