Technical Due Diligence: The Twelve Things I Check First

TL;DR

• Technical due diligence is a structured review of code, architecture, infrastructure, security, data, and team — not a vibe check on whether the stack sounds modern.
• The order below is ranked by how often each item turns out to be the actual problem, not by how dramatic it sounds.
• Hardcoded secrets and dependency vulnerabilities surface in almost every review; architecture mismatch is rarer but more expensive when it appears.
• AI-generated code has added a new layer of risk: code that functions well enough to ship but fails a security audit or cannot be understood by anyone who did not write it.
• If you want someone to run this review before a hire, an acquisition, or a funding round, the fractional CTO engagement is where that work lives.

---

Most technical due diligence reviews I have read focus on what sounds important rather than what actually surfaces problems. Architecture gets top billing because it is conceptually interesting. Secrets management gets buried because it sounds like housekeeping. In practice, the ordering is almost the reverse.

This is not a comprehensive framework. It is the twelve things I look at first, in the order I look at them, because they are the ones most likely to change the picture before I get to anything else.

Why does the order matter?

Because time is limited and findings are not independent. A codebase riddled with hardcoded secrets tells you something about the engineering culture that makes every other finding more or less credible. Finding that the entire product runs on one engineer's personal AWS account tells you the infrastructure section will be uncomfortable before you open it.

Since 2024, AI coding tools have become a standard part of how software gets built. An estimated 41% of all new code is now AI-generated, with 85% of professional developers using AI coding tools regularly. That code often functions well enough to ship, but it does not always function well enough to scale, survive a security audit, or make sense to a team that did not write it. The gap between "it works" and "it is well-built" has widened considerably. That gap is exactly what this kind of review is meant to measure.

The twelve checks, ordered by frequency of finding something real

1. Hardcoded secrets and git history

Run gitleaks or trufflehog against the full git history, not just the current branch. GitGuardian's State of Secrets Sprawl 2026 report documented 28.65 million new hardcoded secrets in public GitHub commits during 2025, a 34% year-over-year increase representing the largest single-year jump ever recorded. Detection alone is not closing the gap: 64% of secrets confirmed as valid in 2022 were still active and exploitable in 2026. The fix is rotation, not deletion. GitGuardian's 2026 report found that AI-assisted commits leak secrets at a 3.2% rate, roughly 2x the baseline.

2. Dependency vulnerabilities

Run npm audit, pip-audit, or Snyk against every service. The question is not just whether vulnerabilities exist — they almost always do — but whether anyone is watching them. A lockfile that has not changed in eighteen months on an actively maintained product is a signal. Automated tools like Snyk for dependency vulnerabilities and SonarQube for static analysis should run before manual code reviews. Automated scans detect 70% more vulnerabilities than manual reviews alone.

3. Authentication and access control

Who can do what, and can you prove it? Check for broken object-level authorization (BOLA is still the most common API flaw in the OWASP API Top 10), missing rate limiting on auth endpoints, and whether admin routes are protected by anything beyond a frontend check. Also check who has production access and whether credentials are long-lived or federated through an identity provider.

4. Infrastructure ownership and key-person risk

IP diligence and infrastructure ownership confirm that the buyer is actually acquiring the technology it thinks it is. This is one of the few areas where small gaps can quickly become big problems. Check whether cloud accounts are owned by the company or a founder's personal email. Check DNS registrar and SSL certificate ownership. Specifically: who owns the code, whether the company (not individuals) owns the core software, whether employee and contractor agreements exist, and whether IP has been properly assigned.

5. Environment separation and secrets injection

Is there a staging environment meaningfully different from production? The foundational rule is that no secret value should ever appear in source code, pipeline YAML, Dockerfile, or any artifact committed to version control. The correct pattern is runtime injection: the pipeline requests credentials from a secrets manager at the moment they are needed, receives a short-lived value, and uses it for that step only.

6. CI/CD and deployment pipeline

What does a deploy actually look like? Can anyone trigger one, or is there a gated process? Is there a rollback path, and has it been tested? A monorepo where one broken commit takes down three services with no automated rollback is a runtime risk that does not appear in the code itself.

7. Observability: logs, metrics, and alerting

The absence of structured logging is a reliable indicator that the team has never had to debug a production incident under pressure. Check whether errors are surfaced in Sentry or a similar tool, whether uptime alerts exist, and whether logs are queryable. A product with no observability cannot be safely operated by anyone other than the person who built it.

8. Open-source license compliance

Open-source usage needs scrutiny: whether licenses are understood and compliant, and whether any third-party dependencies limit future use or transfer. A GPL-licensed dependency inside a commercial product sold as proprietary software is a genuine legal exposure. Run a license audit with license-checker or FOSSA. This check is quick and the findings can be material.

9. Data architecture and compliance posture

Where does user data live, who can access it, and what regulations apply? GDPR, HIPAA, and PCI-DSS each carry technical requirements that go beyond a privacy policy. Check whether PII is encrypted at rest, whether access logs exist, and whether there is a documented data retention and deletion process. For the healthcare project PSI Nest, this was a primary design constraint from day one — that is the right order.

