· 10 min read · fractional CTO · due diligence · startups
A technical due diligence checklist covering architecture, code quality, security, infrastructure cost, team risk, IP and technical debt, plus red flags.
Ten Peaks Tech
Technical due diligence is the part of a funding round or acquisition where someone external looks at what you’ve actually built, rather than what the pitch deck says you’ve built. It usually lands late, under time pressure, and it is frequently the point at which a deal changes shape — a lower price, a longer earn-out, a remediation condition, or occasionally a walk-away.
It is also one of the few examinations a technical team can prepare for almost entirely in advance, because the questions barely change between processes.
This guide is for two audiences. If you’re an investor, acquirer or corporate development lead commissioning diligence, it sets out what to ask for and what the answers should look like. If you’re a founder or engineering leader on the receiving end, it’s the list you should run against yourself before anyone else does. Either way, the aim is the same: separate the problems that genuinely affect value from the ordinary mess that exists in every codebase ever shipped.
Technical diligence is an assessment of whether the technology can support the business case being sold. Not whether the code is beautiful — whether it can carry the growth in the model, at a predictable cost, without a dangerous concentration of risk.
It typically runs after commercial terms are broadly agreed and before signing: after a term sheet, during exclusivity, or as part of a Series A or later round. The window is usually one to three weeks. For a small company, expect a document request, read-only repository and infrastructure access, and two to four interviews with technical staff.
The output is a report to the buyer or investor, generally organised as findings by severity with remediation cost and time estimates. Those estimates matter, because they get converted into money at the negotiating table.
Reviewers want to understand the shape of the system and where it breaks. Expect questions about the main components and how they communicate, where state lives, what the current load is and what happens at ten times that, which parts are single points of failure, and whether anything is genuinely hard to scale — an unshardable database, a single-writer bottleneck, a component that only runs on one machine.
A monolith is not a finding. An architecture nobody can explain is.
Nobody reads the whole codebase. Reviewers sample: the core domain logic, the most recently changed files, and anything security-sensitive. They look at consistency, whether abstractions hold together, how much duplication there is, and whether the code matches the team’s description of it.
On testing, the interesting question is not the coverage percentage — it’s whether the team can make a change and know they haven’t broken anything. A suite that everyone ignores because it’s flaky is worse than a small suite that’s trusted.
Rarely a full penetration test in the diligence window. More often a review of controls and evidence: authentication and access control design, secrets handling, dependency currency, cloud IAM, logging, backups, encryption, and any past incidents. Recent pen test reports and evidence of remediation carry weight. If you’re heading into a process, our application security checklist for SaaS startups covers most of what gets asked.
Reviewers build a picture of what it costs to run the product per customer and how that curve behaves as volume grows. Unit economics that quietly worsen with scale are a real finding. They’ll also look at whether infrastructure is defined in code or configured by hand, how deployment and rollback work, and whether a region or provider failure has an answer.
Often the most consequential section. Who actually built the system, are they still here, and what happens if the two people who understand the core leave after the deal? Reviewers look at commit distribution, documentation, on-call coverage, and whether contractors hold critical knowledge. Retention arrangements for key engineers frequently come out of this.
The ownership chain has to be clean. Every employee and contractor who wrote code needs a signed agreement assigning IP to the company. Missing contractor assignments are a common and genuinely awkward finding, because the fix requires the cooperation of someone who no longer works for you.
On open-source licensing, the concern is obligations that conflict with the business model — most often strong copyleft licences in distributed software — and whether anyone has ever produced a dependency inventory. Any AI-assisted code generation policy will also come up now.
How work gets from idea to production: version control practice, code review, CI, release cadence, environment separation, incident handling. Reviewers want evidence that shipping is routine rather than heroic. Weekly, boring releases tell a better story than a quarterly all-hands deployment weekend.
Every company has it. What’s assessed is whether the team knows where it is, whether it’s getting worse, and what it costs. A team that hands over a written list of its ten worst areas with rough remediation estimates looks in control. A team that says “there isn’t really any” looks either inexperienced or evasive.
The distinction that matters most in a diligence report.
Normal mess — present in nearly every growing company, priced as ordinary cost of doing business:
Red flags — things that change price, structure or appetite:
The pattern is worth naming: reviewers are far more tolerant of problems that are known, documented and estimated than of problems discovered by an outsider in week two.
Both sides of a deal use fractional technical leadership here, and the work differs.
On the buy side, a fractional CTO runs the assessment: agreeing scope and severity definitions with the deal team, requesting documents and access, sampling the codebase and infrastructure, interviewing the engineering team, and producing a findings report with costed remediation. The value is in translation — turning “the billing service is tightly coupled to the legacy schema” into “roughly two engineer-quarters before you can launch the new pricing model”, which is a sentence a deal team can act on.
On the sell side, the same person runs the process in reverse, several months earlier. Find the findings first, fix the cheap ones, document the rest with honest estimates, and assemble the data room before it’s requested. Founders consistently underestimate how much negotiating leverage comes from producing a clean architecture document, a current dependency inventory and a recent pen test report on day one instead of scrambling for three weeks. What Does a Fractional CTO Do? covers the broader role this sits inside.
A note on scope: technical diligence is not a code review. Reviewers who spend the whole window arguing about style produce reports nobody uses. The job is to assess risk to the investment thesis.
| Area | What to request | What “good” looks like |
|---|---|---|
| Architecture | Diagram plus a walkthrough | Current, and any engineer can explain it |
| Scalability | Load figures and known limits | Team names its own bottlenecks unprompted |
| Code | Read-only repo access | Consistent patterns, active recent history |
| Testing | CI config and recent runs | Green, trusted, covers critical paths |
| Security | Controls summary, pen test, incidents | Findings tracked and closed, not just listed |
| Dependencies | Inventory and vulnerability scan | Current, automated updates in place |
| Infrastructure | Cost breakdown and IaC repo | Environments reproducible from code |
| Reliability | Uptime record and incident postmortems | Blameless write-ups with follow-up actions |
| Backups | Policy plus evidence of a restore | Tested restore within the last quarter |
| Deployment | Release history | Frequent, automated, rollback proven |
| Team | Org chart and commit distribution | Knowledge spread across more than one person |
| Documentation | Onboarding guide and runbooks | A new engineer ships in their first week |
| IP | Signed assignments for all contributors | Complete chain, contractors included |
| Licensing | Open-source licence report | No obligations conflicting with the model |
| Data and privacy | Data map, sub-processors, DPAs | Known data flows, documented retention |
| Technical debt | The team’s own prioritised list | Honest, estimated, and shrinking |
| Third parties | Critical vendor list and contracts | No single vendor that could end the business |
If you expect a process in the next twelve months, three things are worth doing now.
Write the architecture document, and keep it current. It’s the first thing requested and the cheapest credibility you will ever buy.
Close the IP chain. Chase every missing contractor assignment while relationships are still warm and the request is routine rather than urgent.
Build your own findings list. Run the table above against yourself, fix what’s cheap, and document what isn’t with a rough estimate beside it. Handing a buyer an honest list of your worst problems sounds counterintuitive, and it is one of the strongest signals of a well-run engineering organisation.
We run technical due diligence for investors and acquirers, and sell-side readiness reviews for founders heading into a process — in both cases producing a findings report with costed remediation rather than a list of opinions. That work sits within our fractional CTO and consulting services, alongside cybersecurity reviews when security is the main concern.
Related reading: What Does a Fractional CTO Do? and the Application Security Checklist for SaaS Startups.
Keep reading
· 10 min read
A clear explanation of what a fractional CTO is, what they do day-to-day, when your company needs one, cost expectations, and how the model works in practice.
· 12 min read
A prioritised security checklist for early-stage SaaS teams: auth, access control, secrets, dependencies, headers, logging, backups and pen testing.
· 9 min read
How to build an MVP that actually validates your idea — covering common mistakes, tech stack choices, realistic timelines, cost ranges, and when to hire a developer vs. build it yourself.
A senior engineer replies within one business day.
