The Pre-Launch Checklist for AI-Built Apps

You can change something without changing it for everyone

One project, one database, one set of keys means staging is a branch and production is where you find out. Every experiment you run, your users run with you.

How you knowAsk yourself where you'd test a risky change. If the honest answer is “on the live site, late at night”, you don't have this.

You can undo a deploy in under a minute

Deploys that only go forward mean that when a change breaks checkout at 9pm, the fix is another change written under pressure — which is how a small outage becomes a long one. Code is the easy half: most hosts put yesterday's build back in one click. A database change that shipped with it does not come back the same way, and that is the half worth having an answer for before you need it.

How you knowFind the button or command that puts yesterday's version back, then ask what happens to a database change that went out with it. If either answer takes more than a minute to arrive, you don't have this yet.

No keys or passwords are sitting in your code

API keys committed early and never rotated stay valid, and stay in the history after you delete the line. Anyone who ever gets a copy of the repo has them.

How you knowSearching your editor covers today's files, not the history — and the history is where the risk sits. From the project folder run: git log -p | grep -iE 'sk-|secret|password|api.?key' — or point a free scanner like gitleaks at the repo. Anything that looks like a real credential is one, and deleting the line now doesn't remove it: the fix is to rotate the key.

Your AI spend has a ceiling you chose

No per-user cap, no budget alert and no caching turns one loop or one scraper into a bill that competes with your runway. It is one of the fastest ways an AI-built app can lose real money in a week, because nothing about it looks wrong until the invoice.

How you knowOpen your model provider's billing page and look for a spend limit and an alert. If neither is set, your ceiling is whatever your card allows. Check which kind you have, too — some providers stop serving requests at the limit, others only email you after you've passed it.

Someone can't hit your app ten thousand times a minute

An endpoint answers as fast as it's asked, so whoever finds it decides your capacity — and if it calls a model on every request, your bill. The routes you wrote yourself are the exposed ones.

How you knowSome of this you get for free: Supabase and Clerk throttle their own login and signup routes, and a proxy like Cloudflare in front of the app covers some of the rest. The gap is almost always the endpoints you wrote, especially anything that calls a model. Take your most expensive one and ask what stops the same caller hitting it a thousand times in a row.

Your database and login were set up for real users, not a demo

Permissive access rules, no connection pooling, no migration path, and a session model that was fine for ten people. Each of those is invisible until the day it isn't.

How you knowLog in as one test user, find a URL with an ID in it, and change that ID to another user's. If their data comes back, you have the problem. Test it rather than reason about it — this is the cheapest item here to check and the most expensive to be wrong about.

You find out about problems before your users tell you

When something breaks and there's nothing to look at, you learn about outages from the people paying you — and you learn about them late.

How you knowAsk where you'd look to see whether the app is erroring right now. No answer means no observability.

You have a backup, and you have restored from it once

Managed hosts usually take backups on paid plans, and several — Supabase and Neon among them — give you little or nothing on the free tier. So the first question is whether they exist at all. The second is that a backup nobody has restored is a belief rather than a plan.

How you knowFind what your plan actually includes, then restore yesterday's database into a scratch copy. If you can't find them, don't know how, or it fails partway, you don't have backups — you have files.

You know what one user actually costs you

Hosting, database, model calls and storage per active user is the number every pricing and fundraising conversation depends on, and it's the one nobody computes until it hurts.

How you knowTake the part of last month's bill that moves with usage — model calls, storage, bandwidth — and look at it per active user. Then find your ten heaviest users and work out what they cost. On an AI product the average hides them, and the heavy tail is what decides your pricing. Keep fixed hosting out of it; it doesn't divide. If you can't get those inputs in ten minutes, that's the gap.

Nothing important depends on one person's personal account

Domains, hosting, model keys and app-store listings registered to a personal email are a single point of failure that has nothing to do with your code.

How you knowList where the domain, the hosting and the production database actually live, and whose login opens each. Any personal account on that list is a risk.

Your slowest page is slow for a reason you know

“The app feels slow” is often a single query or an unbatched loop rather than a hosting problem — and the fix people reach for first is a bigger server, which costs money and sometimes changes nothing.

How you knowOpen your slowest page with the browser's network tab showing, and watch how long the first request takes to come back before anything appears. If you can't name what it's waiting on, you're guessing at the fix — and a bigger server is the expensive way to find that out.

You can add a second person without giving them everything

The first engineer or contractor you bring on needs enough access to work and not enough to end you. Set up after the fact, under time pressure, this always lands on “make them an admin”.

How you knowIf there's exactly one account tier and it's owner, you'll be making that decision in a hurry later.

You know which of these you're deliberately ignoring

Not everything here needs fixing before launch. Working through the whole list before launch is its own failure mode — it's how a month disappears before anyone has used the thing. The point is that each one is a decision you made rather than one you never saw.

How you knowGo back through the list and mark the ones you're choosing to skip. If any item is unmarked because you didn't understand it, that's the one to ask about.