--- title: "Technical Due Diligence for AI-Generated Codebases: What Investors Check and How to Prepare - George Rios" description: "Investors rarely reject AI-built code outright. They ask whether a human team can maintain it, whether it survives ten times the load, and whether the secrets, tests, licenses and backups are in order. What a technical due diligence reviewer looks at in a Cursor, Claude, Lovable or Bolt codebase, the evidence pack to prepare, and how a 30-day Architecture Discovery produces it." url: https://georgerios.com/articles/technical-due-diligence-ai-generated-codebase author: George Rios --- [ All articles](https://georgerios.com/articles) AI-Built App Audit # Technical Due Diligence for AI-Generated Codebases: What Investors Check and How to Prepare Investors rarely reject AI-built code outright. They ask whether a human team can maintain it, whether it survives ten times the load, and whether the secrets, tests, licenses and backups are in order. Here is what the reviewer looks at, the evidence pack to have ready, and how to produce it in 30 days. Published 2026-10-23 Reading time 8 min Topic AI-Built App Audit Author George Rios **Short answer:** the reviewer is not grading how the code was written. They are deciding whether the thing you built is an asset or a liability that comes with the deal. An AI-generated codebase passes when a human can explain it, run it, change it and scale it, and when the embarrassing things (keys in the repo, no tests, no backup ever restored, a dependency with a license that forbids your use) have been found by you before they are found by them. I have sat on both sides of this: building the platforms being reviewed, and reviewing codebases for acquirers and boards. The questions below are the ones that come up every time, with what "good" looks like for an app that was mostly generated. ## What the reviewer actually checks ### 1\. Can someone other than the builder run it? The first thing a reviewer does is try to get the app running from the repository using only what is written down. If that needs a Slack message to you, the finding is "key-person dependency" and it goes at the top. For AI-built apps the risk is higher than usual, because the knowledge of how the system fits together often lives in a chat history rather than in a README. Good looks like: a new developer, or a new AI session, can clone, configure, run and deploy in a day from the docs alone. ### 2\. Does the architecture survive ten times the load? Reviewers look for the choices that work at a hundred users and fall over at ten thousand: the query that loads every row and filters in memory, the background job that runs in the web request, the single database with no read path, the file uploads stored on one server's disk. They are not asking whether you have built for scale; they are asking whether scaling would require a rewrite. Good looks like a short, honest document that says where the limits are and what the next step is at each one. ### 3\. Secrets, access and data handling Three questions, asked in this order: are there credentials in the repository history, can any user reach another user's data, and what personal data do you hold and where does it get copied. AI-generated code fails the second one more than anything else, because authorization gets written into the screen instead of the server. Good looks like: a secrets scan with zero live findings, authorization enforced in one place on the server and tested with two accounts, and a one-page data map. ### 4\. Tests, and what they actually cover Generated codebases often have many tests that test nothing: assertions that the mocked function was called, snapshot tests that pass whatever renders. A reviewer opens a handful and reads them. Good looks like a smaller number of tests on the paths that make money or lose data: sign-up, payment, permissions, the core workflow, and a test for every bug that has reached production. ### 5\. Dependencies and licenses Every package is pulled into the deal with you. The reviewer runs a vulnerability audit and a license scan, and looks at the handful of packages that handle authentication, payments and file handling by hand. AI tools choose whatever got the task done, which sometimes means an abandoned library or one under a license that is incompatible with a commercial product. Good looks like: an audit with no high findings open, a license report with nothing copyleft in a shipped product, and a named maintainer for anything critical. ### 6\. Operations: monitoring, backups, incidents Can you show the reviewer the last time an error alerted someone, the last time a backup was restored, and what happened the last time production broke? "We have never had an outage" is not reassuring; it usually means nobody would know. Good looks like: an error tracker with alerts, a restore log with a date and a duration, and a short incident history, even if it is two entries. ### 7\. The AI bill and the AI features If the product calls language models, the reviewer will ask what one user costs you per month, what stops a single user or bot from running that cost up, and what happens to user data sent to the model provider. Good looks like per-feature cost figures, rate limits on the expensive paths, and a sentence in your privacy policy that matches what the code does. ### 8\. Ownership and provenance Who owns the code the contractor generated? Did any of it come from a template with its own license? Is the production account in a personal email? These are legal questions with technical evidence behind them. Good looks like: assignment clauses in contractor agreements, accounts in the company's name, and no mystery folders. ## The evidence pack to have ready Reviewers are faster and kinder when you hand them the answers before they ask. This is the pack I build in a discovery: 1. **System map.** One diagram and one page: services, data stores, third-party dependencies, and which account owns each. 2. **Runbook.** How to set up, run, deploy and roll back, written so a stranger could do it. Include the environment variable list with no values. 3. **Security findings and fixes.** The scan results, the authorization test with two accounts, the data map, and what was fixed when. 4. **Dependency and license report.** The audit output and a short note on the critical packages. 5. **Test summary.** What is covered, what is not, and why; a reviewer trusts an honest gap more than a coverage number. 6. **Operations evidence.** Monitoring screenshot, alert history, backup restore log, incident history. 7. **Scale and cost notes.** Known limits, next steps at each, and cost per user including AI calls. 8. **Known issues and plan.** The prioritized list of what is left, with effort. Nothing damages credibility like a reviewer finding an issue that is not on your list. The same pack answers a partner's security questionnaire, which is usually the other place a founder meets these questions for the first time. Most questionnaires are the eight sections above in a spreadsheet. ## How the 30-day Architecture Discovery produces it The [Architecture Discovery](https://georgerios.com/ai-app-audit#process) is built to end with this pack. In the first days I map the system and read the code; then I test the highest-priority gaps hands-on, including the parts a reviewer will test, like restoring a backup and trying to read another user's records; then I write it up as findings with evidence and a verdict, and a plan ordered by what to fix first. The deliverables are the [system map, findings with evidence, prioritized plan and hardening options](https://georgerios.com/ai-app-audit#findings), which map directly onto items one through eight above. A sample report outline, so you know what you would be handing over: 1. Summary and verdict: build on it, or not, in one paragraph. 2. System map and ownership. 3. Findings by area, each graded Critical, Needs work or Pass with the evidence behind it. 4. What was fixed during discovery. 5. Prioritized plan with effort and sequencing. 6. Appendices: scan outputs, test results, restore log, dependency and license report. If the raise is weeks away rather than months, say so on the call. The order of work changes: secrets, authorization and the runbook come first, because those are the findings that stop a deal, and the rest becomes the "known issues and plan" section, which is a perfectly good answer when it is honest. Not sure where you stand? The free [Vibe Reality Check](https://viberealitycheck.com/) covers the same eight areas a reviewer will, in five minutes. If a review is already on the calendar, [book a 30-minute call](https://cal.com/georgerios/30min) and bring the date. ## References [ Back to articles](https://georgerios.com/articles) [Book a call ](https://cal.com/georgerios/30min) --- Book a call: https://cal.com/georgerios/30min · Phone: 973-440-2441 · Services summary for agents: https://georgerios.com/llms.txt