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.

How you knowFind the button or command that puts yesterday's version back. If you have to think about it for more than a minute, you don't have one.

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 knowSearch your project for “sk-”, “key”, “secret” and “password”. Anything that looks like a real credential is one, including in old commits.

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. This is the single most common way an AI-built app loses real money in a week.

How you knowOpen your model provider's dashboard. If there's no hard spend limit set and no alert configured, your ceiling is your card limit.

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

Every endpoint answers as fast as it's asked, so the first bot that finds your signup route decides your capacity — and, if it's an AI endpoint, your bill.

How you knowIf you've never configured a rate limit anywhere, you don't have one. Nothing turns this on by default.

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 knowAsk whether a logged-in user could read another user's rows by changing an ID in the URL. If you can't answer confidently, that's the answer.

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

Almost every host takes backups. Far fewer founders have ever restored one, and a backup you've never restored is a belief, not a plan.

How you knowRestore yesterday's database into a scratch copy. If you don't know how, or it fails, 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 knowDivide last month's total infrastructure and model bill by your active users. If you can't get the 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 usually one query or one unbatched loop, not a hosting problem — and the usual fix people reach for first is a bigger server, which costs money and changes nothing.

How you knowTime your worst page. If it's over about two seconds and you can't name the reason, you're guessing at the fix.

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. Doing all thirteen at pre-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.