September 28, 2026
Is Your AI-Built App Safe to Sell?
A non-technical founder’s checklist: 18 checks you can do without reading a line of code.
The short answer
Not automatically. AI builders get you to a working app fast, but AI-written code often ships with security holes, and securing your app is largely your job, not the platform’s. Before you take money or customer data, check that you own every account, that each customer can only see their own data, that payments run through Stripe, and that you have basic legal pages. If you handle sensitive data, get a developer’s second opinion first.
Is AI-generated code safe?
AI-generated code is not safe by default. In its 2025 GenAI Code Security Report, Veracode tested over 100 AI models across four programming languages: 45% of code samples failed security tests and introduced OWASP Top 10 vulnerabilities (the industry’s standard list of the most common web security flaws).
The app builders have had real incidents too. In March 2025, researcher Matt Palmer found that 170 of 1,645 Lovable-built apps he analysed (about 10.3%) had database tables anyone could read. Exposed data included names, emails, phone numbers, API keys and payment details. The cause, logged as CVE-2025-48757, was an “insufficient” row-level security policy (the rules deciding who can see which data). Lovable disputes the CVE, saying each customer is responsible for protecting their own app’s data, which is exactly the point: that responsibility sits with you.
This is risk awareness, not proof that your app is unsafe. The point is that nobody knows until someone checks.
Is my Lovable app secure?
Your Lovable app is as secure as its settings, and those are your responsibility. The same goes for Bolt and Replit: Replit’s shared responsibility model says it secures the platform, while the builder is responsible for “verifying correctness, security, and licensing of Agent output”.
I’ve sat on both sides of the developer relationship. A gap I often see isn’t bad code. It’s that nobody owns the question “is this safe to put customer data into?”
Who owns code built with Lovable, Bolt or Replit?
In general, you do: all three platforms’ terms say you keep the rights to what you build, but each also takes a licence over your content. This is what the terms said in September 2026. Terms change, so check the current terms before relying on it.
| Platform | Who owns your app and code | What the platform can do with it | What to do |
|---|---|---|---|
| Lovable | “You own your Customer Data, including the applications, websites, or other projects you build”, and the AI output (terms, updated 28 August 2026). | A perpetual licence to use your content, including to train AI models. You can opt out of training. | Opt out of training. Git sync to your own GitHub. |
| Bolt (StackBlitz) | You “retain all right, title, and interest” in your content, and StackBlitz assigns you its rights in AI output (terms, updated 22 September 2026, effective 7 October 2026 for existing accounts). | A licence to host your content, and to use some of it for AI training unless you opt out. | Check the opt-out. Sync to your GitHub. |
| Replit | You “retain any and all of your rights” to content you submit (terms, updated 3 August 2026). | A licence to run the service with your content. Replit may access private apps for troubleshooting and security. | Keep apps private. Check permissions. |
Owning the code on paper doesn’t protect you from a freelancer who set up the accounts in their own name. That’s what checks 1 to 7 are for.
What should I check before I sell my AI-built app?
Check five things: you own the accounts, your data is locked down, money is handled safely, the legal basics are in place, and someone qualified has looked. Each check says how to do it without reading code, and the red flag that means fix it first. Your AI builder can walk you through most of them.
1. Accounts and ownership
| Check | How to check it | Red flag |
|---|---|---|
| 1. The code is in a GitHub repo in your name | Log in to GitHub as yourself and find the repo under your username or company. Confirm your builder’s GitHub connection points there. | The only copy lives inside the builder tool, or in a freelancer’s GitHub. |
| 2. The domain is registered to you | Log in to your domain registrar and see the domain listed in your own account. | “My developer bought it for me” and you don’t have the login. |
| 3. Hosting is in your account | Find where the live app runs and confirm you can log in and manage it. | You’d need to ask someone else to redeploy, restart or cancel it. |
| 4. The database is in your account | Log in to the database provider (often Supabase, or the builder’s own cloud) and see your tables. | You don’t know where customer data is actually stored. |
| 5. API keys come from your accounts | List every outside service the app uses (AI, email, payments) and find each key under your own login. | Keys borrowed from a freelancer, a friend or a tutorial. |
| 6. Two admins, with two-factor login | Every account above has you as owner, a named backup admin, and two-factor authentication on. | One shared password sitting in a group chat. |
| 7. Billing is on your card or company | Check who receives the invoices for each account. | Someone else’s card, so the app goes dark if they stop paying. |
2. Data and access
| Check | How to check it | Red flag |
|---|---|---|
| 8. Logged-out visitors can’t see private pages | In a private (incognito) browser window, paste the address of a dashboard or admin page. You should land on the login screen. | The page loads, or shows data for a second before redirecting. |
| 9. Each customer sees only their own data | Create test accounts A and B. Add made-up data as A. Log in as B and try to find it, including by changing any ID number in the web address. Ask your builder: “Is row-level security on for every table, and what does each policy allow?” | B sees anything of A’s, or the answer is “not sure”. This was the hole behind CVE-2025-48757. |
| 10. No secret keys in the front end | Ask your builder to list every key and whether it’s visible in the browser. Secret keys (payment, AI model, database admin) belong in the tool’s secrets feature. Public “publishable” keys are meant to be visible, but only safe if check 9 passes. | A secret key pasted into page code, or “it’s fine, nobody will look”. |
| 11. Backups exist, and you’ve tested one | Find the backup settings in your database provider, note how often they run, and do one practice restore. | No backups on your plan, or nobody has ever tried a restore. |
| 12. You’ve run the built-in security scan | Run your builder’s security check and fix what it flags. | Treating a green scan as proof. Palmer noted Lovable’s first scanner only checked that a security policy existed, not that it worked. |
3. Money
| Check | How to check it | Red flag |
|---|---|---|
| 13. Payments go through Stripe, not custom code | Make a test purchase. The card form should be Stripe Checkout, a Payment Link or Stripe’s embedded form, so card numbers never pass through your app. | A card form your app built. Stripe says handling card data directly can mean meeting more than 300 PCI DSS security controls. |
| 14. Spend limits on AI and API usage | In every paid service, set a monthly budget alert and a hard cap where offered. | No cap, plus a public form anyone can submit that calls an AI model on your bill. |
4. Legal and trust
| Check | How to check it | Red flag |
|---|---|---|
| 15. A privacy policy that matches the app | List what personal data you collect, why, and which services receive it. Check your policy says the same. | No policy, or a template naming services you don’t use. |
| 16. Terms, and a written pilot agreement | Website terms, plus a simple written agreement with each paying customer covering scope, price, data and liability. | Paying customers on a handshake. |
| 17. You know where data is stored and which laws apply | Check the region setting in your database and hosting, then the privacy laws in your customers’ markets (for example, Australia’s Privacy Act, the EU’s GDPR or Japan’s APPI). | A buyer asks “where is our data hosted?” and you can’t answer. |
5. Proof
| Check | How to check it | Red flag |
|---|---|---|
| 18. A developer’s second opinion before you sell to anyone with sensitive data | Pay an independent developer for a fixed-scope review of checks 1 to 17 and the code, with written findings ranked by severity. | The only reviewer so far is the AI that wrote the code, or an agency quoting to rebuild it. |
When do you need a developer or security review before selling?
Get a professional review before your first sale if your app touches any of these, because a mistake lands on your customer, not just you:
For these, “the AI said it’s secure” won’t satisfy your buyer’s IT team, and it shouldn’t satisfy you.
Disclaimer: this checklist is general information, not security or legal advice, and passing it doesn’t make an app secure or compliant. Check the local laws and regulations in your market(s), and get qualified advice where the stakes are high.
What if the checklist turns up problems?
If you find red flags, don’t start a third rebuild. Fix ownership first (checks 1 to 7), because it’s free and stops you losing the app. Then fix data access (checks 8 to 12) before real customer data goes in.
You also don’t need a finished app to get your first paying customer: sell a paid pilot and deliver it by hand while the software catches up. That’s the Manual MVP. If the app has stalled completely, read Stuck at 80%: what to do when your AI-built app stops working.
If you’d like to walk through this checklist on your own app with me, that’s my workshop Is My AI MVP Safe to Sell? (US$67). It goes deeper than the 18 checks here, starting with my free 20-point audit, Who Really Owns Your AI-Built App?
Free founder audit
Who really owns your AI-built app?
A 20-point audit for founders with a Lovable, Bolt, Replit or Cursor prototype, or a freelancer using AI. No coding needed: you're checking who holds the keys, not reading code.
Should you sell it before you fix it?
Take the free Manual MVP Check: 5 questions, 2 minutes. You’ll score green, amber or red, then see what you can safely deliver by hand in your sector while the app gets sorted.
Get the free Manual MVP Check Join the Safe to Sell workshop (US$67)Frequently asked questions
Is my Lovable app secure?
Not necessarily. Lovable secures its platform, but your app’s security depends on its settings, especially row-level security. Test with two accounts: if one can see the other’s data, it isn’t safe to sell yet.
Who owns code built with Lovable, Bolt or Replit?
Under their September 2026 terms, you keep the rights to what you build, but each platform takes a licence over your content. Terms change, so check the current terms, and keep the code in a GitHub repo in your name.
Is AI-generated code safe?
Not by default. Veracode’s 2025 GenAI Code Security Report found 45% of AI-generated code samples introduced OWASP Top 10 vulnerabilities. That doesn’t prove your app is unsafe, but someone should check before customers put data in.
What is row-level security?
A database setting that decides which records each logged-in user can see or change. With weak or missing rules, one customer can read another’s records. Weak or missing row-level security rules were behind CVE-2025-48757 in Lovable apps.
Do I need a developer before I sell my AI-built app?
If you handle sensitive personal data, payments beyond Stripe’s hosted checkout, health, finance, government or regulated work, yes. Otherwise, work through the checklist and get a second opinion before real customer data goes in.
Related guides
- The Manual MVP: get paid before you write code
- Stuck at 80%: what to do when your AI-built app stops working
- The Paid Pilot playbook
Sources: Veracode, Insights from the 2025 GenAI Code Security Report (30 July 2025); Matt Palmer, Statement on CVE-2025-48757 and CVE-2025-48757 disclosure (29 May 2025); NVD entry for CVE-2025-48757; Lovable terms and Lovable deployment, hosting and ownership docs; StackBlitz (Bolt) terms; Replit terms and Replit shared responsibility model; Supabase row-level security docs; Stripe integration security guide. Platform terms read September 2026.
About the author
Matt Ainsworth is the founder of The Lean CPTO, with 20+ years across product, technology, sales, marketing and communications in Australia and Japan, including nearly a decade in Tokyo. He has mentored founders for more than 10 years and has worked on both sides of the developer relationship: selling development services and building products with developers.