A real security checklist for an AI-built app before you launch it

By Ranjit Bhinge, founder of Blur Studio · Updated October 30, 2026 · 6 min read

Short answer: Before launching an AI-built app, check four things specifically: that no secret key or password is sitting visibly in the code, that your database's access rules (row-level security, if it's built on Supabase) actually restrict who can see and change which data, that you have a backup separate from the live app, and that payment and login edge cases have been tested, not just the happy path. Real, published incidents, including a May 2025 Lovable vulnerability and a July 2025 Base44 flaw found by security researchers at Wiz, show these are genuine, not hypothetical, risks. A short paid developer review before launch is the most reliable way to catch what a checklist alone might miss.

You've got an AI-built app close to ready and want to know exactly what to check before real customers start using it.

I'm Ranjit, and I run Blur Studio: 15+ years building software, 120 apps taken live, and clients who have gone on to raise $10M+. I build AI systems and processes that help businesses do a lot more with a lot less time. I also work differently from most of what else is out there, more on that further down this page. Say hello.

A checklist is only useful if it's specific enough to actually act on, so this one skips generic advice like "make sure it's secure" in favor of exactly what to check, and why each item matters. To judge whether an AI-built app can carry real work at all, see can you build a real business app with AI.

Secrets and access

No API key, password or database credential should ever appear directly in your app's visible code. These belong in environment variables, a setting your hosting platform keeps separate and hidden, never typed directly into a file the AI tool shows you or that ends up in a public repository.
Check who has admin access to the app itself, not just the live database, and remove anyone who no longer needs it, including a freelancer or a past collaborator.
Rotate any key that was ever shared in a chat, an email, or a screenshot during the build process, since once a secret has been shared outside the app itself, treat it as compromised.

Data access rules, and row-level security specifically

This is the single area most worth getting right, because it's also the one most likely to default to something looser than it should be. A flaw published as CVE-2025-48757 in May 2025 found that database rules in some apps built with Lovable, an AI app builder you chat with to generate a working web app, up to that point, could let outsiders read or change data without logging in at all; Lovable's own documentation now explicitly says the customer is responsible for checking these settings and recommends a professional review for sensitive data.

Many AI builders use Supabase underneath, a database platform that uses row-level security, meaning rules you define that control exactly which rows of data a given logged-in user is allowed to see or change. The AI tool can set these rules up, but it doesn't always turn them on or get them fully right by default. What to actually check: log in as two different test users and confirm, directly, that user A cannot see or edit user B's data, rather than assuming the rules work because the feature "looks" correct in a single-user test.

Authentication and account creation

In July 2025, security researchers at Wiz found that an outsider could create an account inside a private app built on Base44, a no-code AI platform for generating apps from a plain-language description, using only the app's ID, without an invitation. Base44's owner, Wix, said the issue was fixed within 24 hours of being reported and found no evidence it had been exploited beforehand, but it's a useful, concrete example of how an app marked "private" can still have a gap in how accounts actually get created. What to actually check: try creating an account or accessing the app from outside your intended user list, using a browser where you're not already logged in, to confirm the app genuinely restricts access the way it's supposed to.

Payments, if your app handles them

Test a declined card, not just a successful charge.
Test a refund and a mid-cycle plan change, if your app supports either.
Confirm a price shown to the user can't be changed in the browser before the payment is submitted.
Check that a failed payment doesn't silently grant access anyway.

Backups, and a separate test version

In July 2025, the AI coding agent belonging to Replit, another AI app builder with a fuller coding workspace attached, deleted a live production database belonging to SaaStr founder Jason Lemkin during an active code freeze, a database holding records on more than 1,200 companies. Replit's CEO called the incident unacceptable and the platform has since added safeguards, specifically keeping test and production databases separate. What to actually check: confirm you have a real, recent backup of your live data stored somewhere separate from the app itself, and never let an AI tool make changes directly against your live, real data. Make changes against a separate test copy first, and push to the live version only once you've checked the result.

The test steps, in order

Try to break into data you shouldn't be able to see, using a second test account.
Try to create an account or reach the app from outside your intended user list.
Test every payment edge case listed above, not just a successful charge.
Confirm a recent backup exists and that you know how to restore from it.
Search your own code or build history for any exposed key or password, and rotate anything you find.
Load the app with a realistic amount of data, not a handful of test rows, and confirm it still behaves correctly.

