Technical due diligence for AI-built products
A product put together in a month with an AI assistant can look as mature as one that took years to build. Technical due diligence is there to spot the difference before the deal, not after it.
In short
A standard technical review looks at code, architecture, security, team, licenses and infrastructure. For a product built with AI, six questions are added: who owns the code, which licenses came in with the dependencies, whether the server enforces data access, how tied the product is to the platform it was built on, what AI costs per user and whether anyone understands the system without the assistant. The output is not a good or bad grade but a register: what to fix, what it costs, and what belongs in the deal terms.
What any technical review covers
- Code quality and tests: can the system be changed without breaking it?
- Architecture and scaling: will it support the growth plan in the business plan.
- Security: known vulnerabilities, handling of secrets, access control.
- Team: who knows the system, and what happens if that person leaves.
- Licenses and intellectual property: what can be sold.
- Infrastructure and operations: what it costs to run, how changes are shipped.
That is the baseline. Here is what changes when the code was written by AI.
Six questions specific to AI
1. Who owns the code
The US Copyright Office, in its report on copyrightability, concluded that AI output is protected only where a human determined enough of its expressive elements, and that prompts alone are not sufficient. Using AI within human work does not remove protection. For a deal, this means code that was generated and not reworked by people may be an asset with unclear rights. We check what share of the code was substantially edited by people and how that is reflected in the repository history.
2. Which licenses came with the dependencies
According to Black Duck's report on open source in commercial software, open source is present in almost every audited codebase, and license conflicts appear in more than half, with a notable share coming through transitive dependencies. An AI assistant adds packages quickly and does not check the license. We review the full dependency list, including transitive ones, and look for packages that do not exist or have been abandoned.
3. Does the server enforce data access
The most common defect in AI-written code is this: permissions are checked in the interface while the server executes any user's request. For a buyer, this is not technical debt but a data breach risk that may surface after closing. We check access to each table and test attempts to read other users' records.
4. How tied the product is to its platform
A product built in Lovable or Bolt often depends on a combination of the platform, Supabase and several cloud services. The question is whether it can be built from the repository without the platform, who owns the accounts, and what happens if the platform changes its terms.
5. What AI costs per user
If the product calls models itself, it has a cost of goods that ordinary SaaS does not: every user request costs money. We check how many calls a typical session makes, whether there are limits and caching, and whether that matches the subscription price in the business plan.
6. Does anyone understand the system
In a product built with AI, the team may consist of the founder and the assistant. We check whether someone can explain why the system is built the way it is, find the cause of a failure and ship a fix. If not, that is the first item in the post-deal plan.
What the investor or buyer receives
| Report section | Contents |
|---|
| Risk register | Each defect found, its consequences and the approximate effort required to fix it |
| What belongs in the deal | Conditions before closing, seller warranties, items to reflect in price or a deferred payment |
| First hundred days plan | Order of fixes: first what cannot be fixed after the fact (leaks, access, backups) |
| Dependency map | Platforms, cloud services, AI providers, licenses |
The report is written for the person making the financial decision, not for a developer: every item is stated as a risk and its cost, not as a code review comment.
How the review runs
- Read access to the repository, a list of services and accounts, a product description and the growth plan.
- A conversation with whoever built the system: how it works, what the AI did, what people did.
- Review of code, dependencies, data access and infrastructure.
- Report and walkthrough with the investor or buyer.
Access to the production database with customer data is not needed. Keys and passwords are not requested.
Frequently asked questions
How is due diligence for an AI product different?
On top of the usual questions about code, architecture and team come ownership of AI-generated code, licenses of automatically added dependencies, server-side data access checks, platform lock-in, the cost of model calls and whether a person understands the system without the assistant.
Is AI-written code owned?
In the US Copyright Office's view, AI output is protected only where a human determined enough of its expressive elements; prompts alone are not enough. So what matters is how much of the code people substantially reworked. The final conclusion on rights is a lawyer's; the review gives the lawyer facts from the repository.
Can the product be reviewed without access to customer data?
Yes. Read access to the repository, a list of services and a test environment or an ordinary user account are enough. Production keys and passwords are not needed.
What do these reviews find most often?
Permissions enforced only in the interface, secrets in code or repository history, dependencies with incompatible licenses, no tested backup, and a system understood only by the founder together with an AI assistant.
Who orders the review?
Usually the investor or buyer before a deal. Sometimes the founder before a round: finding and closing problems before someone else's review finds them is cheaper.
SLAtech LTD