Your app works in the browser. You can sign up, click around and pay. That is the point where AI-built apps are most dangerous, because everything that is not visible in the browser has never been looked at.
When I audit apps that are about to launch, the biggest problems are rarely in the features. They are in the things around the code: backups, alerts, access, limits and costs. Here is what to check before you send people to it.
1. Can you get your data back?
- Open your database provider and find out whether backups are on, and on which plan. On Supabase, daily backups come with a paid plan.
- Do one restore into a scratch project. A backup that was never restored is not a backup.
In one infrastructure audit, the owner could not say whether backups existed. That alone was rated critical, since one bad migration would have meant permanent data loss. See the infrastructure example report.
2. Will you know when it breaks?
- Add error tracking (Sentry, or Cloud Error Reporting if you are on Google Cloud).
- Add an uptime check on a health route, with an email alert.
- Set a budget alert with your cloud provider and a spending cap with your AI provider.
If the answer to "how would I find out the site is down?" is "a customer tells me", you are not ready.
3. Who else can get in?
If only one person holds the keys to your cloud account, database, domain and payment provider, losing that one account locks everyone out. Add a second trusted owner to each, turn on two-factor authentication everywhere, and keep recovery codes offline.
4. Is it secure enough for real users?
Real users mean real data, and AI assistants skip checks nobody asked for. The short version: no secrets in the code, authentication on every route, owner checks on every query, row level security on every table, and npm audit clean. The full list is in the security checklist for AI-built apps.
5. Does it still work with more than 1,000 rows?
Supabase and PostgREST return at most 1,000 rows from a read by default, and they stop there without an error. If you load "all products" or "all orders" in one query, the first customer with more than 1,000 of them gets silently incomplete results. In one audit this had already truncated an export of a 1,347-item feed. Search your code for reads without .range() or .limit() and page through them. The scalability example report shows how this was found and rated.
6. How do you deploy, and can you undo it?
- Are releases built by CI, or from someone's laptop?
- Does a failing test stop a deploy?
- Is there a staging environment, and does it match production?
- Can you go back to the previous version in minutes?
Deploying from a laptop is fine for a first version. Know that it is a risk, and write down the steps.
7. What is the first visit like?
Some hosting setups scale to zero. The first visitor after a quiet period can wait several seconds for the app to start. In one audit I measured 5 seconds for the first request and about 0.1 seconds after that. If your launch page is a login page, that first impression matters.
8. Are your environment variables written down?
If the code reads variables that are not in .env.example, rebuilding the app or onboarding someone takes hours of guessing. List every variable, with an empty value and a one-line comment.
9. The boring but necessary
A privacy policy, terms if you take payments, and a cookie banner if you use analytics. A working contact address. A test of the whole signup and payment path with a real card in test mode, then once live.
How long this takes
Most of this is an afternoon. The slow parts are the restore test and getting a second person set up with access. Do those first.
Want a second pair of eyes
The four audits I run cover exactly these areas: security, infrastructure, architecture and scalability. You can read real reports from one audit of a working AI-built app in the examples, try the free skill on your own project, or ask me to do it for you. See pricing.