# App Launch Checklist for AI-Built Apps: 5 Checks First

> A practical app launch checklist for AI-built apps from Lovable, Bolt or Base44: data rules, exposed keys, payment confirmation, backups, load and rollout.

- Author: Filipe Eduardo, Senior Software Engineer (https://filipeeduardo.dev/)
- Published: October 8, 2026
- Topic: AI-built apps · Tags: app launch checklist
- Canonical URL: https://filipeeduardo.dev/blog/app-launch-checklist

![Minimal illustration of a pieced-together browser window beside a five-item app launch checklist with the first check ticked in orange](https://cms.filipeeduardo.dev/wp-content/uploads/2026/10/app-launch-checklist.webp)

## Key takeaways

- Four checks cover most of the risk: data access rules, exposed keys, payment confirmation and backups.
- Treat AI-generated code as a first draft. Fix what exists before thinking about a rewrite.
- The platform secures its infrastructure. You are responsible for your app’s behavior: data rules, keys in the browser, payment confirmation, backups.
- Test with a second account, not just your own admin login.
- Launch to a small group first, with a way to roll back and a way to notice problems.

A solid **app launch checklist** for an AI-built app comes down to four checks before real users arrive: who can read which data, which keys are exposed in the browser, whether payments are confirmed on the server, and whether you can restore a backup. Two more steps, a basic load test and a staged rollout, keep the launch calm.

I am a Brazilian senior engineer, and this is the order I run these checks in when I look at [an app generated by Lovable, Bolt, Base44 or similar tools](https://filipeeduardo.dev/blog/ai-app-builder-production). None of it needs a full audit. A few focused checks find most of the risk, and fixing problems gets more expensive once real users and payments are in the system.

## What must be true before you launch an AI-built app?

Before launch, five statements should be true, and you should be able to prove each one rather than believe it:

1.  A user cannot read or change another user’s data.
2.  No secret key ships to the browser.
3.  An order is marked paid only after the server confirms the payment.
4.  You have restored a backup at least once, successfully.
5.  The app works with more than one person using it at the same time.

The reason this list is short is the shared responsibility model. The builder and the database provider secure their servers and accounts. They do not know what your business rules are. Who may see an invoice, which price is valid, when an order counts as paid: that is your app’s behavior, so it is yours to verify.

[AI tools are good at making screens work. They are weaker at the invisible parts](https://filipeeduardo.dev/blog/vibe-coding-security), and those are exactly the parts the checks below cover.

## Are data access rules tested with a second account?

This is the check I would never skip. If your app uses Supabase, access is controlled by row-level security (RLS) policies. Apps built with Lovable have shown a pattern of weak RLS rules, so do not assume yours are right because the app looks fine when you use it.

### How to test it in 15 minutes

1.  Create two normal user accounts, A and B, in separate browsers.
2.  As A, create a record: an order, a document, a profile note.
3.  As B, try to open A’s record by its URL or ID. It should fail.
4.  Open the browser dev tools as B, find the API request the app makes, and change the ID or filter to A’s. It should return nothing.
5.  Log out entirely and repeat the request. Anonymous access should be refused for anything private.

Also check that RLS is actually enabled on every table, not only the ones you remember. A table without RLS and with the public key in the browser is readable by anyone who looks. Pay attention to policies that say something like “allow if the user is logged in” without tying the row to that user.

The Base44 case from July 2025 is a useful reminder. Wiz researchers found that someone could register on apps meant to be private using only the app’s ID, and it was fixed within a day. The platform fixed its part quickly, but the lesson for owners is to confirm that your private app is actually private, from the outside.

![Two laptops showing separate user dashboards, illustrating a second-account test of data access rules in an app launch checklist](https://cms.filipeeduardo.dev/wp-content/uploads/2026/10/app-launch-checklist-1.webp)

Testing with a second account shows whether one user can reach another’s data.

## Are any keys exposed in the browser?

Anything that reaches the browser is public. Open the site, view the page’s loaded JavaScript and the network tab, and look at what is sent.

Some keys are meant to be public: the Supabase anon key, a Stripe publishable key. These are safe only if your data rules are correct, which is why the previous check comes first. Other keys must never appear there:

-   Supabase service role key (it bypasses RLS entirely)
-   Stripe secret key and webhook signing secret
-   Any third-party API key that bills you per call, such as an AI model provider or email service

### What to do if you find one

Rotate it first, then fix the code. Removing a key from the code does not help if it was already served to visitors or committed to a repository, because it should be treated as leaked. Move the call that needs it to a server function or backend route, and keep the secret in environment variables on the server side.

Also search your repository history if the code lives on GitHub. A key deleted last week is still in old commits.

## Is payment confirmed on the server?

A common AI-generated pattern is to redirect the user to Stripe Checkout, and when they land back on a “success” page, mark the order as paid. That page can be reached by anyone who guesses the URL, and it is skipped entirely if the user closes the tab after paying.

The reliable approach is for Stripe to notify your server through a webhook, and for your server to [verify the event signature before changing anything](https://filipeeduardo.dev/blog/stripe-webhook-secret). Only then should the order become paid.

Test these cases:

-   Open the success URL directly without paying. The order must stay unpaid.
-   Pay, then close the tab before the redirect. The order should still become paid.
-   [Replay the same webhook event twice](https://filipeeduardo.dev/blog/stripe-test-webhook). You should not get two orders or two deliveries.
-   Check that the amount and product come from your server, not from values the browser sent. A user should not be able to edit a price in a request.

This is where generic security scanners tend to fall short, because duplicate orders and webhook logic are business logic, not known vulnerability patterns. [Webhook details deserve their own walkthrough](https://filipeeduardo.dev/blog/stripe-webhook-events), so here I only cover the launch-level question: does the server decide, or the browser?

## Can you restore a backup?

Having backups enabled is not the same as having a backup you can restore. Many founders discover the difference during an incident.

Do a drill before launch:

1.  Find out what your database plan actually backs up and how often. Check the provider’s current documentation, since this varies by plan.
2.  Restore a backup into a separate, empty project.
3.  Open the restored copy and check that recent data is there and the app can connect to it.
4.  Write down the steps and how long it took.

Also decide where your code lives. Code built in Lovable can be moved to GitHub and to your own hosting, which gives you a copy you control. If the builder account were suspended tomorrow, could you still deploy? If the answer is no, fix that before launch. Uploaded files, such as images and documents, are often stored separately from the database, so confirm those are covered too.

![Two matching server cabinets, one being restored from the other, representing a backup restore drill before launch](https://cms.filipeeduardo.dev/wp-content/uploads/2026/10/app-launch-checklist-2.webp)

A restore drill proves the backup works before you need it.

## Will the app hold up under real traffic?

You do not need a large load test. You need to find the obvious failures. Real users do things your demo never did: they open many tabs, refresh repeatedly, and arrive at the same moment after you send an email.

Simple checks that find most problems:

-   Use a free load tool to simulate a few dozen concurrent users on your main flows: sign-up, login, the main list page and checkout.
-   Watch the database. Pages that load every row of a table and filter in the browser get slow as data grows.
-   Look for missing indexes on columns you filter or sort by.
-   Check rate limits on login, password reset and any endpoint that sends email or calls a paid API. Without limits, one script can run up your bill.
-   Confirm the plan limits of your hosting and database. Free tiers often pause or throttle.

Set up error tracking and basic uptime monitoring too. If something breaks at 2 a.m. you want to learn about it from an alert, not from a customer.

## How do you roll out to the first users safely?

Launch in stages. A small group exposes problems while the damage is still small.

1.  **Separate environments.** Keep test data and live data apart, and use Stripe test mode until the end.
2.  **Invite a small group.** Start with a small group of people you can talk to directly; as a rule of thumb, a few dozen at most.
3.  **Watch the first payments by hand.** Compare each Stripe payment with the matching order in your database.
4.  **Have a rollback.** Know how to return to the previous version quickly and who does it.
5.  **Widen gradually.** Expand only after a few days without surprises.

Staying on the builder is sometimes the right call, especially for an internal tool or a small app with low-risk data. The checks above apply either way. And if a check fails, fix the specific issue in the existing code first. A rewrite is rarely the first move.

## Want a second opinion?

If you are about to launch an AI-built app, email me@filipeeduardo.dev with the link and a short description, and I’m glad to tell you what I’d check first.

## Frequently asked questions

### Do I need a full security audit before launch?

Usually not at the start. The four focused checks cover most of the risk. A broader audit makes sense once you handle sensitive data or meaningful payment volume.

### Can I ask the AI builder to fix these problems?

You can ask, but verify the result yourself. Data rules, keys and payment paths are what these tools tend to get wrong, so run the second-account test again after every fix.

### Is the platform responsible if my data leaks?

The platform is responsible for its infrastructure and accounts. Who can read which rows, and what ships to the browser, is the app owner’s responsibility. This is not legal advice; check your terms and talk to a lawyer about obligations to your users.

### How long does this checklist take?

As a rough rule of thumb from my own experience, a small app can be checked in a day or two. Fixing what you find varies a lot with the app.

### When should I move off the builder?

When you need control the builder cannot give, such as custom backend logic, your own hosting or tighter security. If the app is simple and the checks pass, staying can be fine.