Technical due diligence from a CTO who has been through the deal
Technical due diligence is an independent review of a company’s software, infrastructure and engineering team before an acquisition or investment. The point isn’t a grade. It’s to tell you what you’re actually buying, what it will cost to fix, and which problems should change the price or the terms.
I’ve been CTO through an acquisition and on the seller’s side of two exits, so I know which parts of a data room are polished for the buyer and where the real risk tends to sit. I read the code, talk to the engineers, and give you a written report you can use in negotiation.
What I examine
Software due diligence covers more than the code. A clean repository with one engineer who understands it is a bigger risk than a messy one with a healthy team. I look at each area and score it against the deal thesis, not against an abstract ideal.
- Architecture. Can it carry the growth in the business plan? Where are the single points of failure, and how hard is the data model to change?
- Code quality and delivery. Test coverage on the parts that matter, how often the team deploys, how long changes take to reach production, and how much of the codebase nobody touches because they’re afraid to.
- Infrastructure and operations. Hosting, backups that have actually been restored, monitoring, incident history and cloud spend relative to revenue.
- Security. Secrets handling, access control, dependency hygiene, past incidents and how they were handled. This isn’t a pentest; I’ll tell you if you need one.
- Team and key-person risk. Who holds the knowledge, who is likely to leave after the deal, and whether the roadmap is realistic for the people you’re getting.
- IP and licensing. Copyleft licenses in shipped code, contractor IP assignment, third-party services the product can’t live without.
- Cost to operate and cost to fix. The number most acquirers care about once the excitement wears off.
If you want to run parts of this yourself, my technical due diligence checklist lists the questions by area along with what a red answer looks like.
What the deliverable looks like
You get a written report designed to be read by people who won’t open the code. It starts with a short summary: overall view, the findings that matter for the deal, and my recommendation. Behind that sits the detail for your technical people.
- Each finding rated by severity and by how likely it is to bite in the first year.
- A rough effort estimate to remediate, in engineer-weeks, so you can turn findings into a number.
- A clear split between deal issues (price, warranties, escrow, retention) and post-close work (the first 100 days).
- Questions to put to management where the evidence was incomplete.
I’ll also walk you through it on a call. Reports get skimmed; conversations get to the point faster.
Red flags vs normal mess
Every codebase that has made money has scar tissue. The skill in tech due diligence is separating what’s ugly from what’s dangerous. Here’s how I usually sort it.
- Normal mess: outdated dependencies, inconsistent style, a few god classes, thin documentation, tests that are slow or flaky. Annoying and fixable, usually priced into the first year of engineering budget.
- Worth negotiating: a framework version out of security support, a monolith that needs real work to scale, no restore ever tested, cloud costs growing faster than revenue.
- Red flags: one person who can deploy and won’t be staying, customer data in places nobody can list, GPL-family code inside a product you distribute, IP created by contractors without assignment, and numbers in the pitch deck the system can’t actually produce.
Red flags don’t always kill a deal. They change the structure: a retention package for the key engineer, a specific warranty, a holdback, or a source code escrow arrangement.
How it runs
- Scoping call. You tell me the deal, the thesis and the timeline. I tell you what’s realistic to cover and what I’d leave out.
- Access. Read-only access to the repositories, cloud console and ticketing, plus a few hours with the CTO and two or three engineers.
- Review. I read code, run the build, look at deploy and incident history, and check claims against what the system actually does.
- Report and walkthrough. Written findings, a summary page for the investment committee, and a call to answer questions.
Why a former CTO rather than an audit firm
Large IT due diligence firms are good at breadth and checklists, and for a large carve-out with dozens of systems that’s what you want. For a software company with one product, the risk is in specific judgement calls: is this data model going to hold, will this team ship the roadmap, is this rewrite proposal sensible or a red flag in itself.
Those are calls I make every week as an engineering lead. I’ve built payment platforms, scaled Yola from 10K to 11M users as an early engineer, and co-founded and sold a software studio after 200+ projects. I know what good looks like at different stages, and what’s reasonable to expect from a seed-stage team versus a company with 50 engineers.
If you’re a fund or acquirer rather than a founder preparing for a raise, the page on due diligence for investors and acquirers covers independence and timing in more detail.
Preparing for diligence as a seller
I also work the other side. If you’re raising or selling, a pre-emptive review finds the issues before the buyer’s team does, while you still have time to fix them or explain them. The usual fixes are cheap: an up-to-date architecture diagram, an IP assignment sweep, a license scan, a tested restore and a written answer to “what happens if your lead engineer leaves?”
Questions
What is technical due diligence?
Technical due diligence is an independent assessment of a company’s technology before an investment or acquisition. It covers architecture, code quality, infrastructure, security, the engineering team and IP, and translates what it finds into deal risk and cost to fix.
How long does tech due diligence take?
It depends on the size of the system and the deal timeline. I scope the review to fit the deal window. I agree scope and timing up front so the report lands before you need it.
Is software due diligence the same as a code audit?
No. A code audit is for owners who want to understand their own system. Software due diligence is done for a buyer or investor, under deal confidentiality, and the findings are framed around price, terms and post-close risk.
Do you need full access to the source code?
Read-only access is ideal. When a seller won’t share code before signing, I can still do useful work through screen-shared walkthroughs, architecture sessions and repository metadata, and I’ll tell you clearly which conclusions are weaker as a result.
Can you help after the deal closes?
Yes. Many findings turn into the first 100 days of work, and I can lead that hands-on as an embedded engineering lead or interim CTO while you hire.
Got a deal on the table?
Tell me the timeline and what you’re worried about. I’ll tell you what I can cover in the time you have, and what I’d leave out.
GMT+2 · Full EU overlap · US East mornings