Technical Due Diligence Checklist for Non-Technical Founders

Technical due diligence is a structured check of whether a codebase can ship, scale to the next stage, and be maintained by someone other than the people who wrote it. You can run a useful version in a week with one borrowed senior engineer and the checklist below. You do not need to read code. You need to ask the right questions, watch the answers being produced, and know what good and bad look like for each one.

Part 2 of the Fractional CTO guide. Part 1 covers what a fractional CTO does for Canadian and US startups.

Table of Contents

• What diligence is for
• What the published checklists miss
• Ownership and access
• The codebase
• Architecture and data
• Security basics
• Operations
• Team and bus factor
• Costs
• The printable checklist
• What to do with the results
• When to bring in a fractional CTO
• FAQ

What diligence is for

Founders usually arrive here in one of three situations. An agency built the product and the contract is ending. A technical co-founder left and nobody else has touched the code. Or an investor wants a technical review before a round and you want to know what they will find first.

In all three cases you are answering the same three questions. Can it ship: if you hire a developer on Monday, can they get a small change to customers by Friday without breaking anything. Can it scale to the next stage: whatever your plan says for the next 12 to 18 months, at a cloud bill you can afford. Can someone else maintain it: if everyone who built it left tomorrow, how long until a new team is productive.

I was founder and CTO of Mago through three funding rounds and CTO at Levpay before Pagsmile acquired it, so I have been the person answering these questions. The findings that hurt are usually about ownership and operations, not code style.

What the published checklists miss

I read three that rank well for this topic before writing mine. SDA’s checklist for non-technical founders covers code, testing, infrastructure, security, documentation and technical debt, and says a comprehensive review takes two to three weeks. Matt Van Itallie’s prep checklist on TechCrunch, written from the acquirer’s side, is the only one that asks for evidence of domain ownership and IP assignment agreements from vendors. Halo Lab’s checklist adds team structure, labour costs and roadmap.

All three assume the reader will hand the list to an engineering team, and none tells a founder how to verify an answer. “We have automated backups” is an answer; watching someone restore last night’s backup is verification. None asks who gets paged at 2am, whether the cloud bill tracks usage, or whether the admin panel is open to the internet. Those gaps are where agency builds and abandoned codebases hurt, so this checklist spends its time there.

Ownership and access

Start here, because nothing else matters if you do not own what you are evaluating. Go through each item live with whoever holds access today, and do not accept “I’ll send it later”.

The repository should sit in an organisation you own; the test is whether you can remove any other user yourself. Log in to the domain registrar and check the registrant email and renewal card are yours. The cloud account, and any platform like Vercel or Supabase, should be billed to your company with a root email you control. If the agency pays the bill and re-invoices you, the infrastructure is theirs.

Ask where the database password and API keys live. A secrets manager you can rotate is good; a shared spreadsheet, a chat message, or only the agency’s deploy pipeline is bad. List every third-party service (payments, email, auth, app store developer accounts) and confirm you hold the owner login.

Then read the contract. It should assign the code to your company; if it does not say so, assume it does not. Record everything in a spreadsheet with three columns: what, who owns it today, who should. The gap between the last two is your first negotiation.

The codebase

This is where the borrowed engineer earns their day. Hand them a laptop with nothing installed and the repository URL, and time how long until the app runs locally. Within an hour from the README alone is good. Needing to message the original developer means the project has never been handed to anyone. While they are at it, look for one command that starts everything, including the database: a Makefile, a docker-compose.yml, or a single documented script. Six terminal windows in a specific order costs every new hire their first week.

Have the engineer run the test suite, then open the CI tab and look at the last 20 runs. Tests on every pull request, mostly green, is good. No CI, a badge red for months, or three test files in a 50,000-line project is bad. SDA suggests 70 to 80% coverage for critical logic as a benchmark. I care less about the number than whether the tests exercise the paths that make money: signup, payment, the core workflow.

Check the runtime and framework versions against what is still supported; a version past end of life means the new team’s first job is an upgrade nobody budgeted for. Run the ecosystem’s audit command (npm audit, pip-audit, govulncheck, bundle audit) and count the high and critical findings. Read the commit log: small regular commits from more than one person is good; giant commits labelled “updates”, a single author, or a two-month gap before handover is bad.

Last, have the engineer read for an hour and tell you in plain language whether a competent stranger can follow the code.

Architecture and data

You do not need a diagram. You need to know where the data lives and whether it would survive a bad day.

Ask for a list of every store that holds customer data: the main database, file storage, caches, queues, analytics, third-party systems. If the team cannot name every place, neither can whoever has to delete that data on request.

Ask when the last backup was taken, then have the engineer restore it into a fresh database and open it. The backup exists if and only if the restore works. Check that there is a staging environment that resembles production; testing on production, or staging sharing the production database, goes on the list.

Then ask what breaks first if traffic triples. A good answer names a specific thing: one table, one background job, one external API limit. “It should be fine” with no reasoning is a bad one. The system does not have to scale to anything yet; the people running it have to know where the walls are.

Security basics

You are checking for the obvious, not running a penetration test.

Run a secret scanner over the full git history. gitleaks is a common choice; its git command reads patches from git log -p, so a key committed and later deleted still shows up. Anything it finds has to be rotated, whether or not you think anyone saw it.

Ask how users log in and how passwords are stored. A managed provider (Auth0, Clerk, Cognito, Firebase Auth) or a well-known library using bcrypt, scrypt or argon2 is fine. Anything hand-written, or MD5 or SHA-1 for passwords, is wrong. On GitHub, check whether Dependabot alerts are on and how many are open.

