Technical Due Diligence Checklist: What I Check Before You Buy, Invest or Sign

Technical due diligence answers one question: can this software do what your business plan assumes, at a cost you have actually priced in? I check code, architecture, data, security, infrastructure costs, the team, process, licensing and documentation. Every finding gets a cost attached, so it can change the price, the terms or the decision.

You're about to buy a company, invest in one, inherit a codebase, or sign a large contract with an agency. The demo looks good. The pitch deck looks better. And you can't read the code.

That's normal. You don't need to read it. You need someone who can, and who will tell you what it means in money, time and risk before you sign. This is the checklist I work from, including the parts you can check yourself.

What is technical due diligence, and when do you need it?

Technical due diligence is an independent review of a software product, its codebase and the team behind it, done before a commitment that's hard to reverse. The seller tells you what the software does. Due diligence tells you what it will cost to keep doing that, and to do the next thing.

For that last one, the estimate deserves its own review: see how to evaluate a software development estimate.

The technical due diligence checklist

This is what I look at, area by area, and what I'm asking. Most of it needs an engineer with access to the code and the cloud account. I'll come back to what you can check yourself.

Code

• Is the code in a version control repository the company owns, not a developer's personal account?
• Are there automated tests, and do they actually run? How much of the critical path do they cover?
• Are the language, framework and major libraries on supported versions, or past end of life?
• Are there hot spots: files nobody wants to touch, features that break whenever anything changes?

Architecture

• Does the structure match how the business actually works? A data model built around the wrong core idea is the most expensive thing to fix.
• Can it support the next stage of the plan? A tool built for one organization is a different animal from a product that serves many customers (multi-tenant, in engineering terms).
• How hard is it to add a feature? Ask for an example of a recent one and how long it took.

Data

• Where does the data live, who owns it, and can it be exported?
• Are there backups, and has anyone ever restored from one? An untested backup is a hope, not a backup.
• Are there audit or retention requirements, and does the system meet them?

The finding that matters most here is fit. Messy code can be cleaned up in place. A data model that doesn't match the business usually means a rebuild. And if the seller's answer to every weakness is "we're planning a rewrite", be careful: a rewrite is a project with its own risks, not a fix. On one modernization project, a previous rebuild attempt had stalled at roughly 18%. We upgraded the existing platform in gated phases instead, because the real specification lived in the running application, not in any document. I go deeper on that call in Rebuild vs Refactor.

Security

• Who has admin access to production, the domain registrar, the cloud account and the code? Is anyone on that list a former employee or contractor?
• Are secrets (passwords and API keys) stored in the code, or in a proper secrets store?
• Are dependencies scanned for known vulnerabilities, and are any security-critical libraries abandoned?
• How are customer passwords and personal data stored and protected?

Infrastructure and running costs

• What does it cost to run per month, line by line: hosting, database, email, storage, monitoring, every third-party service?
• Which of those costs grow with users, and how steeply?
• How does code get to production? Automated deployment, or one person following steps from memory?
• Could the infrastructure be rebuilt from code or config, or was it clicked together by hand?

Running costs are a decision, not a fact. At Business Builders we took the Hosting department from break-even to over 40% gross margin, by migrating more than 100 sites to a cheaper platform and onboarding 75 clients. In diligence that cuts both ways: an inflated bill is upside, and an artificially low one is a cost waiting for you after close.

Team and bus factor

• Who can deploy, fix a production outage and explain the architecture? If the answer is one person, that's your bus factor (how many people would have to leave before nobody understands the system). One is a risk you are buying.
• Are the key people staying after the deal, and on what terms?
• How much of the work is done by contractors or an outside agency, and what do their contracts say?

Process

• How does work get planned, reviewed and released? Is there code review before changes ship?
• Is there a visible backlog, or does work live in someone's inbox?
• How often do releases go out, and how often do they get rolled back?

Weak process is usually fixable without touching the code. At Business Builders I rescued an at-risk SaaS client relationship by introducing code standards, an external Kanban board so the client could see the work, and an 8-stage workflow.

Licensing, IP and third-party dependencies

• Did every employee and contractor assign their IP to the company in writing?
• Are any open source libraries under copyleft licenses (licenses that can require you to publish your own source code if you distribute the software)?
• Which third-party APIs or platforms would break the product if they changed their terms or prices?

Documentation

• Is there an architecture overview, a setup guide and a deployment runbook a new engineer could follow?
• Are business rules written down anywhere, or only encoded in the code and in people's heads?

Missing documentation isn't fatal, but it is a cost: every question it would have answered gets answered by an expensive person instead. That's the argument I make in Documentation Debt.

Which red flags matter most, and what do they cost?

Here's how I translate the common findings into the terms a deal actually uses:

The question for each finding is whether it changes the price, the terms, the plan or the decision. Most findings change the plan. A few change the price. Very few should kill a deal on their own.

What can a founder check without an engineer?

More than you'd think. These need nothing but questions:

1. Ask for a list of every recurring technology bill. If nobody can produce it, that's a finding.
2. Ask who owns the accounts: domain, hosting, code repository, app stores, email. They should be in the company's name.
3. Ask when the last release went out and who did it. "Months ago" or "only one person knows how" are both answers.
4. Ask what happens if the lead developer leaves next week. Listen for a plan, not reassurance.
5. Ask for signed IP assignment agreements for everyone who wrote the code.
6. Ask when a backup was last restored, not just taken.
7. Ask for the architecture overview and deployment guide. Then see whether they exist.

What you can't check yourself: code quality, security, and whether the architecture and data model fit the plan. Those need someone who reads code for a living and has no stake in the deal.

How long does technical due diligence take?

It depends on scope. A focused review of one product, with prompt access, is generally a matter of days to a couple of weeks. Several products, many integrations or regulated data take longer.

The thing that slows it down is almost never reading speed. It's access. Ask for repository access, read access to the cloud account and an hour with the lead developer on day one.

What should a technical due diligence report contain?

Written for the person signing, not for other engineers:

1. A plain-English summary with a recommendation. Proceed, proceed with conditions, or don't.
2. Scope and access. What was reviewed, what wasn't, and why. Gaps here are findings too.
3. Findings by area, each rated by severity.
4. A cost for each finding in money, time, headcount or risk, and what it affects: price, terms, plan or decision.
5. Key-person risk and what it would take to reduce it.
6. The recurring cost picture, current and as usage grows.
7. A first-100-days plan: what to fix first and what can wait.
8. Open questions that the seller or vendor still needs to answer.

If a report can't tell you what to do next, it's a description, not diligence.

Get the answer before the signature

The expensive version of due diligence is finding all this out after close, when every finding is your problem instead of a negotiating point.

This is exactly what a Technical Assessment covers: I review the code, architecture, data, security, costs and team, and give you a written report with a recommendation and a cost on every finding. After 25+ years building software, eight of them owning a P&L, I give you the answer in the terms you're deciding in.

FAQ

Related Reading

• How to Evaluate a Software Development Estimate (Before You Sign): The same scrutiny, applied to the quote from an agency or dev team.

• Rebuild vs Refactor: How to Decide Whether to Rewrite Legacy Software: What to do when diligence says the codebase needs serious work.

• Documentation Debt: The Hidden Cost of Disorganized Knowledge: Why missing documentation shows up as a cost, and how to pay it down.

If you're about to buy, invest in or sign for software you can't read yourself, get it checked while a finding is still a negotiating point. Get in touch if you want me to look before you commit.