The technical due diligence checklist new CTOs actually need

TL;DR: Most technical due diligence checklists are written for sellers preparing for an audit, not for the CTO who just inherited the seat. This guide flips it: five categories of red flags grounded in real rescue cases, plus the three decision paths — remediate, renegotiate, walk — that most TDD reports never spell out.

Every month a CTO four weeks into a new role calls us with a clean diligence report and a codebase that's already starting to bite them. The report wasn't wrong. It answered exactly what it was asked to answer. The trap was the questions the report didn't ask — because the seller's team didn't think to mention them, and the incoming CTO didn't know to ask.

The five categories below are the ones we see step on people. Each ends with what to do when you find it.

Why most technical due diligence reports answer the wrong question

The technical due diligence reports I've seen from competent firms — ESET-grade vulnerability shops included — were good. They covered exactly what they were scoped to cover. The vulnerability scan caught the vulnerabilities. The code audit identified the code-quality issues. The architecture review flagged the architecture risks.

What was missing wasn't the firm's failure. It was outside the scope of the engagement.

That's the entire trap. A TDD report is a deliverable; it answers a brief. If the brief asks "are there security vulnerabilities," you get vulnerabilities. If you wanted to know whether the only engineer who understands the payment system gave notice last month, that wasn't in the brief. So it's not in the report.

Most TDD content online — including the AKF Partners technology due diligence checklist, the Django Stars guide, and HyperNest Labs' 50-point startup TDD checklist — is written for the seller preparing for the audit. The seller's job is to make the report look good. They have an incentive structure that pushes toward polish.

The incoming CTO has the opposite job. The report is the starting line, not the finish line. What they actually need is a way to surface what the seller's team didn't put in the report — not because the team was hiding things, but because they took the omissions as obvious.

Our CTO Jan has a phrase for it: "You don't know what you don't know." You inherit a clean audit and a black box. Then you step on something inside the first month — almost every time. The bug that crashes the app at 11 PM on a Tuesday. The plugin that broke during the upgrade two weeks before you arrived. The senior engineer who's already mentally checked out.

The rest of this article is a checklist for the buyer's side of the table — for incoming CTOs, acquirers, and investors who want to know what to look for in addition to what the seller commissioned. We'll walk through five categories, then close with the three decision paths every CTO eventually faces: remediate, renegotiate, or walk.

Architecture and scalability: what a competent TDD will catch

Architecture is where most technical due diligence work earns its money. A serious diligence team will walk the deployment topology, run the dependency graph, profile the load patterns, and flag the parts that look like they were built for a smaller version of the company. This part is mostly table stakes.

What you're looking for at this layer:

• Monolith strain. Deploys that block on each other. Releases that require coordinated freezes. "We can only deploy on Thursdays." These show up as cycle-time slowdowns in the engineering metrics.
• Mixed-stack sprawl. PHP backend, Node microservices, Python ML pipeline, all coupled through brittle integration layers. The maintenance cost compounds with every new language the team has to keep current.
• Scaling triggers nobody planned for. N+1 query patterns in the database. Stateful services that don't horizontally scale. Hardcoded queues. A load balancer set up "temporarily" three years ago.

A real example. When we took over the Futurestay platform, it was managing 64,000+ vacation properties across 120+ countries on infrastructure originally sized for a few hundred. The architecture had been right at the time it was built. It had simply outgrown itself. The diligence their previous partner ran caught most of the architecture story — the parts it missed were business-specific load patterns nobody had written down. We rebuilt the booking flow on Laravel, stabilized the platform to 99%+ uptime, and the company secured $2M in funding once the platform held under load.

The architecture findings from a competent TDD are useful. They tell you what the technical debt looks like in shape and scale. What they can't tell you is how often the system breaks in production at 2 AM, because nobody who wrote the report was on call.

For that, you need section six.

Code quality and technical debt: where the report measures, where it can't

The code-quality portion of any TDD report typically covers four things: language and framework versions, test coverage, dependency hygiene, and code-review discipline. These are all measurable. A good firm will report them faithfully.

McKinsey's 2020 CIO survey on technical debt put the cost of unmanaged technical debt at 20–40% of the entire technology estate. That's a 2020 baseline number, not current. In the five years since, nobody has produced a credible estimate that's lower.

