Technical Due Diligence for Clients: The Checklist I Run

Before I take over a codebase or agree to a fixed-fee project, I run a technical due diligence. Skipping that step is how consultants end up in nightmare engagements. Here is the exact checklist I use and what each item is actually revealing.

Why Due Diligence Matters

Clients describe their systems in sales terms. "We have a modern stack." "The code is clean." "It scales fine." Those claims may be true. They may also be aspirational. The point of due diligence is to find out which before you quote a price.

The Checklist

Code quality
  [ ] Version control: git, with readable history
  [ ] Branch protection on main
  [ ] Test suite exists and passes
  [ ] Linting and formatting configured
  [ ] No secrets in the repo (I grep for common patterns)
 
Infrastructure
  [ ] Deployment is reproducible (IaC or documented)
  [ ] Environments are separated (dev/staging/prod)
  [ ] Backups exist and have been tested
  [ ] Monitoring exists and alerts go somewhere
  [ ] Cost is known, not a surprise each month
 
Security
  [ ] Secrets are managed (vault, parameter store, something)
  [ ] Dependencies have been updated in the last 6 months
  [ ] No obvious OWASP top-10 issues
  [ ] Access controls exist on the production environment
 
Documentation
  [ ] README can get a new developer running
  [ ] Architecture is described somewhere
  [ ] Runbooks exist for common incidents
  [ ] API contract is documented

Every checkbox that fails is a risk. I do not refuse to work with failures. I price them in.

What Each Item Reveals

Test suite: am I going to be afraid to change things? Deployment: can I ship, or am I going to spend a week setting up pipelines? Monitoring: will I find out about production issues from users or from alarms? Documentation: how expensive is onboarding going to be?

Those are the real questions. The checklist is the proxy.

Priced Risk vs Walked Away

Not every failed check is a dealbreaker. Messy code I can refactor. Missing tests I can add. Genuine dealbreakers are things that suggest the relationship itself is risky: secrets in the repo, no backups, unclear ownership of production credentials. Those are signs the client has not taken the system seriously, and I cannot fix that from outside.

When I do walk away, I tell the client specifically which items failed. Sometimes they fix them and come back ready. That is a fair outcome for both of us.

Read the OWASP ASVS for a more rigorous security checklist.