Technical Due Diligence in 2026: How to Assess a Codebase Before You Commit

Technical due diligence is one of those things everyone says they do and few do well. The common version is: a developer looks at the code for a day, says “it’s messy but fixable,” and the deal closes. Then six months later the team discovers the database has no backups, the main developer left taking all the tribal knowledge, and the “fixable” monolith requires a full rewrite to add any new features.

Good technical due diligence is a structured risk assessment. The goal is not to produce a perfect grade for the codebase. The goal is to answer: what will it cost, in time and money and risk, to operate and evolve this system over the next 18 months?

What you’re actually assessing

Technical due diligence covers several distinct layers, and conflating them produces incomplete assessments.

Code quality and architecture — can engineers who don’t know this codebase understand and modify it? Is the coupling between components high or low? Is there a recognizable pattern (MVC, hexagonal, microservices) or does the structure suggest each developer added code wherever they had access?

Test coverage and reliability — can the team make changes with confidence? This is not just about test percentage. 90% coverage on only the happy paths is not the same as 40% coverage on the business-critical paths. More useful: what does the CI pipeline block on, and what has it let through?

Security posture — are credentials handled correctly? Are dependencies free of known exploits? Are there obvious injection surfaces? Has there been a previous incident that wasn’t disclosed?

Infrastructure and operations — what does the system cost to run, what does it cost when it breaks, and what is the team’s capacity to respond? Are there runbooks? Is on-call rotated or does one person carry all the load?

Team and knowledge — if the lead developer left tomorrow, how much operational knowledge leaves with them? Is documentation current? Can the system be reasoned about from artifacts alone, or does understanding it require interrogating the people who built it?

Dependencies and licensing — what third-party software is the system built on, and what are the licensing obligations? Any open-source licenses with viral clauses (GPL) that could complicate commercialization?

The documents to request before you start

Before touching code, ask for:

1. Architecture diagram — even a rough one. The gap between the actual architecture and what someone describes in a conversation is often informative.
2. Three months of production incidents — not a summary, the actual incident records. How many incidents per month? Mean time to recovery? Patterns in root causes?
3. Current infrastructure bill — broken down by service. A $2,000/month AWS bill is very different from a $20,000/month bill.
4. Dependency inventory — a list of all external services the system depends on (third-party APIs, SaaS tools, payment processors) and what happens when any of them goes down.
5. Offboarding documentation — if someone has left the team in the last year, ask what documentation they were able to leave behind. The quality of departure documentation tells you a lot about documentation culture overall.

If any of these don’t exist, note that in your assessment. Absence of documentation is data.

The code walk-through

Have the team walk you through the codebase. Do not just read it yourself. The walk-through reveals:

• Whether they can explain architectural decisions or only describe what the code does
• Whether there are “this area is complicated, don’t touch it” warnings — and why those areas exist
• Where the technical debt is concentrated (every codebase has some — knowing where it lives matters more than how much there is)
• Whether the team has a shared mental model of the system, or whether different people have different (and possibly contradicting) understandings of how it works

Ask during the walk-through: “Show me the last feature you added. Walk me through where the code lives and what you had to change.” A team that added a feature cleanly in three well-scoped files tells you something different from a team where adding a feature touched 12 files across six layers.

Security checks that matter most

For most assessments, security checking doesn’t require a full penetration test. The highest-return checks:

Git history for secrets — run git log -S "password" --all and similar searches on any repository you’re reviewing. Credentials committed to Git history, even if “deleted,” are permanently accessible. This is a deal-breaker.

Dependency vulnerability scan — run npm audit, pip-audit, or an equivalent on the dependency files. Unresolved critical CVEs in production dependencies without a documented remediation plan are serious.

Authentication and authorization — can a logged-in user access another user’s data by changing an ID in the URL? Can a low-privilege user perform admin operations by knowing the endpoint? Test these manually on a staging environment.

Data storage — are passwords hashed with a proper algorithm (bcrypt, argon2, scrypt) or stored as MD5 hashes or, worse, plaintext? Is PII encrypted at rest or just in transit?

For any system handling payments or health data, the security assessment needs to be more thorough than this. But these four checks catch the most common deal-killers.

What the tests tell you

Test coverage percentage is a weak signal. What matters:

Does the CI pipeline run tests, and does a test failure block a deploy? If tests exist but can be skipped in a merge, they are not a reliability mechanism — they are documentation.

Do the tests cover the system’s actual contract (inputs and outputs of APIs, business rules, data integrity) or just implementation details (did this internal function get called with these args)?

Can the tests run in an isolated environment, or do they require production credentials and live external services? Tests that can’t run in CI without human intervention are not a safety net.

The absence of tests is not automatically a deal-breaker. The cost to add tests to a well-structured codebase can be estimated. The cost to add tests to a spaghetti codebase of unknown behavior is not estimable — that’s the actual problem.

Infrastructure assessment

This is where many due diligence efforts stop short. Review:

Backups — are database backups being taken, and has anyone tested a restore recently? A backup that has never been tested is a hypothesis, not a safety net.

Scaling limits — what happens at 10x current load? Is the architecture horizontally scalable (add servers) or is it constrained by a single large instance that requires vertical scaling (more expensive servers)?

Single points of failure — is there a component whose failure takes down the whole system? Is there a plan for that failure?

Cost scaling — as the system grows, does the infrastructure cost scale linearly with usage, or are there expensive step-functions (a dedicated database server that costs $1,000/month regardless of usage, paid background job workers)?

What to do with the findings

Organize findings into three buckets:

Deal-killers — things that cannot be priced, represent undisclosed liability, or would require immediate remediation regardless of other factors. Examples: committed secrets, no data backups, undisclosed security breach.

Quantifiable technical debt — things that are expensive but scoped. Estimate the engineering cost to remediate over 12 months. Add that to your cost model.

Acceptable technical debt — things that are suboptimal but don’t create risk or block development. Document them as known debt, not surprises.

Then make the decision based on the deal-killers list and the technical debt cost model, not on a subjective “the code quality seems okay” impression.

Agencies and technical teams who do this systematically can take on legacy projects with eyes open. Those who skip it tend to take on projects whose actual cost is revealed only after the commitment is made. Our guide on how to write a technical proposal that wins agency work covers the flip side — what clients actually need to see before they commit to you.