When QuantPedia came to us, the platform was running on legacy .NET in a state that made every new feature a negotiation with the existing codebase. The diligence we'd run as part of the rescue showed exactly what you'd expect: framework version two major releases behind, no automated test harness, dependencies pinned to obsolete versions. The code-quality story was textbook.

What the diligence couldn't tell us was the business priority of which features depended on which bits of legacy code. That's the part you can only learn by sitting with the product and engineering teams. We rebuilt the platform on WordPress with a custom architecture, shipped it in stages, and watched subscriptions and traffic grow by 300% after launch — none of which was knowable from the diligence report alone.

The pattern repeats across rescues. Code-quality metrics in a TDD tell you the shape of the debt. They can't tell you which parts of the debt are load-bearing for the business and which are dead weight. That distinction lives in the heads of the people who built the system — and in most handovers, those people don't write it down.

A trap new CTOs hit: a clean test suite covers the parts the team wrote tests for. The parts nobody tested are also the parts most likely to break. Coverage percentage looks reassuring on a slide deck. It tells you almost nothing about what happens when you change the payment service.

Security, compliance, and the boring stuff that kills deals

If you're acquiring a SaaS company, security findings are the most common deal-killer. They're also the easiest to outsource to a competent firm. A vulnerability scan from a serious shop will surface the standard catalog: injection vulnerabilities, dependency CVEs, auth-handling gaps, encryption-at-rest issues.

What it won't tell you is the security debt the seller's team knows about and has been tolerating.

That's the conversation we had with QuantPedia's leadership in the early phase of their rebuild. The technical findings were known. What mattered for diligence was understanding which findings had been deferred deliberately (because the workaround was acceptable for now) and which had been deferred accidentally (because the person who knew about them left the company).

The result speaks: in the years since the QuantPedia rebuild shipped, zero security incidents on the platform. That number is achievable. It just doesn't appear on any TDD report you commission.

Compliance is the other half of the question. SOC 2 and GDPR have been the standard checklist items for years. The newer entry is the EU AI Act, which adds compliance requirements for AI features specifically — including features the seller may have added in a rush before going to market. If the target company has shipped an AI feature in the last 18 months, ask whether the AI Act requirements were evaluated. The answer "we'll handle that later" is itself a finding.

The "I don't know what I don't know" checklist

This is the section the standard TDD report doesn't write — because nobody commissions it.

Every project handover has the same structural weakness. The people running the handover share what they consider relevant. The omissions aren't malicious. They're the result of someone treating their own knowledge as obvious. The buyer doesn't know enough to ask, because the gap is invisible from the outside.

The CTO doing the handover talks about technical debt. The PM gives you a polished first-call deck about why the product exists and what its history is. Both are useful. Neither tells you the whole story. And in roughly nine cases out of ten, the gap between the two — the un-volunteered detail — is what bites the new owner inside the first 30 days.

The five traps we see most often:

1. The core engineer who gave notice two weeks ago. The person who understands the payment subsystem, or the data pipeline, or the integration with the largest customer's stack. They handed in their resignation just before the diligence kicked off. Nobody on the buying side asked. Nobody on the selling side volunteered. The handover document lists their name on the team org chart anyway.

2. The bug that crashes the app once or twice a month, randomly. Everyone on the engineering team knows about it. They've stopped reporting it formally because nothing actionable comes of doing so. The on-call runbook has a workaround paragraph that begins "if you see error 504..." The diligence report describes the application as stable.

3. The two-week-old upgrade that quietly broke three plugins the business depends on. The platform upgrade happened just before the deal closed. Three plugins integrated through the old extension API stopped working. Nobody surfaced it because nobody on the technical team uses those features daily. The first you'll hear about it is when finance asks why their report ran fine last quarter and produces an empty CSV now.

4. The tolerated security risk that's one exploit away from being a real incident. The team knows about it. They've decided the workaround is fine for now. The "for now" started 14 months ago. It isn't in any audit because it wasn't reported externally. It's a Slack thread between two senior engineers and the CISO.

5. The 80% dead code that turns out to be load-bearing. The codebase has long passages nobody touches. The diligence report flags this as a refactor opportunity. What the report can't tell you is that one corner of that "dead" code runs the year-end compliance export the business uses once every 12 months to satisfy a regulator. Touch it, and you'll discover the dependency the hard way.

