Technical due diligence on an AI-built product rarely turns on whether AI wrote the code. It turns on whether your team can explain, test and maintain what the AI wrote. Investors and acquirers look harder at three things in a product built largely with AI coding tools: who understands the code, what the tests prove, and where code and licences came from.
This guide explains what technical due diligence covers, what investors check, which red flags they look for, and how to prepare before the data room opens. For the wider picture of shipping AI-built products safely, start with our founder’s guide.
TL;DR
Technical due diligence is the independent check an investor or acquirer runs on your product’s code, architecture, infrastructure, security, data handling, IP and engineering team before a deal. For an AI-built product, the reviewers ask one extra question throughout: does this team own its code, or only operate it? Findings feed directly into price, warranties and closing conditions.
- What investors check: Technical due diligence covers six areas: architecture, code ownership and licences, security and personal data, infrastructure, testing, and team knowledge.
- AI-built red flags: The red flags in an AI-built codebase are suppressed errors, duplicated code, tests written alongside the code, secrets in the repository, open database access and knowledge held by one person.
- How to prepare: Preparation takes four steps before the data room opens: inventory, independent review, fixing deal blockers, and documenting evidence.
What technical due diligence is, and what it is not
Technical due diligence is an expert evaluation of a company’s product technology, commissioned by an investor or acquirer before a deal. It covers the code, architecture, infrastructure, security, data handling and the engineering team that maintains them. It usually runs during exclusivity, after both sides sign a letter of intent (LOI): a non-binding agreement on the main deal terms.
Technical due diligence is often confused with two narrower checks. Table 1 shows the difference.
| Type | What it examines | Typical question |
|---|---|---|
| Technical due diligence | The product: code, architecture, infrastructure, security, data, IP and team | Can this product scale, and can this team keep building it? |
| IT due diligence | Internal systems such as finance, CRM and office IT | Can the company’s back-office systems support the business after the deal? |
| Cyber due diligence | Security posture only | What security risks and past incidents come with this company? |
Who commissions the review also matters. In buyer-side due diligence, the buyer pays for an assessment to test the target. In vendor due diligence, the seller commissions a review first and shares it to speed up the process. A seller-side review makes sense when the product was built quickly or largely with AI tools and you expect a technical buyer.
Technical due diligence is also not vendor selection. Checking an outsourcing partner before you sign is covered in our guide to outsourcing due diligence.
Why an AI-built product gets a closer look
Investors do not mark down a product for using AI tools; they mark down code nobody can explain. In an AI-built product, the reviewer’s question shifts from “is the code good?” to “does this team own its code?”
Three patterns explain the extra attention. AI tools produce almost-right code that passes shallow tests but fails on edge cases. Each prompt starts with a fresh context, so the same function often exists in several versions. And tests generated in the same session as the code tend to confirm the AI’s assumptions instead of challenging them. Licence provenance adds a fourth question: where did each snippet come from, and under which terms?
None of these patterns blocks a deal on its own. They become expensive when the reviewer finds them first, because each one turns into a price adjustment, a specific warranty or a condition to fix before closing. The founder who can show the evidence in advance keeps control of that conversation.
What investors check: six areas
Every technical due diligence covers six areas, and in an AI-built product each one has a typical red flag. Table 2 pairs each area with the evidence that answers it.
| Area | What the reviewer asks for | AI-built red flag | Evidence that answers it |
|---|---|---|---|
| Architecture and maintainability | Architecture overview, main components, known technical debt | Same logic duplicated across modules; no structure a new engineer can follow | Architecture diagram, debt register, refactoring plan |
| Code ownership, IP and licences | Repository ownership, contributor agreements, dependency licences | Unclear origin of snippets; copyleft licences in the dependency tree | Licence report, IP assignment from every contributor, AI tool terms |
| Security and personal data | Security review, access control, data flows, incident history | Secrets in the code; no access rules on the database | Independent review with remediation status, record of processing |
| Infrastructure, deployment and recovery | Hosting, deployment process, backups, running costs | Manual deploys; no tested restore; unclear model and API costs | Deployment description, restore test, cost overview |
| Testing and quality | Test coverage, CI pipeline, error monitoring | Tests written in the same session as the code; suppressed errors | Coverage summary, reviewed test plan, error logs |
| Team and knowledge | Who maintains what, documentation, key-person risk | Only one person, or only the AI tool, can explain billing and authentication | Knowledge map, walkthrough by a second engineer |
Code ownership deserves a closer look. A copyleft licence, such as the GPL, lets you use open-source code on one condition. When you distribute software that includes it, you release your own source code under the same licence. The GNU AGPL extends that duty to software people use over a network. An AI tool can copy such code into your product without flagging it, so reviewers scan the dependency tree, the full list of libraries your product relies on. They also read the AI tool’s terms of service on output ownership. The ownership question itself is covered in who owns code written by AI.
For security and personal data, investors measure the product against named yardsticks. GDPR Article 32 requires security measures appropriate to the risk, and ISO/IEC 27001:2022 is the management-system standard many reviewers reference. Running costs belong in the infrastructure area as well: model and API usage fees are part of the unit economics an investor tests.
The team-and-knowledge area decides more AI-built deals than code style does. Prepare that one first.
Technical due diligence questions to expect
Most technical due diligence questions fall into the six areas, and the ones below catch AI-built products most often. Each comes with what a good answer contains.
- Which parts were generated with AI tools, and how was that code reviewed? An honest estimate, plus the review step every change passed.
- Who can explain the authentication and billing code without the AI tool? A named engineer who can walk a reviewer through it.
- What do your tests cover, and who wrote them? Coverage of the critical flows, and tests reviewed by someone other than the code’s author.
- Which open-source licences are in the dependency tree? A generated licence report with any copyleft licence explained.
- Where does personal data live, and who can access it? A data map and an access list for production systems.
- How do you deploy and roll back? A repeatable pipeline and a rollback you have tested.
- Which secrets exist, and how are they managed? A secrets manager, no keys in the code or its history.
- What happens if the founder or the main freelancer leaves? Documentation and a second person who knows the critical modules.
- Which AI models or APIs does the product call, and on which terms? A list of providers, data terms and monthly usage.
- Has an independent party reviewed the code? A recent report with findings and remediation status.
Reviewers also use AI tools to scan repositories for dependencies, secrets and duplication. They do not accept an AI-generated report as the assessment itself. Investors pay for a named human reviewer who can defend each finding.
Investors trust findings you found first. An independent review of your AI-built product gives you evidence, a prioritised fix list and documentation you can put in the data room.
→ See what an AI-built product review covers
Red flags in an AI-built codebase, and the evidence that answers them
Six red flags appear most often when reviewers examine an AI-built codebase. Each has a specific piece of evidence that settles it, as Table 3 shows.
| Red flag | Why a reviewer cares | Evidence that settles it |
|---|---|---|
| Suppressed errors (lint rules disabled, empty catch blocks) | Failures happen silently in production | Re-enabled checks, error-monitoring logs |
| Duplicated utilities and dead code | Every change must be made in several places | Refactoring record, clean static-analysis report |
| Tests created together with the code | Tests confirm assumptions instead of behaviour | Independent test review, tests for known edge cases |
| Secrets in the repository history | Keys may already be exposed | Rotated keys, history scan, secrets manager in use |
| No access rules on the database | Any user may read other users’ data | Access-rule review, results of an authorisation test |
| One person holds all knowledge | The product stalls if that person leaves | Knowledge map, recorded walkthroughs, second maintainer |
Any red flag in authentication, payments or personal data is a fix-before-close item. Style issues are not.
How to prepare: four steps before the data room opens
Prepare for technical due diligence before you sign a letter of intent, because fixes made during exclusivity happen under deal pressure. Four steps cover it:
- Inventory. List the code repositories, dependencies and licences, data flows, and every AI tool and model the product uses.
- Independent review. Commission an AI code audit so you see the findings before the investor does.
- Fix the deal blockers. Resolve issues in authentication, payments, personal data and secrets first.
- Document the evidence. Put reports, remediation status and the results of a production readiness review in the data room.
Commission a pre-due-diligence review yourself when the product was built fast with AI tools or by one developer. Skip it when a recent independent audit exists and your team can walk a reviewer through the code.
Technical due diligence checklist for your data room
A technical due diligence checklist for an AI-built product lists the documents an investor expects to find in the data room:
- architecture overview and diagram
- dependency and licence report
- list of AI tools and models used, with their terms
- security review or audit report, with remediation status
- record of processing (GDPR Article 30) and processor agreements (Article 28)
- data-breach log
- deployment, backup and recovery description
- test coverage summary
- access list for production systems
- team and knowledge map
- EU AI Act role statement (provider or deployer) if the product contains AI features
- note on whether the NIS2 Directive applies to your company
What findings do to the deal
Technical due diligence findings change deal terms in five general ways. The investor or acquirer can lower the price or ask for a specific warranty or indemnity. They can hold back part of the price in escrow, money parked with a third party until conditions are met. They can also set a condition to fix before closing, or walk away. Which mechanism applies depends on the severity of the finding and the negotiation, and your lawyer advises on the terms themselves.
The pattern founders can control is who finds the problem. A finding you discovered, fixed and documented yourself rarely moves the price. The same finding discovered by the investor’s reviewer raises a second question: what else has not been found?
How Sunbytes prepares AI-built products for due diligence
Investors are not checking whether a human typed every line; they are checking whether your team can explain, maintain and secure what was built. An AI-built product review from Sunbytes produces that evidence. The review is independent of any remediation work, so its findings carry weight with investors.
Software engineers and security specialists review the product together. You receive findings with the evidence behind each one, a prioritised action plan and a technical handoff, explained in plain English rather than as a scanner export. Sunbytes works under an ISO/IEC 27001:2022-certified ISMS with Dutch-led governance, and has delivered 300+ projects over 15+ years.
Every product and deal differs, so the scope is agreed case by case. Talk to us about a review before your round or sale reaches the letter of intent.
