Technical due diligence checklist for non-technical founders

In short: technical due diligence answers one question for whoever is about to commit money to a codebase: will this work, and if not, where does it break first and what does that cost? The checklist below covers nine areas. Most of the serious findings are not in the code itself; they are in who holds the keys, who understands what, and how releases actually happen.

Who needs technical due diligence

An investor before a round, an acquirer before a deal, a founder before the next build phase, a board before approving a rescue budget. In each case the person deciding is usually not an engineer and cannot judge the answer they are given by the people who built the thing. The point of an independent review is that its author gains nothing from the conclusion: not from the sale, not from the fix.

The nine-area checklist

1. Access and ownership

• Who holds the credentials for production, the database, the domain, the cloud account, the app-store accounts?
• Does the company, rather than an individual contractor, own the repository and the accounts?
• Is the code ownership written in a contract that has been signed?

2. Bus factor

• Which parts of the code does only one person understand? Look at the commit history per module, not at the org chart.
• If that person left tomorrow, what stops?

3. Architecture fit

• Does the structure match what the product has to become in the next twelve months, for example multi-tenancy, a second country, a mobile app on the same API?
• Where is the data model rigid in a way that makes the next feature expensive?

4. Code health

• Dependency age and known vulnerabilities (run the package manager's audit and read the result).
• Test coverage where it counts: payments, permissions, data migration. Overall coverage percentage is a weak signal.
• Dead code, copy-pasted modules and abandoned experiments.

5. Security basics

• Authentication and session handling, tenant isolation, file-upload handling, secrets stored outside the repository.
• A quick scan for the obvious exposures is part of due diligence; a full penetration test is a different engagement.

6. Delivery process

• How does a change reach production? Manual copy, or an automated pipeline?
• Release frequency, rollback plan, and the gap between what the team says happens and what the commit log shows.

7. Infrastructure and cost

• Hosting model, backups (and whether a restore has ever been tested), monitoring, and the monthly bill at today's volume versus at ten times.

8. Documentation

• Can a new developer run the project locally in a day using only what is written down?

9. Remediation cost

• For every finding: what happens if nothing is done, and what it costs to fix in developer-days. A risk with no number attached is a risk nobody acts on.

What this looks like in practice

An investor asked for technical due diligence on a logistics SaaS before a bridge round. The code was better than expected. The risk was elsewhere: a single contractor held the only credentials to the production database and the deployment pipeline, and had not been paid in seven weeks. That is not a code finding and no automated scanner reports it. It went at the top of the risk matrix and was resolved in four days.

The lesson is the order of the checklist. Area 1 (access) comes before area 4 (code health) because it is cheaper to check and more often decisive.

How to run it without being an engineer

1. Define the decision first. A review with no decision attached is an expensive document. "Do we invest at this valuation?" and "do we keep this vendor?" produce different reviews.
2. Ask for read access, not a demo. A demo shows the path the team chose. Read access to the repository and the release history shows the rest.
3. Insist on a ranked output. A risk matrix placing each finding by impact and likelihood, on one page, beats a list of two hundred lint warnings.
4. Get costs in days. If the weakest three areas are not costed in developer-days, you cannot compare the findings to the price.
5. Keep the reviewer independent. Someone who also wants to be hired for the remediation has a reason to find a lot.

Red flags that deserve an immediate conversation

• Production credentials held by one person outside the company.
• No backups, or backups that have never been restored.
• Secrets committed to the repository.
• No way to deploy without that one developer.
• A data model that stores several customers' data with no enforced isolation.

Get it done

My Delivery Risk Audit is exactly this: ten working days, fixed price, a one-page risk matrix, the three weakest areas costed in developer-days, a 90-day plan and a live 90-minute readout. I do not bid on the remediation. Related reading: what a code audit checks, and what it costs.