When we took on the Tentacles IoT rescue, the original supplier had walked away from a half-finished product. The Dutch team was sitting on a stack of partial implementations and one departing senior engineer whose knowledge wasn't documented anywhere. We rebuilt the stack, halved their development cost, and put a working demo in front of customers within weeks. The hard part wasn't the code. The hard part was extracting what only existed in one person's head before that person finished their notice period.

If you're inheriting a system, the right diligence question isn't what's in the report? It's what did you decide not to put in this report, and why? Sometimes you'll get an answer. The fact that you're asking changes what gets surfaced.

The AI and agentic readiness blind spot

This is the newest category of un-volunteered handover risk. It hasn't been formalized into standard TDD methodology yet, which means almost no diligence reports include it.

Most of the AI strategy conversations we have with SaaS leadership end in the same place: the architecture won't support what the board is asking for. According to IBM's Institute for Business Value, 81% of executives believe tech debt is constraining AI success at their organizations. MuleSoft's 2025 Connectivity Benchmark Report put the share of IT leaders citing AI integration difficulties at 95%. The mismatch between AI ambition and architectural reality is the rule, not the exception.

The category to check, but rarely on any diligence checklist:

• APIs designed for humans, not machines. Endpoints that return HTML-coupled data. Authentication flows that assume a browser. Rate limits set for interactive use. None of this is a problem when humans use the product. All of it becomes a problem the moment an AI agent tries to.
• CRUD-only architectures with no event layer. If the platform only knows how to read and write rows, it can't broadcast state changes. Agentic workflows need event streams. Webhooks are the minimum.
• No MCP server support. The Model Context Protocol ecosystem grew from roughly 100 servers in November 2024 to 5,800+ by December 2025, with 97 million-plus monthly SDK downloads (Anthropic MCP first anniversary, Nov 2025). Agents are increasingly expected to consume products through MCP. If the target SaaS has no MCP server and no plan to ship one, the product is becoming invisible to that ecosystem.
• Semantic layer absent. Agents need consistent definitions of business entities across endpoints. If the same "customer" object has three slightly different representations across the API surface, the agent will get stuck.
• Wrapper antipatterns. Bolting an MCP server on top of a CRUD API that was never designed for agents typically produces something that works in demos and fails in production. LiquidMetal AI's piece If your MCP is an API wrapper, you're doing it wrong describes the failure mode cleanly. The agent works for the first five calls and then gets stuck on the sixth.

The targets in the most danger are simple CRUD-only tools that exist to store data and add no real intelligence layer. Those products have no future from a business standpoint, even with the shiniest codebase, because they sit on the wrong side of the agentic shift. The risk is amplified for monolith-style platforms with no clear path to expose machine-consumable interfaces.

We haven't yet delivered a complete AI-readiness transformation engagement — that offering is in active validation as we run the assumption tests. What we have is a strong technical view of the changes the architecture needs to make, anchored in our work on API-first refactoring and event-driven redesign for clients moving in that direction. I'd rather be honest about what we've shipped and what we're still designing than overclaim. The point of this section isn't to claim authority on a transformation nobody has delivered at scale yet. It's to add a checklist category that probably belongs in your diligence work and almost certainly isn't there yet.

As Gauge.sh put it: "The penalty for having a high-debt codebase is now larger than ever." The penalty curve has steepened because AI agents amplify it.

What to do with what you find: remediate, renegotiate, walk

Every TDD article on the internet ends with the checklist. Most of the time that's the section the article needed.

The buyer's side of the table has one more decision to make. You have findings. The deal isn't closed, or the role hasn't been formally accepted, or the budget hasn't been signed. You have three real paths.

Remediate. Take the role or close the deal, and budget the remediation as part of the acquisition cost. This is the right move when two conditions hold: the technical team stays mostly intact, and the diligence you ran was deep and thorough enough that you trust the scope of the work. A focused stabilization phase for a scaleup-stage SaaS typically runs two to three months and €60,000–90,000 for the heavy lifting — a small senior team working through the prioritized list while the existing engineers stay on the feature roadmap. The CFO conversation is easier than people expect. You're not asking to slow down; you're asking to pay for a known fix instead of an unknown future incident.