Have the engineer open the admin interface, database admin tool and monitoring dashboard from outside your network. Anything that answers without a login or VPN is a finding, as is any database with a public IP or any publicly readable storage bucket. These are common in agency builds because developers worked from many networks and opening everything was the convenient fix. Finally, list everyone with production access: anyone who has left should be gone, and the rest should have two-factor authentication on.

Operations

Ask the engineer to deploy a typo fix to staging, then production, and watch. Push a branch, merge a pull request, a pipeline does the rest, and there is a documented rollback: good. One person running a script from a laptop, files copied over FTP, or nobody willing to deploy on a weekday: bad.

Ask what happens when the site goes down. The answer should name a tool (uptime checker, error tracker, cloud alarms) and a person. “Customers tell us” is the wrong answer. Then ask who is paged, how, and what happens when that person is on holiday. If the name is at the agency, find out what your contract says about response times after handover.

Ask whether there are runbooks for the usual failures: database full, certificate expired, deploy failed, third-party API down. Their absence is not a red flag by itself for an early product, but it tells you how little of the firefighting was written down.

Team and bus factor

The bus factor is, in Wikipedia’s definition, “a measurement of the risk resulting from information and capabilities not being shared among team members”. In practice: how many people would have to leave before nobody could work on the system.

Measure it from the commit history rather than from what people tell you. git shortlog -sn prints commits per author, and if one name has 90% of them your bus factor is one. For an agency build, ask which individual developers did the work and whether they are still there; agencies rotate people, and the one who understood your payment flow may have left a year ago.

Then look at pull requests. Every change reviewed by a second person means knowledge has already spread; none, or ones merged by their author within a minute, means it has not. Over a longer window, PR throughput and review time show whether the team is still shipping or only patching, which is what I built DeliveryCompass to show. For a one-week review, the repository’s Insights tab on GitHub is enough.

Ask who works on the codebase today, their status (employee, contractor, agency) and their notice periods. The gap between who built it and who can maintain it is often the most important finding of the week.

Costs

Put the last three months of cloud bills next to your usage numbers. If users were flat and the bill doubled, something is misconfigured or someone turned a service on and forgot it. Open the billing console sorted by service and ask about the top five lines; each needs a one-sentence purpose.

Then ask what triples with traffic and what does not. Per-request managed services usually do; a fixed set of servers does not, until it falls over. Neither is wrong, but your financial plan should match the answer. Also list every paid SaaS the product depends on and who holds the subscription, because they often sit on a developer’s personal card.

The printable checklist

Give the engineer the “how to check” column and fill in the result yourself.

What to do with the results

You will end up with three piles.

Fix. Most security and operations findings go here: rotate leaked secrets, close the open admin panel, test a restore, add two-factor, remove departed users. These are days of work that a contractor can do without understanding the business. Do them first whatever else you decide.

Renegotiate. Ownership findings go here. If the agency holds the repo, domain or cloud account, that is a contract conversation to have before the engagement ends, while you still have leverage. The same applies to a departed co-founder who still holds admin on anything.

Rewrite, or not. Resist starting over until you have answered the three questions from the top. If the product ships, the data is safe and someone can maintain it, a messy codebase is a cost you pay down gradually. A rewrite is justified when the codebase fails the maintainability question outright: nobody can run it locally, the runtime is years past end of life, and the only person who understood it is gone. Even then, replace one piece at a time behind the existing interfaces rather than freezing the product for six months. A stalled rewrite costs more than ugly code, because you pay for two systems and ship neither.

Whatever you decide, write the findings down with dates. If an investor runs their own review later, your list and what you fixed is worth more than a clean report.

When to bring in a fractional CTO

A borrowed engineer can run the checklist. What they usually cannot do is weigh the findings against your business plan, negotiate with the agency, or tell you whether the scale point the team named matters for your next 18 months. That is judgement work, and it is what a fractional CTO is for.

Bring one in when an investor has asked for diligence and you want to see the findings first, when the agency handover needs negotiating, when you have to choose between repair and rewrite, or when you are about to hire your first in-house engineers and want someone to set the bar. Part 1 of this series explains how fractional CTO engagements work for startups in Canada and the US. If you have inherited a codebase and want a second opinion, you can book a call with me.

FAQ

What does technical due diligence cost?

It depends on who runs it and for how long, and the published checklists do not price it. The version in this post costs a week of one senior engineer’s time plus a few hours of yours, whether that engineer is borrowed or comes with a fractional CTO engagement. Investor-commissioned reviews run longer; SDA puts a comprehensive one at two to three weeks.

How long does technical due diligence take?

About a week for an early-stage product with one engineer. Ownership and access take a day if the current holders cooperate, codebase and data checks a day or two, security and operations another day, and the rest is writing up findings.

Can I do technical due diligence without an engineer?

You can do the ownership, access and cost sections yourself, and they are the ones most likely to surface a serious problem. The codebase, security and operations sections need someone who can run commands, read a test suite and recognise a bad password hash.

What is a bus factor?

Bus factor is the number of people who would have to leave before nobody could work on the system. A bus factor of one means a single person holds all the knowledge, which is the common case for agency builds and solo technical co-founders. Measure it with git shortlog -sn and by checking who is still reachable, not from what the team says about documentation.

What if the agency won’t give repo access?

Treat it as a contract problem first and a technical problem second. Read your agreement for the IP assignment and deliverables clauses, and ask in writing for owner-level access to the repository, domains and cloud accounts, with a date. If the contract is silent on ownership, you need a lawyer before you need an engineer. Do not pay the final invoice until you hold the keys, because your leverage drops to zero afterwards.