Forty-five percent of AI-generated code samples fail basic security tests, and one in five references a package that does not exist (Cloud Security Alliance). In 2026 a meaningful share of every codebase you might acquire, invest in, or take over from a previous vendor was written that way, often by a founder who cannot tell you which parts. Technical due diligence used to be about finding the messy corners of a codebase. It is now about finding out whether anyone understands it at all.
We run technical due diligence for acquirers, investors, and companies inheriting a product from an agency that has gone quiet. This post is the checklist we use: 30 checks across six areas, a scoring rubric that turns findings into a price or a plan, and the five findings that most often change a deal. It is written for the person commissioning the review, so you know what a good one covers and can tell when a "code audit" is a two-hour skim with a logo on it. It does not cover legal, financial, or commercial diligence, which run alongside and share findings with this one.
What is technical due diligence?
Technical due diligence is a structured review of a software product's code, architecture, infrastructure, security, data, and engineering team, carried out before a transaction or handover, to establish what the product actually is, what it will cost to keep running and to change, and what risks the buyer is taking on. Its output is a written report with a risk-rated findings list, a remediation estimate, and a clear answer to the question that matters: can this system support the plan the price assumes?
When do you need it?
- Acquiring a company or a product. The code is a large part of what you are paying for. Diligence turns "we have a platform" into a verified asset with a known maintenance bill.
- Investing. A seed or Series A cheque increasingly funds a product built fast with AI tools. You are pricing whether it can survive the growth the round is supposed to buy.
- Inheriting from a vendor. The previous agency is gone, unresponsive, or being replaced. Before a new team commits to a roadmap, someone has to establish what they are standing on.
- Before a modernization decision. Choosing between wrapping, refactoring, or rebuilding a system depends entirely on what diligence finds. We covered that decision in legacy system modernization.
The 30-point technical due diligence checklist
Each check is rated Critical, Major, or Minor when it fails. Critical findings change the price or the decision. Major findings go into the first 90-day plan. Minor findings are noted and priced.
Area 1: Code and architecture
| # | Check | Failing looks like | Severity if failing |
|---|---|---|---|
| 1 | Architecture matches the description given to the buyer | "Microservices" is one deployable with folders | Major |
| 2 | Test coverage on revenue-critical paths | No automated tests on signup, billing, or core workflow | Critical |
| 3 | Build is reproducible from the repository | Deploys depend on a laptop or undocumented steps | Critical |
| 4 | Dependency health | Unpinned versions, abandoned packages, unresolved critical CVEs | Major |
| 5 | Provenance of AI-generated code | Large modules nobody on the team can explain; hallucinated packages in the manifest | Major, Critical if in auth or payments |
| 6 | Duplication and dead code | Same logic in four places; features behind flags nobody remembers | Minor |
Area 2: Security
| # | Check | Failing looks like | Severity if failing |
|---|---|---|---|
| 7 | Secrets management | API keys and database passwords in the repository or client bundle | Critical |
| 8 | Authorization enforced server-side | Access control checked only in the UI; users can reach other tenants' data by changing an ID | Critical |
| 9 | Input validation and injection defenses | Raw SQL with string concatenation; no validation on file uploads | Critical |
| 10 | Encryption in transit and at rest | Plain HTTP internally; unencrypted backups; PII in logs | Major |
| 11 | Static analysis and dependency scanning in CI | None, or results ignored | Major |
| 12 | AI features: prompt injection and tool permissions | An agent with write access to production data and no approval gate | Critical |
Area 3: Infrastructure and operations
| # | Check | Failing looks like | Severity if failing |
|---|---|---|---|
| 13 | Infrastructure defined as code | Servers configured by hand; nobody can rebuild the environment | Major |
| 14 | Backups exist and a restore has been tested | Backups configured, never restored | Critical |
| 15 | Monitoring, alerting, and error tracking | Outages discovered by customers | Major |
| 16 | Cloud spend understood and bounded | No cost allocation; AI inference costs unmetered | Major |
| 17 | Single points of failure documented | One database, one region, one person with root | Major |
| 18 | Account ownership | Cloud, domain, and app-store accounts in a founder's or vendor's personal name | Critical |
Area 4: Data
| # | Check | Failing looks like | Severity if failing |
|---|---|---|---|
| 19 | Schema integrity | No foreign keys or constraints; duplicates and orphans in production data | Major |
| 20 | Migration system | Schema changes applied by hand in production | Major |
| 21 | Personal data inventory and retention | Nobody can say where PII lives or how to delete a user | Critical in regulated sectors, else Major |
| 22 | Third-party data terms | Data sent to AI vendors or analytics tools without contractual limits | Major |
Area 5: Product and delivery
| # | Check | Failing looks like | Severity if failing |
|---|---|---|---|
| 23 | Documented change velocity | Commit history shows features taking months; hotfix-to-hotfix cadence | Major |
| 24 | Roadmap feasibility on current architecture | Planned features require rewrites the plan does not budget | Critical if the price assumes the roadmap |
| 25 | Performance under expected load | No load testing; known collapse at a user count the plan exceeds | Major |
| 26 | Accessibility and platform compliance | App-store rejections pending; no accessibility baseline in regulated markets | Minor to Major |
Area 6: Team and knowledge
| # | Check | Failing looks like | Severity if failing |
|---|---|---|---|
| 27 | Bus factor | One person understands the core; they are not staying | Critical |
| 28 | Onboarding time for a new engineer | Weeks to a first meaningful change; no runbooks | Major |
| 29 | IP and contributor agreements | Contractors or previous vendors never assigned copyright; open-source licence conflicts | Critical |
| 30 | Engineering practices | No code review, no branching model, no release process | Major |
How to run technical due diligence in two weeks
- Days 1 to 2: access and inventory. Read access to all repositories, cloud consoles, CI, monitoring, and documentation. List every service, environment, third-party dependency, and account. Check 18 (account ownership) is answered on day one; it is the finding most often hidden.
- Days 3 to 5: automated sweep. Run dependency scanning, static analysis, secret detection, and licence scanning across every repository. Pull the commit history into a timeline of velocity and contributors. Provision a fresh environment from scratch to test reproducibility (check 3).
- Days 6 to 8: manual review of the paths that matter. Read the code for authentication, authorization, billing, and the core workflow end to end. This is where checks 2, 5, 8, 9, and 12 are decided, and it cannot be automated. Trace one real request through every layer.
- Days 9 to 10: interviews. Two hours each with the lead engineer, whoever runs production, and whoever owns the product. Ask them to explain the module the automated sweep flagged as least-touched and most complex. Hesitation is data.
- Days 11 to 12: restore and load. Restore a backup into a clean environment (check 14). Run a load test at twice current peak. Both frequently fail and both are cheap to try.
- Days 13 to 14: score, price, and write. Rate every finding, estimate remediation in engineer-weeks, and produce the report with a one-page summary the deal team will actually read.
Turning findings into a number
A findings list is not a decision. The report has to answer "what does this cost and does it change the deal?" We use a simple rubric that maps severity counts to a remediation estimate and a recommendation.
| Profile | Typical findings | Remediation estimate | Recommendation |
|---|---|---|---|
| Sound | 0 Critical, 0 to 3 Major | 2 to 6 engineer-weeks | Proceed; fold remediation into the first quarter |
| Investable with conditions | 1 to 2 Critical, 4 to 8 Major | 8 to 20 engineer-weeks | Proceed with price adjustment or escrow; Critical items fixed before close or within 90 days |
| Rescue required | 3 or more Critical, or any Critical in auth, payments, or account ownership unresolved | 20 to 40 engineer-weeks, or a partial rebuild | Renegotiate or walk; if proceeding, treat the first six months as a rescue, not a roadmap |
Engineer-weeks convert to money at the rates in your market. Using blended offshore senior rates we see in 2026, the "investable with conditions" band prices at roughly $30k to $90k of remediation; the rescue band at $80k to $200k or a partial rebuild. Our AI-generated app rescue playbook lays out what the rescue sequence looks like when the diligence says so, and the hidden cost of cheap software explains why the remediation bill so often exceeds what the original build cost.
The five findings that change deals most often
- Accounts in the wrong name. Cloud, domain, and app-store accounts owned by a founder or the previous agency. Cheap to fix before close, nearly impossible after a dispute. Make transfer a closing condition.
- Authorization only in the UI. Tenant data reachable by changing an ID in the URL. Common in fast-built SaaS, and a breach waiting for a customer to notice. Critical, and the fix touches every endpoint.
- Untested backups. Configured, never restored, and in one case we reviewed, silently failing for eleven months. A ten-minute restore test is the highest-value hour in the whole review.
- Unassigned IP. Contractors or agencies that never signed an assignment. Your contract checklist for the go-forward vendor should make assignment on payment explicit; diligence checks whether the previous ones did.
- One person. A single engineer who understands the core and has already decided to leave. No amount of code quality survives that; the remediation is a knowledge-transfer program with a deadline, budgeted before close.
What "AI-generated" changes about the review
Nothing in the checklist is new because of AI, but the weighting has shifted. Check 5, provenance, used to be a curiosity. It is now a primary risk indicator, because AI tools produce confident, well-formatted code that passes a skim and fails under adversarial input, and because the Stack Overflow 2026 survey shows 84% of developers use these tools while only 3% highly trust the output (Stack Overflow survey summary). One Hacker News commenter put the inheritance problem precisely: "There will be an entire new industry of people who vibed 1000 lines of MVP and now are stuck with something they can't debug" (Hacker News). Diligence is how you avoid paying full price to join that industry.
The practical adjustment: spend the manual-review days on the paths where a plausible-looking bug costs the most, which are authentication, authorization, payments, and any AI agent with write access. The controls we expect to find on that last one are in our AI agent security checklist, and the broader baseline for any web product is in web application security for business owners.
Frequently asked questions
How much does technical due diligence cost?
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.
How long does technical due diligence take?
Two weeks for a typical SaaS or mobile product, assuming access is granted on day one. Larger estates with many services or a regulated data footprint take three to four weeks. A "code audit" delivered in two days is a skim, not diligence.
What is the difference between a code audit and technical due 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.
Can technical due diligence be done without source code access?
Not properly. Interviews, documentation, and a demo establish claims; the code establishes facts. If a seller will not grant read access under NDA, treat that refusal as a finding in itself.
What should the report contain?
A one-page summary with the overall profile and recommendation; a findings list rated Critical, Major, and Minor with evidence; a remediation estimate in engineer-weeks and money; a 90-day plan for the Critical and Major items; and an appendix with the automated scan results. If the report does not put a number on remediation, it is not finished.
Key takeaways
- Technical due diligence answers one question: can this system support the plan the price assumes? Everything else is evidence for that answer.
- Thirty checks across code, security, infrastructure, data, delivery, and team. Critical findings change the price; Major ones fill the first 90 days.
- The five findings that most often change deals are account ownership, UI-only authorization, untested backups, unassigned IP, and a single key person.
- AI-generated code has raised the weight of provenance. Spend manual review time on auth, payments, and any agent with write access.
- A two-week review costs under 1% of most transactions and routinely finds remediation worth ten times its fee.
- A report without a remediation number and a 90-day plan is a findings list, not diligence.
Know what you are buying before you pay for it
If you are about to acquire, fund, or inherit a software product, tell us what it is and when you need an answer. We will scope a two-week review against the 30 checks above, with a fixed fee, and deliver a report that prices the remediation. If the system is sound, you will have the evidence to proceed with confidence. If it is not, you will know before the money moves, which is the entire point of our custom software development team doing this work.