Ten questions to ask before you launch an AI-built app to real users

The demo works, friends have tried it, and you’re about to put your AI-built app in front of real users who’ll trust it with their data and maybe their money. This is the moment where “it works” and “it’s safe to launch” turn out to be very different things. Before you flip the switch, answer these ten questions. If any answer is “I don’t know,” that’s your to-do list.

The ten questions

1. If the database got wiped right now, could you get it back?

Not “is there a backup somewhere,” but: have you actually restored one and seen your data come back? A backup you’ve never tested is a guess. Restore to a scratch copy once and confirm it works. This is the single most important question, so it’s first. See how to test a restore if you’re not sure how.

2. Are there any passwords or API keys sitting in the code?

AI code tools sometimes hardcode secrets instead of using environment variables. A key in your browser bundle or git history is public. Search for anything like sk_live or a long random string, and if you find one, rotate it and move it to an environment variable. Our 5-minute check walks through where to look.

3. Can one user see another user’s data?

This is the most common serious bug in AI-built apps. Log in as two different test users and try to open user A’s data while logged in as user B. If it works, you have a data leak. You need access rules (row-level security) so the database itself enforces who sees what, not just the app’s front end.

4. What happens when something breaks: do you find out, or does the user?

If your app throws an error at 3am, do you get an alert, or do you learn about it from an angry email three days later? You need basic monitoring: uptime checks and error tracking. Finding out before your users do is the difference between a quiet fix and a public failure.

5. Can you deploy a change and undo it if it goes wrong?

The day after launch you’ll want to fix something. If your only option is editing the live app with no way back, one bad change takes everyone down. You need a safe path: test the change first, then deploy, with a clear way to roll back. If you’re still vibe-coding features, this matters even more.

6. Will it stay up when more than a handful of people use it at once?

Demos have one user. Launch day might have fifty. The usual first thing to break is the database running out of connections, because AI-built apps often open a new connection per request and never close it. Know your platform’s connection limit and whether you need pooling. See connection limits explained.

7. If you’re in the EU or serving EU users, are you compliant enough to launch?

If you collect personal data (names, emails, anything identifying) from EU users, GDPR applies. At launch you need a lawful basis, a privacy policy, and a data processing agreement with whoever stores your data. You don’t need to be perfect, but you can’t be at zero. This is legal risk, not just technical.

8. Do you know what every paid service costs and when it renews?

Launch is a bad time to get surprised by a €200 charge. List every paid service, its monthly cost, and its renewal date. Set a spending alert on your cloud and AI accounts so a runaway process or a leaked key can’t quietly drain your card before you notice.

9. Who owns the domain, and does it auto-renew?

An expired domain takes your whole app offline in one quiet moment. Confirm the domain is in an account you control, with a working payment card on file and auto-renew on. If a client or a former freelancer owns it, fix that before launch, not after it lapses.

10. If it breaks and you can’t fix it, who can?

Be honest. If the app went down tomorrow and you couldn’t sort it out, is there a person who could? A freelancer on call, a friend who codes, a service? “Nobody” is a real answer, and a risky one for anything a business depends on. Know your fallback before you need it.

How to score yourself

• All ten a clear yes: launch.
• One or two “I don’t know”: fix those first, they’re usually quick.
• Three or more gaps: you’re not ready. Working through them will take a few days, and it’s a lot cheaper than cleaning up after a launch that went wrong.

Questions 1, 2, and 3 are non-negotiable. A launch without tested backups, with exposed secrets, or with users able to read each other’s data isn’t a launch, it’s an incident waiting for a date.

Or, we do it for you

Want someone to run these ten checks for you and hand you a plain-language report? A free Stackbastion audit does exactly that, no obligation. You’ll know before launch which of the ten are green and which need work.

FAQ

I’m launching to only 10 friendly users. Do I still need all this?

Not all of it. For 10 friendly beta users you can defer monitoring, pooling, and some polish. But questions 1, 2, and 3, backups, secrets, and data isolation, still apply from user one. Even friendly users have real data, and a wiped database or a leaked key is just as bad at 10 users as at 10,000. Do the floor, defer the rest.

How long does it take to fix a “no” answer?

Most individual items are a few hours to a day if you follow a guide. Testing a restore is an afternoon. Getting keys out of code is usually an hour. Access rules and a proper migration take longer, a few days. If you have three or more gaps, budget a week of part-time work before launch. It’s rarely as bad as it looks once you start.

What if I don’t understand some of these questions?

That’s a fair signal that you need a second pair of eyes before launch, not that you should skip the question. The ones you don’t understand are often the ones most likely to bite. Either read the linked guides, ask a developer to check, or run a free audit. Don’t launch past a question you can’t answer just because it’s uncomfortable.

Is GDPR really a launch blocker, or can I sort it out later?

If you serve EU users and collect personal data, the basics (privacy policy, lawful basis, a DPA with your data host) need to be in place at launch, because the obligation starts the moment you collect data, not when you get big. You don’t need a perfect compliance program on day one. You do need to not be at zero. Fixing it “later” means launching in breach, which is a risk you’re choosing on purpose.