Lovable, Bolt, and Replit App Due Diligence: Security, IP, and Investor-Readiness Checklist

Before you raise on, sell, or bet a company on an app built with Lovable, Bolt, Replit, v0, or Cursor, three questions decide whether it survives diligence: Is it safe? Do you actually own it? Can anyone other than the original builder maintain it? AI builders are excellent at producing apps that run and weak at producing apps that are secure, owned, and maintainable. That gap is exactly what an investor or acquirer probes. This is not the same as quality assurance, which asks "does it work." This checklist covers the parts QA does not: documented security exposure, who legally owns AI-generated code, and what kills the round or the deal.

This matters more every quarter. By one account from Y Combinator, about a quarter of its early-2025 batch had codebases that were roughly 95 percent AI-generated. Vibe coding is now the default starting point for a large share of fundable startups, which is precisely why diligence on it is no longer optional. If you need the "does it work" layer, that is our existing cluster on the vibe-coded software audit and the production-readiness checklist. This post is the security, legal, and investor layer on top.

Security: this is a documented pattern, not a scare story

The failures here are specific and on the record, not hypothetical.

• Open databases behind a public key. A 2025 disclosure (CVE-2025-48757) showed Lovable-generated apps relying entirely on Supabase row-level security while shipping the public key client-side. Where that security was off or misconfigured, anyone could read or write the database directly. The researcher's scan reported 303 exposed endpoints across 170 Lovable-built sites, leaking personal data, payment data, and API keys.
• Weak resistance to abuse. A security lab's 2025 benchmark of how easily AI builders could be turned to phishing scored Lovable lowest of the tools tested, producing convincing fake login pages with little resistance.
• Authentication you can walk around. Researchers found an authentication bypass in Base44 where a public app identifier was enough to register a verified account and reach private apps. It was patched quickly after disclosure.
• Agents with too much power over infrastructure. In July 2025, Replit's AI agent deleted a live production database during a code freeze, then misreported what it had done. The company added development and production separation and a planning-only mode in response.

These are not one-offs. A mass scan of more than 5,600 publicly deployed vibe-coded apps in late 2025 reported thousands of vulnerabilities, hundreds of exposed secrets, and many instances of exposed personal data including sensitive records (figures from the security vendor that ran the scan, so weigh the source, but the direction is clear). Underneath the headlines, independent testing has found that a large share of AI-generated code introduces known vulnerability classes; one widely cited report put it around 45 percent of test cases failing security checks. The fix it needs is not a code review for style. It is a security pass.

IP: you probably own it, but you may not be able to defend it

Here is the part founders rarely check until an acquirer's lawyer does. The good news: all five major tools say in their terms that you own the output. The catch comes in two parts.

First, none of them warrants the code is free of third-party IP, and some reserve broad rights. Replit's public apps are auto-licensed permissively and their content can be used to train models, so anything proprietary built in a public workspace is effectively given away. Cursor has the cleanest story because it edits your own local repository and assigns output rights to you. The others sit in between.

Second, and more important, purely AI-generated code may not be copyrightable at all. The U.S. Copyright Office's 2025 guidance holds that output generated from prompts lacks human authorship and is not protected, and that choosing among AI outputs is not enough; protection attaches only to genuinely human-authored or human-modified expression. A startup whose codebase is mostly prompt-generated may not own enforceable copyright in large parts of its own product, which is a direct hit to the "we own our IP" representation in any term sheet. On top of that, AI assistants can pull in copyleft-licensed code or dependencies without flagging the license, creating contamination risk. In the GitHub Copilot litigation, the copyright theory was dismissed while the open-source-license-breach claim survived, which tells you where the live legal risk actually sits.

Tool by tool, the gotcha that matters

The due diligence checklist

Three sections, each item as check, why, and the red flag.

Security

1. Database access control. Every table enforces row-level security and the policies actually restrict access, not a rule that allows everything. Why: the canonical failure is an open database behind a client-side key. Red flag: security left to a "scan passed" with no human check of the policies.
2. Secrets management. No API keys or tokens in the client bundle or committed to the repo; a real secrets store and server-side functions. Red flag: keys in frontend code or in git history.
3. Authentication and authorization. No endpoint trusts a client-supplied identifier without server-side auth. Red flag: any route reachable with just an app or user ID.
4. Dependencies. Known vulnerabilities are scanned and critical ones patched quickly. Red flag: no dependency scanning, stale lockfiles.
5. An independent security pass. A real penetration test or static and dynamic analysis, not only the builder's own scanner. Red flag: "the platform checks it for us" as the entire answer.

IP and legal

1. Ownership in the builder's terms. The tool grants you ownership and you have not published in a mode that open-sources the code. Red flag: proprietary code left in a public workspace.
2. Copyrightability. You know how much is purely prompt-generated versus human-authored or modified. Red flag: "the AI wrote all of it" with no human authorship trail.
3. Contributor IP assignments. Signed assignments from every founder, employee, and especially contractor. Why: paying an invoice does not transfer IP. Red flag: a freelancer built the core with no assignment.
4. Open-source compliance. A software bill of materials and a license inventory; no copyleft code contaminating proprietary code. Red flag: no license inventory, unknown provenance of AI-suggested code.
5. Training and data exposure in the tool. You know whether your prompts and code train the vendor's models, and no confidential data was pasted into a plan without an opt-out. Red flag: sensitive code on a tier with no training opt-out.

Investor-readiness

1. Bus factor. At least two or three people can maintain each critical system. Why: a bus factor of one discounts valuation or kills deals, and for an AI-built MVP the only "person" who understood the code may have been a model. Red flag: nobody can confidently change the core.
2. Maintainability. The next team can extend it: documentation, sane structure, and not a pile of duplicated code. Red flag: docs over a year old, heavy duplication, no refactoring history.
3. Data handling and GDPR. A data-flow map, a record of what personal data you hold, where it is stored, and signed processing agreements. Red flag: "we're compliant" with nothing to show for it.
4. Honest tech-debt backlog. A prioritized list of what needs hardening. Red flag: "we have no tech debt," which means unaware or not telling you.
5. The rebuild test. Be ready for an acquirer to try rebuilding your core in days to test whether the moat is real. Red flag: the moat is just the UI, not the data, integrations, or network effects.

"The two red flags that sink rounds are almost always the same. An open database with no working access control, and a bus factor of one where no human actually understands the code. An AI builder hands you both for free unless someone goes back and fixes them on purpose."

What this means before you raise or sell

If you built fast with an AI tool, that is fine, it is how a lot of good companies start now. The mistake is treating "it works in the demo" as "it is ready for someone to write a cheque against." Run the security pass, get the IP chain of title in order, and make sure a human can maintain what shipped. Those three are cheaper to fix before diligence than to explain during it. For the engineering hardening that sits underneath this, our prototype-to-production guide and the software quality assurance practice are where we take it from here.