Renegotiate. Take the findings back to the seller and use them to either discount the deal or add closing conditions. This is the right move when the diligence surfaces something the seller didn't fully disclose. The cases I've seen justify renegotiation:

• The CTO or core engineers departed (or are about to) and weren't flagged
• The TDD itself was shallow — vulnerability scan only, no code review, no architecture walk
• A core framework or library is out of vendor support and the upgrade introduces serious backward-compatibility breaks
• A material security finding is older than the seller represented it as

The amount you ask for varies. The principle doesn't. The price the seller wrote reflected their belief about the asset's state. Your findings give you a basis to renegotiate to the actual state.

Walk. Kill the deal — or if you're the new CTO, formally renegotiate the role's mandate before you fully take ownership. My rule of thumb: tech is always recoverable. People and culture aren't. I've watched a target company where the entire original engineering team left within a single year after acquisition. The acquirer kept the product. They kept none of the institutional knowledge. The product was worth a fraction of what they paid by the end of the year.

The cleanest signal that the right move is to walk: the people in the codebase have already mentally left. They're polite during diligence and unrecoverable inside six months. Reading those signals is harder than reading code. It's the part that no checklist can do for you.

FAQ

How long does technical due diligence take? For a Series A-stage startup, two to three weeks for a competent firm to deliver a thorough report. For an enterprise acquisition with multiple products, four to eight weeks. The buyer-side surfacing work this article describes — the "what's not in the report" conversation — should run in parallel and continues into the first 30 days post-close.

What does a technical due diligence audit cost? Range varies enormously by scope. A focused vulnerability and code audit from a competent firm typically runs €5,000–25,000. A full architecture-and-team review for an acquisition can be €40,000–150,000. The €5,000 Tech Health Audit we run at GrownApps sits at the lower end and is scoped specifically as the "incoming CTO" check rather than the seller's audit.

Who should run technical due diligence? The seller's side commissions one firm; the buyer's side should commission another. Use different firms for each — the seller's diligence is starting evidence, not the final word. Buyer-side TDD is best run by a team with hands-on rescue and modernization experience, not just audit credentials.

When should you walk away from a deal based on TDD findings? When the people are the problem and you can't keep them. Tech debt can be fixed; cultural debt and key-person attrition often can't. If diligence reveals that the engineers who built the system have already disengaged, the asset is worth less than the price.

What's the difference between TDD and a regular code audit? A code audit looks at the code. Technical due diligence looks at code, architecture, infrastructure, team, processes, security, and compliance — usually in the context of an investment, acquisition, or new-CTO appointment. A code audit is one input to TDD, not the whole thing.

How is AI and agentic readiness different from traditional TDD? Traditional TDD checks whether the product runs reliably for human users. Agentic-readiness diligence checks whether the product can be consumed by AI agents — API design, MCP server support, event infrastructure, semantic layer consistency. As of 2026 it's almost never included in a standard TDD scope. It should be, especially for SaaS targets where AI agents are increasingly the buying audience.

Where to go from here

The technical due diligence report your predecessor commissioned probably did its job. The question is whether the job it was scoped for is the job you actually need done.

If you've just inherited a codebase, are about to, or are evaluating one, the Tech Health Audit (Discovery) is the version of this conversation we run for incoming CTOs. It's €5,000, takes two to three weeks, and includes the "what's not in the seller's report" surfacing work this article describes. The output is a prioritized remediation plan with the math for each option — remediate, renegotiate, walk — based on what we actually find.

If you have an audit in hand already and want a second opinion, we'll review it and tell you where the gaps are.

Sources

• Anthropic. Model Context Protocol — first anniversary. 2025.
• AKF Partners. Technology Due Diligence Checklist. Growth Blog.
• Django Stars. Technical Due Diligence: Meaning, Process, plus Checklist.
• Gauge.sh. Engineering velocity research. Referenced quote on tech-debt penalty.
• HyperNest Labs. The 50-Point Technical Due Diligence Checklist for Startups. 2026.
• IBM Institute for Business Value. The CEO's guide to generative AI. 2024.
• LiquidMetal AI. If your MCP is an API wrapper, you're doing it wrong.
• McKinsey. Tech debt: Reclaiming tech equity. 2020.
• MuleSoft / Salesforce. 2025 Connectivity Benchmark Report. 2025.