# Technical due diligence before you raise Source: https://www.plutonapps.com/resources/technical-due-diligence-before-fundraising Published 2026-10-02. By Plutonapps Engineering. Investors will look under the hood before they wire money. What they check, the extra questions for AI-built products, and how to have the evidence ready in 30 days. Technical due diligence before you raise is an investor's check that your product is real, that your company owns it, and that it can grow without a rewrite. As of 2 October 2026, the way to pass it is to show evidence, not intentions. Show who owns the code and accounts, how the system is built and secured, what the tests prove, how often you release, and what happened when things broke. If an AI tool wrote much of your code, expect extra questions. Investors will ask who owns that code, and whether anyone on your team can explain and change it safely. This guide is for founders preparing a seed or Series A round with a product built partly or mostly with Lovable, Bolt, v0, Replit, Cursor or a similar tool. Legal and standards facts below come from the primary sources listed at the end, checked on 2 October 2026. It is not legal advice: ask your lawyer about anything that touches ownership. ## What do investors check in technical due diligence? The depth depends on the round and the investor. An angel may ask a few questions on a call. A larger fund may send a written questionnaire, or hire an outside engineer to review the code. The topics are usually the same; only the depth changes: | Area | What they ask | Evidence that answers it | | --- | --- | --- | | Ownership | Does the company own the code, data, domains and accounts? | Repository in a company organization, accounts in the company's name, contributor agreements | | Architecture | Can it handle ten times the users without a rewrite? | A one-page system map and the known limits | | Security | Who can read which data, and how do you know? | Access rules, a recent security review, a list of secrets and who holds them | | Quality | Can the team change it without breaking it? | Tests that run on every change, and their results | | Delivery | How often do you release, and how often does a release fail? | Release history, rollback record, incident notes | | Team | Who understands this system if one person leaves? | Named owners per area, written runbooks | None of these areas needs a perfect answer. Investors know early products carry [technical debt](https://www.plutonapps.com/resources/what-is-technical-debt). What they look for is that you know where it is, and that you have a plan that fits the money you are raising. ## How do you prove the company owns its code and accounts? Ownership problems can delay a close, because fixing them needs other people's signatures. Start here, weeks before the data room opens. - Code: the repository lives in a GitHub organization the company owns, with at least two company admins. Not in a founder's or freelancer's personal account. - People: everyone who wrote code, including freelancers and agencies, has signed an agreement that assigns their work to the company. If any are missing, a lawyer should draft the fix. - Accounts: hosting, database, domain, email sending, payments, analytics, app stores and AI providers are registered to the company, billed to the company, and listed in one document. - Licenses: you can list the open-source packages you depend on and their licenses. GitHub's dependency graph shows each package's version and license, and can export a software bill of materials (SBOM) for audit or compliance purposes. If a developer or builder still holds an account, move it now. Our guide to [handing over an AI-built app to developers](https://www.plutonapps.com/resources/hand-over-ai-built-app-to-developers) lists the accounts to move and the order to move them in. ## What changes when AI wrote much of the code? Two questions get sharper: who owns the output, and does anyone understand it. On the first, read your tools' terms. Lovable's terms, last updated 28 August 2026, say you own the AI output generated for you, subject to any third-party rights. Copyright is a separate question. In Part 2 of its report on copyright and AI, published 29 January 2025, the US Copyright Office concluded that AI output can be protected only where a human author has determined enough of its expressive elements. Creative arrangements or changes a person makes to the output can count. The mere provision of prompts does not. So an investor's lawyer may ask how much of the code your team shaped, reviewed and changed. A clean commit history with reviewed pull requests is the best evidence you can have. On the second, generated code tends to work on the screens and fail underneath: data readable by the wrong users, keys in the browser, packages nobody chose. Our article on [vibe coding security risks](https://www.plutonapps.com/resources/vibe-coding-security-risks) lists the common ones and how to check each. Expect a diligence engineer to look for the same things. Be ready to answer these directly: - Which tools generated the code, and which parts were written or rewritten by people? - Is every change reviewed by an engineer before it reaches production? - Can someone on the team explain the data model and the access rules without opening the AI tool? - If the AI builder disappeared tomorrow, could you still build, run and release the app? This is the [vendor lock-in](https://www.plutonapps.com/resources/what-is-vendor-lock-in) question. ## What architecture and security evidence should you prepare? Use this as your technical due diligence checklist. A short, true document beats a long, aspirational one. Prepare: 1. **A system map** One page: the front end, the server, the database, file storage, scheduled jobs, and every outside service, with where each one runs. 2. **Known limits** What breaks first as usage grows, and roughly when. Naming the bottleneck is more credible than saying there is none. 3. **Data access rules** Who can read and change each kind of data, and the test that proves a user cannot read another user's rows. 4. **A secrets inventory** Every key by name and purpose, where it is stored and who can see it. Never the values. 5. **A security review** The results of a recent review against a named standard, and what you fixed. OWASP's Application Security Verification Standard, at version 5.0.0, is an open standard built as a basis for testing web application security controls. 6. **Compliance status** Say plainly what you have and what you do not. A SOC 2 report covers an examination of a service organization's controls relevant to security, availability, processing integrity, confidentiality or privacy. If you have not started one, say when customers will need it. A [code audit](https://www.plutonapps.com/resources/what-is-a-code-audit) by someone outside the team, done before the round, turns most of this into a report you can hand over. A penetration test is worth doing first if you handle payments or sensitive personal data. If enterprise buyers are in your plan, read up on [SOC 2](https://www.plutonapps.com/resources/what-is-soc-2) early and plan the time it needs. ## What do tests, releases and incident records need to show? That the team can change the product safely and often. Claims like "well tested" mean little; numbers from your own CI mean a lot. - Tests: how many, what they cover, and that they run on every change. Show the CI history, not a screenshot of one green run. - Releases: how often changes reach production and how often one has to be rolled back. DORA, a program run by Google Cloud, names five delivery metrics: change lead time, deployment frequency, change fail rate, failed deployment recovery time and deployment rework rate. - Rollback: proof you can undo a bad release. A rehearsed rollback is worth more than a promise. - Incidents: a short note for each outage or data problem: what happened, how long it lasted, what changed afterwards. Here is what that evidence looks like in practice. When our engineers took over Looph, a customer-feedback product shaped in Lovable, type checking had never run and lint reported 19,849 problems, so a real one was invisible. There were 1,152 passing tests at handover, and 10,387 passing in CI on 29 September 2026. Bell, an AI email assistant, reached its staging build of 21 September 2026 with 1,307 commits, 285 merged pull requests and more than 13,000 automated tests. Both histories can be checked commit by commit, which is the point. ## How should you prepare in the 30 days before you raise? 1. **Days 1 to 5: ownership** Move the repository and every account into the company's name. List contributors and check each has signed an assignment. Ask your lawyer about any gaps. 2. **Days 6 to 10: the map** Write the one-page system map, the secrets inventory and the list of outside services with what each costs a month. 3. **Days 11 to 20: the checks** Make the tests run on every change. Fix anything that lets one user read another's data. Rotate any key that was ever shared in chat or email. Commission an outside review if you can. 4. **Days 21 to 25: the record** Export the release history and CI results. Write short notes for past incidents. Write down the known limits and the technical debt, with a plan for each. 5. **Days 26 to 30: the room** Put it all in a technical folder in the data room, and rehearse the call: one person who can answer every question above without guessing. Thirty days can be enough for a small product with clean ownership. If accounts sit with former contractors, or nothing is tested, start earlier. ## What are the red flags that slow a round down? - The code or a key account belongs to someone who no longer works with you. - No one on the team can explain how the app decides who sees what. - Secrets in the repository or in the browser code. - No tests, or tests that do not run automatically. - No way to roll back a release, and no record of past outages. - A plan to rewrite everything after the round, with no estimate of what it costs. Most of these can be fixed in weeks. Found by the investor's engineer instead of by you, each one costs trust you will want back during negotiations. > **Evidence an investor can check** On a Plutonapps plan you keep prompting in Lovable, and our engineers turn each version into the live product. Every change goes through tests and review, so you raise with a real release history, test results and access rules, not a promise. The code, data and infrastructure belong to your company from the start. The Starter plan is $2,999 a month paid annually, or $3,999 month to month; Growth is custom-priced. See [pricing](https://www.plutonapps.com/pricing). To find your gaps first, take the free [production-readiness check](https://www.plutonapps.com/tools/production-readiness-check): 19 questions, a score out of 100 and your three biggest risks. ## Sources Each legal, standards or platform fact above comes from one of these pages, checked on 2 October 2026. - US Copyright Office: Copyright and Artificial Intelligence, Part 2: Copyrightability, published 29 January 2025 (copyright.gov/ai). - Library of Congress, Copyright Office blog: Inside the Copyright Office's report, Part 2: Copyrightability, February 2025 (blogs.loc.gov/copyright). - Lovable: Terms of Service, Ownership section, last updated 28 August 2026 (lovable.dev/terms). - OWASP: Application Security Verification Standard project page, current version 5.0.0 (owasp.org). - AICPA & CIMA: SOC 2, Reporting on an Examination of Controls at a Service Organization (aicpa-cima.com). - DORA: DORA's software delivery performance metrics guide (dora.dev/guides/dora-metrics). - GitHub documentation: About the dependency graph, including SBOM export (docs.github.com). - Case-study facts: our Looph and Bell case studies, as published on this site; Starter and Growth prices from our pricing page. ## Frequently asked questions ### When does technical due diligence happen in a fundraise? Often after a term sheet or a strong first meeting, and before the round closes. Early investors may only ask a few questions on a call. Larger funds may have an engineer review the code. Prepare before you start pitching, because fixing ownership takes time. ### Is an AI-built app a problem for investors? Not by itself. Investors care whether the company owns the code, whether it is secure, and whether the team can change it safely. Show reviewed changes, tests that run on every change and clear access rules. Then the tool that wrote the first draft matters much less. ### Do I need SOC 2 before a seed round? It depends on your customers. Investors want to know whether your customers will require it, and when. Say plainly what you have today and when you plan to start, and show the security basics in the meantime. ### Who owns code generated by an AI app builder? Check each tool's terms first. Lovable's terms say you own the output, subject to third-party rights. Copyright is a separate question: the US Copyright Office has said the mere provision of prompts is not enough for protection. Ask your lawyer how this applies to your company. ### What should go in the technical folder of a data room? A one-page system map, the list of accounts and who owns them, contributor agreements, a secrets inventory without the values, security review results, test and release history, incident notes, and a short note on known limits and technical debt.