Technical Due Diligence: A Checklist for Investors & Founders
Before an acquisition or a funding round, technical due diligence is what tells you whether the software is an asset or a liability. Here's what it covers, how it runs, and the checklist we work through.
Technical due diligence is an independent assessment of a software product's engineering, run before money moves — an acquisition, a funding round, sometimes a major partnership. Someone who didn't build the thing reads the code, maps how it's put together, pokes at security and infrastructure, and sizes up the people behind it. The point isn't a report card. It's a straight answer to one question: is this software an asset you can build on, or a liability you'll spend years paying down? Get that wrong and you've bought a rewrite you didn't price.
This is the version we'd give an investor or an acquirer who wants to know what they're actually buying, and a founder who's about to be on the other side of the table. It covers what tech due diligence is, when it happens and who runs it, the full checklist we work through, the red flags that show up most, and how to prepare if you're the one being assessed.
What technical due diligence is
Technical due diligence is the engineering half of the diligence an investor or acquirer runs before a deal closes. The financial side checks the books. The legal side checks the contracts. The technical side checks whether the product that generates all those numbers is actually built to last, or held together with the software equivalent of duct tape and good intentions.
It's broader than a code review, and that trips people up. A code review asks "is this code good?" Software due diligence asks "what am I buying, what's it worth, and what will it cost me to keep it alive?" Those are different questions. Beautiful code on top of an architecture that can't scale is still a problem. A few rough modules in a system that's otherwise sound and well-run is usually fine. The job is to weigh all of it against what the deal actually depends on — and to put a number, or at least a range, on the risk.
When it happens and who runs it
Technical due diligence happens whenever someone's about to commit real money to software they didn't build. The classic moments are an acquisition, where a buyer needs to know the codebase they're inheriting is worth the price, and a growth-stage funding round, where an investor wants proof the technology can carry the company's plans. It also shows up before a big partnership or integration, when one party's product becomes a dependency of another's.
Who runs it matters as much as when. The reviewer has to be two things at once: senior enough to read the code and judge the architecture without hand-holding, and independent enough to say "this looks risky" without flinching at who's paying. That's usually an outside firm or a fractional CTO the investor brings in — someone who's built and operated real systems and has no stake in the deal closing. A junior with a checklist will miss the things that matter, and an insider will, consciously or not, soften the parts that should worry you.
The most dangerous diligence report is the clean one written by someone who only looked at what they were shown. If nobody asked to see the deploy process or the on-call history, the review didn't happen — a demo did.
The technical due diligence checklist
A real technical due diligence checklist runs across seven areas. None of them stands alone, and a good reviewer weights them by what the deal rides on — security carries more weight for a regulated fintech product, scalability matters more for something about to 10x its users. Here's the shape of it.
| Area | What it checks | What you're really asking |
|---|---|---|
| Code quality | Readability, test coverage, consistency, review habits | Can a new engineer be productive in this code, or will every change be a fight? |
| Architecture & scalability | How the system's split, where state lives, the bottlenecks | Does this hold up when usage grows, or does it need a rebuild first? |
| Security | Auth, data handling, dependencies, known vulnerabilities | What's the exposure, and how bad is the worst plausible breach? |
| Team & bus factor | Who knows what, documentation, key-person risk | If two people leave, does the knowledge leave with them? |
| Tech debt & roadmap | Deferred work, shortcuts taken, what's planned next | How much is owed, and is anyone actually paying it down? |
| IP & licensing | Code ownership, open-source licences, third-party terms | Do they legally own what they're selling you? |
| Infra & operations | Deploy process, monitoring, backups, incident history | When it breaks at 2 a.m., what happens? |
A few of these deserve more than a row. Code quality is the one everyone reaches for first, and the easiest to fake — clean formatting and a tidy folder structure tell you almost nothing. What matters is whether there are tests that actually run, whether changes get reviewed, and whether the code does what the demo claims. "Clean code" theater is real, and a reviewer who stops at surface tidiness gets played.
Team and bus factor is the area almost nobody checks properly, and it's often the biggest risk in the whole deal. Bus factor is the number of people who'd have to get hit by a bus before the project stalls. If the answer is one — one engineer who holds the whole system in their head and never wrote it down — you're not buying software, you're buying a hostage situation. The code can be excellent and the company still falls apart the day that person leaves.
IP and licensing is the quiet landmine. A product can be technically sound and legally radioactive — a copyleft licence buried three dependencies deep, code a contractor never properly assigned, a model trained on data nobody had the rights to. This rarely shows up in a demo and routinely shows up in a deal that blows up later.
The other areas — architecture, security, tech debt, infrastructure — each get sized the same way: what's the risk, what would it cost to fix, and how much of that are you inheriting on day one?
Red flags that surface most often
The red flags in technical due diligence are remarkably consistent across deals, which is a small mercy — once you know the pattern, you know where to look first. None of these is automatically fatal. What matters is whether the team knows about the problem and has a plan, or whether they're finding out about it from your reviewer.
- No tests, or tests that don't run. Not the absence of 100% coverage — that's a fantasy. The absence of any meaningful safety net, which means every change is a gamble and velocity will crater the moment the original authors leave.
- A bus factor of one. One person who understands the system and nothing written down. The most undervalued risk in software diligence, and the hardest to fix after the deal closes.
- Undisclosed technical debt. Not the existence of debt — every real system has it. The problem is debt nobody mentioned, surfacing in the code as the reviewer reads. It says the team either doesn't know their own system or wasn't being straight with you.
- Security as an afterthought. Secrets in the repo, no dependency updates in two years, auth rolled by hand. Each one's a thread; pull it and you often find more.
- A roadmap that ignores the debt. Twelve months of new features and not one line about the load-bearing module everyone's afraid to touch. A roadmap that only adds is a roadmap that's accelerating toward a wall.
The pattern underneath all of these is the same: the gap between what the team says and what the code shows. A small, honest gap is normal. A wide one is the actual finding.
How to prepare for technical due diligence
If you're the founder being assessed, the way to prepare for technical due diligence is to get your house in order before anyone asks to see it — and the good news is that doing so makes your product better regardless of the deal. Reviewers aren't looking for perfection. They're looking for awareness. A team that can name its own weak spots and show a credible plan reads far better than one insisting everything's spotless right up until the code says otherwise.
Concretely: write down your architecture, even roughly, so a stranger can follow how the system fits together. List every third-party dependency and its licence, so the IP question has an answer ready. Document how you deploy, monitor, and recover, because "it's all in Dave's head" is the answer that sinks deals. And be honest about the debt you already know about — a short, candid list of what you'd fix with more time builds more trust than any amount of polish. If you don't have someone in-house who can pull that together credibly, that's exactly the kind of preparation a fractional CTO arrangement is built for.
The deeper point is that diligence-readiness and good engineering are the same thing. The team that's always ready to be assessed is just a team that documents, tests, and tells the truth about its own system. If you're building toward a round or an exit and want a clear-eyed read before an investor's reviewer gives you theirs, that's the heart of our software development consulting, and it sits inside the broader tech consulting practice. Whether you're scoping a custom build from scratch or deciding how to structure the team that maintains it after the deal, the standards a reviewer checks for are the same ones worth building to from day one — the same logic we apply to pricing a custom build, where the real cost is always what the software quietly depends on.
Frequently asked questions
Technical due diligence is an independent assessment of a software product's engineering before money changes hands — usually an acquisition or a funding round. A reviewer reads the code, maps the architecture, checks security and infrastructure, and sizes up the team that built it. The goal isn't a grade. It's an honest read on whether the software is an asset you can build on or a liability you'll be paying down for years, and what it'll cost to fix whatever's wrong.
Seven areas, roughly: code quality, architecture and scalability, security, the team and its bus factor, technical debt and the roadmap, IP and licensing, and infrastructure and operations. A good review weights them by what the deal actually rides on — security and compliance matter more for a fintech product, scalability matters more for something about to grow fast. The thread through all of them is risk: what could break, what it would cost to fix, and how much of that you're inheriting.
Anywhere from a few days to a couple of weeks, depending on scope and how much the deal rides on the technology. A quick read on a small codebase to confirm there are no obvious landmines can wrap in days. A full review of a large product — multiple services, regulated data, a team you need to assess — runs longer. The bigger variable is usually access: how fast you get the repos, the docs, and time with the engineers.
Senior engineers who've built and run real systems, not a junior with a checklist. On the buy side it's usually an independent firm or a fractional CTO the investor or acquirer trusts to give a straight answer. The reviewer has to be technical enough to read the code and judge the architecture, and independent enough to say the deal looks risky without worrying about who signs the cheque.
Get your house in order before anyone asks. Write down the architecture, list every third-party dependency and its licence, document how you deploy and monitor, and be honest about the technical debt you already know about. Reviewers don't expect perfection — they expect awareness. A team that can name its own weak spots and show a plan to address them reads far better than one that pretends everything's clean and gets caught out in the code.
More from the journal
Mobile App Security: Threats, Best Practices & Checklist
A mobile app carries data, credentials, and your reputation in a place you don't control: the user's device. Here's what threatens mobile app security, the practices that defend against it, and a checklist to harden an app before it ships.
Blockchain Security: Threats, Best Practices & Audits
Blockchain moves value with no undo button, which makes security the whole game. Here's what actually threatens blockchain systems — contracts, wallets, bridges, exchanges — the practices that defend them, and where audits fit.
What Is a Fractional CTO? Role, Cost & When to Hire
A fractional CTO gives you senior technical leadership a few days a week, without the full-time hire. Here's what the role actually covers, what it costs, and the signs you need one — or don't yet.