The Tech Due Diligence Checklist I Use Before Engagements

Before I take on any engagement — fractional, project, or advisory — I run technical due diligence. It's not optional, and it's not a tax on the founder. Done well, TDD is the reason an engagement starts on the right footing instead of unwinding three months in.

This post is the actual checklist. Not a framework, not a generic template — the specific things I look at, in roughly the order I look at them, when assessing a new engagement.

It's written for two audiences. If you're a founder considering bringing in a fractional CTO or selling a stake in your business, this is what you should expect them — or an investor's diligence team — to ask. If you're a CTO running diligence yourself, this is one operator's version: borrow what's useful, ignore what isn't.

Two ground rules upfront:

TDD is not a witch hunt. I'm not looking for reasons to walk away. I'm looking for reasons to scope the engagement properly.
The output is a one-page summary, not a 40-page report. Anything longer is theatre, and most founders won't read it.

Phase 1 — The pre-call (30 minutes, no access required)

Before I touch any code or infrastructure, I do a desk review. The goal is to walk into the first technical call with informed questions, not a blank slate.

What I check before the call:

Public-facing site speed and accessibility — PageSpeed Insights, a basic Lighthouse run, mobile responsiveness on a real phone.
Public APIs and documentation — if there's a docs site, what does it look like? If there are public endpoints, what's the response shape and error handling like?
The hiring page — what roles are open, what's the tech stack as advertised, what's the team's seniority signal.
Their changelog or release notes if public — frequency, quality of writing, what they prioritise.
Trustpilot, Glassdoor, and App Store or Play Store reviews. Patterns in user complaints often map directly to engineering failures.
Companies House for the legal entity — useful for understanding the cap table reality and any insolvency or charge filings.

This takes about 30 minutes and tells me more than most founders expect. If the public surface is broken in obvious ways, the private one rarely isn't.

Phase 2 — The codebase

When I get repository access, the first hour is reconnaissance. I'm not trying to read the whole codebase — I'm trying to understand its shape.

What I check, in order:

Repository age and commit frequency. Old repos with sporadic commits tell a different story than young repos with steady commits. Both are fine; mismatches are what I'm watching for — a repo claiming three years of work with eight months of actual commits, for example.
Number of contributors and their distribution. A "team of five" where one person has 90% of the commits is a key-person-risk problem. So is a codebase with 30 contributors and no clear owners.
Branching strategy and PR hygiene. Are commits going straight to main? Do PRs have meaningful descriptions? Are there code reviews, or is it all self-merged? Is the main branch protected at all?
README quality. Can a new engineer get the project running in under an hour using only what's in the repo? If not, that's a documentation gap that will cost the next hire two weeks.
Test coverage — but not the percentage. I look at whether tests exist, whether they're being added with new features, and whether they actually run in CI. The number matters less than the trajectory.
CI/CD pipeline. Is there one? Does it run on every PR? How long does it take? A 40-minute CI run is a productivity tax most teams don't realise they're paying.
Linting and formatting. Inconsistent style across files signals a lack of standards. It doesn't break anything by itself, but it's a strong proxy for whether the team has shared conventions.
The dependency graph. How many third-party libraries? Are they up to date? Any with known CVEs? Any abandoned packages?
Hot files. I run a quick analysis on which files have the most churn — those are usually where the architectural pain lives.

I deliberately don't read the business logic in detail at this stage. The logic is what the team knows best and where I have least context. The structural signals are what I can read fastest and most reliably.

Phase 3 — Infrastructure and deployment

Infrastructure is where I usually find the most quickly-fixable wins. Founders rarely have a clear view of what they're spending and what it's getting them.

What I look at:

Where things run. Cloud provider, regions, and services in use. Multi-cloud setups for early-stage companies are almost always a smell — someone made a portability decision before it was needed.
The cost shape. Monthly cloud spend, broken down by service. I'm looking for the obvious wins: idle resources, oversized instances, dev environments running 24/7, expensive data egress.
How deployments happen. Push-button or manual? Time from "code merged" to "code in production"? Rollback strategy? If there's no rollback strategy, that's the first thing I fix.
Environment parity. Does staging look like production? Is local development possible without spinning up half the cloud account?
Observability. What logs, metrics, and traces exist? When something breaks at 2am, can the on-call person find out why without phoning someone?
Backups and disaster recovery. Are backups happening? Has anyone ever tested a restore? An untested backup is a hopeful guess, not a recovery plan.
Domain and DNS hygiene. Who owns the domain? Where are the DNS records managed? How many SaaS subscriptions are tied to one founder's email?

The DNS and account-ownership questions sound trivial but they're how I find the existential risks. I've seen more than one company where the entire production stack depended on a former founder's personal Gmail.