When to hand it to a developer for a review

If your app takes payments, stores anything a customer would reasonably expect to be protected, or will be relied on daily by people other than you, get a developer to review it before launch, even briefly. Ask specifically for a review of data access rules, authentication, and payment logic rather than a vague "does this look okay," since a specific scope gets you a specific, useful answer. This is typically a modest, fixed cost, and it's the single most effective thing you can do beyond this checklist, because a developer can read the actual code behind the rules rather than only testing from the outside the way this checklist does. If your app came from Lovable, read about hiring a Lovable developer first.

A worked example of a 30-minute self-audit

Before paying for a developer review, you can catch a surprising share of the common gaps yourself in well under an hour. Open your app in two different browsers, or one normal and one private/incognito window, and log in as two separate test accounts you create specifically for this. In the first account, create a piece of data, a booking, a record, a document. Switch to the second account and try to view or edit that exact item directly, including by guessing or adjusting a URL if your app uses one that references a specific record. If the second account can see or touch the first account's data, you've found a real gap, and it's the single most common one across AI-built apps. Next, log out entirely and try to reach any part of the app that should require a login, directly by URL, to confirm it actually blocks you rather than just hiding a link in the navigation. This simple exercise, done honestly rather than just clicking through as yourself, surfaces most of the obvious issues before you've spent a dollar on a formal review. For a Base44 build, there is a matching guide on hiring a Base44 developer.

Common mistakes with this checklist

Testing only as yourself, the person who built it. You already know the "correct" way to use the app, which means you never stumble into the gaps a real stranger or a confused customer would. Always test as a genuinely separate account.
Assuming a feature that "looks" protected actually is. A button or page being hidden from the navigation menu is not the same as it being blocked at the access-rule level. Test the underlying access directly, not just what's visible on screen.
Treating this as a one-time check. Every new feature you add after launch is a new opportunity for one of these gaps to reappear. Re-run the two-account test after any significant change, not just before the original launch.
Skipping the review because "it's a small app." Small, low-stakes apps are exactly where this checklist alone is often genuinely enough, which is good news, but the moment that same small app starts holding real customer data or payments, it's stopped being low-stakes even if it still feels small to you.

How I'd approach this

When I review an AI-built app before launch, I go through exactly this list and then read the actual code behind the parts that matter most: the data access rules, the authentication logic, and anything touching payments. Most of the time I find a short, specific list of fixes, not a reason to rebuild. I'd rather give you that honest, scoped review before your customers find a gap than have you discover one the hard way.

Questions people ask

What is row-level security, in plain language?

It's a set of rules, built into databases like the one many AI app builders use (Supabase), that control exactly which rows of data a specific logged-in user is allowed to see or change. The AI tool can set these up, but it doesn't always turn them on correctly by default, so they need to be checked directly.

Is it true an AI-built app let outsiders read data without logging in?

A flaw published as CVE-2025-48757 in May 2025 found exactly this in some apps built with Lovable, up to that point. Lovable disputes the characterization but now runs an automatic security scan on publish and recommends a professional review for sensitive data.

How do I check my app's data access rules myself without a developer?

Create two separate test user accounts and confirm, directly, that one account cannot see or change the other's data. This simple test catches a large share of the most common access gaps without needing to read any code.

Do I need a developer review even for a small, low-stakes app?

If it's genuinely internal, with no outside users and nothing sensitive riding on it, a careful self-check against this checklist is often enough. Reserve the paid review for anything with payments, private customer data, or real users depending on it.

What's the single most important item on this checklist?

Data access rules, specifically row-level security if your app uses Supabase underneath. It's the area most likely to default to something looser than it appears, and the one with the most real, published incidents behind it.

Roughly what does this cost?

As a broad reference, fixes and finishes start at around $1,500, and new builds start higher, always a fixed price agreed in writing before I start, never an hourly rate. My AI app cost guide explains what actually drives a quote up or down.

Is my project too small for this?

No. Most of the owners I work with have no tech team at all, that is the whole point. If the smarter move is a cheap software subscription instead of custom software, I will tell you that on the first call, even though it means I do not get paid.