10. Test coverage on critical paths

Overall coverage percentages are a vanity metric. A product with 80% coverage but zero tests on the payment flow or the authentication layer is more dangerous than one with 40% coverage on the right paths. Ask for coverage reports and look at what is actually tested. Code clarity, test coverage, dependency management, and development standards determine long-term maintainability and how much risk sits in onboarding new engineers to the codebase.

11. Architecture and scalability

This check is listed eleventh not because it is unimportant but because it is the one most often over-weighted. The software architecture has to align and enable the business strategy. A broken or inadequate architecture, or one riddled with technical debt, can be a severe handicap to the organisation and investment. The question is not whether the architecture is elegant but whether it can support the business plan for the next 24 months without a full rewrite.

12. Documentation and knowledge transfer risk

Look for runbooks, architecture decision records, and onboarding documentation. Their absence is not a blocker but it adds an overhead cost that belongs in the remediation estimate. If the answer to any operational question depends entirely on one engineer being available, that is a finding.

How do these checks map to deal risk?

Check	Typical finding	Deal impact	Remediation cost
Hardcoded secrets	Live credentials in git history	Immediate security risk; may be material	Low (rotation) to medium
Dependency CVEs	Critical unpatched packages	Price chip or remediation credit	Low to medium
Auth and access control	Missing BOLA checks, no rate limiting	OWASP-class security exposure	Medium
Infrastructure ownership	Personal accounts, no IAM	May block transfer	Medium
Environment separation	Secrets in .env files, no staging	Operational and security risk	Low to medium
CI/CD pipeline	Manual deploys, no rollback	Velocity risk post-close	Medium
Observability	No structured logging or alerting	Hidden incident history	Low
License compliance	GPL in commercial product	Legal exposure; potential blocker	High if core dependency
Data and compliance	PII unencrypted, no deletion process	Regulatory risk; may require pre-close remediation	High
Test coverage	Zero tests on critical paths	Quality and velocity risk	Medium
Architecture	Undeployable monolith, schema migration risk	Scalability cost; affects valuation	High
Documentation	No runbooks, key-person dependency	Transition risk	Low to medium

What does a real review cost and take?

For a single product with two to six repositories, a two-week review by a senior engineer and a security specialist typically costs $8k to $25k depending on system size and whether a load test and restore test are included. That is usually under 1% of the transaction value and it routinely uncovers remediation costs of ten times its price.

A "code audit" delivered in two days is a skim, not diligence. A code audit reviews code quality and security in isolation. Technical due diligence adds infrastructure, data, delivery velocity, team risk, account ownership, and IP, and maps every finding to a cost and a recommendation for the transaction. The code is one of six areas, not the whole review.

The same review applies outside M&A. Founders preparing for a Series A, teams inheriting a codebase from a previous vendor, and companies onboarding a new engineering lead all benefit from a written picture of what they actually have. That is the context most fractional CTO engagements arrive in: not a transaction, but a handover or a hiring decision. For a related look at when that engagement makes sense versus when it is overkill, see When a Startup Does NOT Need a Fractional CTO.

If the codebase was built heavily with AI tools, the security surface is wider than it looks. The security holes to check in a Lovable or Replit app before launch covers the specific failure modes of that class of codebase. For the production-hardening side of that problem, the AI invoicing SaaS hardening engagement is the relevant receipt.

Most engagements start around $5K; smaller well-scoped work is considered case-by-case.

FAQ

Is technical due diligence only for acquisitions?

No. It is most common before acquisitions and investment rounds, but the same structured review applies any time a new technical decision-maker is taking responsibility for a codebase they did not build. Founders inheriting code from an agency, engineering leads joining an unfamiliar product, and teams preparing for a SOC 2 audit all use the same framework.

How is this different from a code review?

A code audit reviews code quality and security in isolation. Technical due diligence adds infrastructure, data, delivery velocity, team risk, account ownership, and IP, and maps every finding to a cost and a recommendation for the transaction. The deliverable is not a list of code smells; it is a risk-rated report with remediation estimates that a non-technical decision-maker can act on.

What access do you need to run this review?

Read-only repository access covers checks 1, 2, 5, 8, 10, and part of 6. Infrastructure and observability checks require read access to cloud console IAM policies, deployment configurations, and monitoring dashboards. Data and compliance checks sometimes need a call with the engineering team rather than direct system access. Write access to any system is never required.

Can a founder prepare for this review in advance?

Do not wait for a term sheet. Run internal checks using a technology due diligence checklist quarterly. Identify gaps like missing runbooks, undocumented services, or expired certifications. Close gaps proactively. The teams that move fastest through diligence are the ones who have already asked themselves these questions.

What happens if findings are material?

Material findings do not necessarily kill deals. They get priced: as a credit, an escrow holdback, or a remediation milestone tied to a tranche. The review's job is to surface them clearly enough that both sides can negotiate from the same factual base.