Phase 4 — Security and compliance

I'm not a security specialist, but there's a baseline every business should be hitting. The point of this phase isn't to do a full audit — it's to identify the gaps that need a specialist before they become a regulator's problem.

What I check:

Authentication. How do users sign in? Is MFA available? Is it enforced for staff? Are there shared accounts?
Secrets management. Are API keys and credentials in a vault, or scattered across .env files in repos? Have any been committed to git history? (I run a basic secret scan early — this is the most common finding.)
Data handling. What personal data does the system touch, where does it live, and who can access it? GDPR is the floor; specific sectors — finance, health — have additional requirements.
Access control. Who has admin access to the cloud account, the database, the CI system? Has anyone left the company recently and still has keys?
Logging. Are auth events, admin actions, and data access logged? Can the team reconstruct who did what, six months later?
Patch hygiene. When was the OS, runtime, and dependency stack last patched? Is there a process or does it happen ad-hoc?
Incident history. Have there been security incidents? What was the response? Were customers notified appropriately?

Sectors with regulatory requirements — FCA-regulated finance, NHS-adjacent health, and public sector — get extra scrutiny here. The cost of getting this wrong scales with the regulator.

Phase 5 — Team and ways of working

Code lives or dies by the team. Two equally good codebases under different teams produce wildly different futures.

What I look at:

Team size, shape, and seniority. How many engineers, how many seniors, how many leads? What's the ratio of permanent staff to contractors?
Working patterns. How long are sprints (if any)? Are stand-ups happening? Is planning lightweight or heavyweight? Are retros happening at all?
Decision-making. Who decides what gets built? Who decides how it gets built? Are those the same person or different people?
Documentation culture. Are decisions written down? Is there an architecture decision record (ADR) habit, or is the rationale in someone's head?
Onboarding. How long does a new engineer take to ship something to production? If the answer is "weeks," there's a fixable problem.
Hiring. What's the pipeline like? What's the interview process? Has anyone good left recently — and if so, why?
Founder/team interface. How does the founder communicate priorities to the team? How does the team push back?

The team questions are often where the most useful conversations happen during diligence. Founders who can answer them clearly tend to be running healthy operations. Founders who can't tend to be the ones quietly losing time. (For founders trying to evaluate the work of an individual developer specifically, I covered that separately in How to Tell If Your Developer Is Building the Right Thing.)

Phase 6 — Technical debt (deliberate vs accidental)

Every codebase has technical debt. The question isn't whether it exists — it's whether the team knows about it and has a plan.

I split debt into three categories during diligence:

Known and accepted. The team can list it, has a view on the cost of carrying it, and has a rough plan for when it gets paid down. This is healthy.
Known and ignored. The team can list it but isn't planning to address it. Sometimes fine (the debt is genuinely low-impact). Sometimes a flag (the debt is significant and there's no plan).
Unknown. The team can't list it because they haven't looked. This is what I'm trying to surface — the issues that will derail a build six months from now if they're not on the radar today.

The output of this phase is usually a short list of the five biggest things the team isn't currently tracking but should be. That list informs the engagement scope more than anything else.

What I do with what I find

The whole TDD process takes 8–12 hours over two or three days. The deliverable is a one-page summary covering:

The three things I'd address first
The two things that are working well and should be protected
The one thing that, if ignored, will cause real pain in 6–12 months
Whether I think the engagement makes sense and at what shape

That's it. No 40-page report. No PowerPoint. The point is to get to clarity quickly, not to demonstrate effort.

If the engagement goes ahead, the summary becomes the basis for the first 90 days of work. If it doesn't, the founder still has a useful artefact and a clear view of where they stand.

What founders should expect

If you're a founder reading this and someone wants to do TDD on your business, the right response is "good — please." A consultant, advisor, or investor who skips diligence is one who'll be guessing for the next six months. You want them informed.

The wrong responses are: refusing access, agreeing to a heavily watered-down version, or treating it as adversarial. None of those serve you.

What you should expect from a good TDD process:

Clear scope upfront — what they'll look at, what they won't, how long it'll take.
Read-only access — diligence shouldn't require write permissions to anything.
A specific deliverable — not "we'll send notes" but a concrete artefact.
A debrief conversation — not just a document drop.
Confidentiality terms in writing before any access is granted.

If those things aren't on offer, push back. If they are, lean in. The process pays for itself the first time it surfaces something you didn't know about your own business.

STAAL & Co provides fractional CTO services backed by a delivery team, starting with technical due diligence on every engagement. If you're considering bringing in senior technical leadership and want to understand what that diligence looks like in practice, a short conversation usually clarifies the scope. Get in touch.