Sooner or later, someone serious looks under the hood. An acquirer, an investor or a new technical leader asks for access to the code and starts asking questions.
That is technical due diligence, and most of its questions come down to three things. Can our people maintain this? Is it secure? Does the company actually own it?
None of that changes because AI agents wrote much of the code. What changes is where the gaps tend to hide. Agents write code far faster than anyone writes the documentation, the tests or the record of who decided what. A product can work well and still be hard to hand over.
I have shipped more than 50 platforms over 30 years, and I sold my startup, Stacks, to EBSCO. I have written about what that taught me. Here is how I would get an AI-built product ready for that kind of look.
Put everything in the company's repository
Start with where things live. The code, the documentation and the design files belong in a repository and accounts the company owns, not in a contractor's personal account or on a founder's laptop.
Then close the loose ends a careful reviewer will find:
- An IP assignment from everyone who contributed, including contractors and the friend who helped with the design.
- The licenses of the libraries you depend on.
- The terms of the AI tools you used, and what they say about who owns the output.
One question is new. In January 2025 the US Copyright Office concluded that AI output is protected only where a human author has determined sufficient expressive elements, and that providing prompts is not enough. I am not a lawyer, and this is a question for yours. But it is one more reason to keep a record of what people directed, reviewed and changed.
Show tests and a release process
A buyer wants to know their team can change the product without breaking it. "The AI wrote tests" is not an answer. Tests that run on every change, and block a release when they fail, are.
In practice, that means:
- separate environments for development, testing and live, each with its own database;
- unit and end-to-end tests that run automatically on every change;
- a release checklist a named person signs off;
- a rollback point for every release.
You do not need a particular number of tests. You need a process someone else can see, follow and trust.
Have a security review on file
Security is one of the first things a careful buyer checks, and adding it to a finished product is far harder than building it in.
Have a recent security review and a static code scan, with every finding fixed or explained before anything goes live. Then check the basics a reviewer will look for: no secrets in the code, API keys kept on the server, and data isolation tested rather than assumed.
Make the company own every account and key
A modern product runs on a lot of accounts: the domain, hosting, the database, email, the app stores, analytics and every AI provider. Each one should be in the company's name, paid by the company and held by more than one admin. GitHub, for example, recommends at least two owners on every organization, so no one loses access to a project.
Write down every service, who has access and where each key is stored. When someone leaves, that list should let you remove their access and rotate their keys the same day.
Keep a record of how the code was made
This is the part that is specific to AI. A reviewer can reasonably ask which tools wrote the code, what they were allowed to touch and who checked their work.
The best answer is one you wrote down as you went:
- The rules your coding agents work under, kept in the repository. Mine say no production data, every change through a preview, and evidence for any public claim. I wrote about those rules separately.
- A spec and a log of decisions, including the options you rejected.
- Commit history and reviews that show a person approved each change before it shipped.
I built Mentor Intelligence with AI coding agents that I directed, reviewed and tested. That review is what turns generated code into code a person can stand behind, and a buyer will want to see that it happened.
Remove the dependence on one person
The hardest question in any review is what happens if a key person leaves. With an AI-built product, the risk is a founder who knows which prompts to run and why things are the way they are, with none of it written down.
So move that knowledge into the repository:
- Setup instructions a new engineer can follow on their first day.
- Architecture notes that explain how the pieces fit together.
- Runbooks for the things that go wrong.
- Monitoring that tells someone when the product is unwell, so nobody has to remember to look.
Monitoring can be simple: a daily check that signs in, walks the key pages and sends a plain-English report, and an alarm when a scheduled job stops running. All of this follows the rule I took from selling my startup: avoid depending on one person, including me.
A checklist before anyone asks
- Code, documentation and IP in company-owned accounts, with assignments signed.
- Tests on every change, and a release process with sign-off and rollback.
- A recent security review and code scan, with the findings closed.
- Every account and key listed, in the company's name, with at least two admins.
- Written rules for your coding agents, and a record of who approved what.
- Documentation good enough that the product does not need you in the room.
This is the standard I hold a v1 build to: code, documentation and IP in your repository, automated tests, a security review and your sign-off on every release. It is far easier to build that way from the start than to reconstruct it while a buyer or investor waits.
If someone is about to look under the hood of your AI-built product, email me with what it is and where it is today. I can help you find the gaps before they do.