Host My AI App

Launch checklist for an AI-built app: what to check before real users

A practical pre-launch checklist for apps built with Claude Code, Cursor, Codex or ChatGPT: access control, secrets, sign-in flows, backups, email, errors, limits, legal basics and a rollback plan, with how to test each one.

Floot ·

Key Takeaways

  • Test access with two ordinary accounts. Broken access control is first on the OWASP Top 10 for 2025. Sign in as user A, create data, then sign in as user B and try to see or change it, including by editing IDs in the URL.
  • Search the shipped JavaScript for secrets. Any key in the frontend is public. Check the browser’s Sources tab for secret-looking strings before launch.
  • Prove you can get data back. Confirm backups exist on your plan and run one restore into a separate database.
  • Walk every account email end to end. Sign-up confirmation, password reset and receipts must arrive, in the inbox, with working links on your real domain.
  • Know how you will undo a bad release. Decide before launch day how to roll back code and how to restore data, and who gets alerted when errors spike.

Quick-Start Prioritization Framework

CheckHow to test itTime
Users only see their own dataTwo test accounts; swap IDs in URLs and requests15 min
No secrets in the frontendSearch browser Sources for sk_, secret, service_role, key prefixes5 min
Backups and restoreFind retention on your plan; restore once into a copy30 min
Sign-up, login, reset emailsRun each flow with a fresh Gmail and Outlook address15 min
Errors are visibleTrigger a failure; confirm it appears in logs or alerts10 min
Plan limits and pausingRead your plan’s idle, quota and commercial-use terms10 min
Privacy policy and contactPage exists, lists what you collect and who processes it30 min

An app that works in the demo can still fail its first real users in ways the demo never showed: one customer sees another customer’s data, the password reset email lands in spam, a free-tier database pauses over the weekend, or a paid API key is sitting in the browser bundle. AI assistants build fast and usually build the happy path. This checklist covers what to verify before you invite people who aren’t you, ordered by how much damage each gap causes. Each item says how to test it, and most take minutes. Nothing here requires you to read the code line by line; it requires you to try the app the way a curious or careless user would.

1. Access control: the check that matters most

OWASP’s Top 10 for 2025 puts Broken Access Control in first place. In small apps it usually looks like this: the page only shows your own orders, but the backend will return anyone’s order if you ask for its ID. The interface hides it; nothing actually prevents it.

The two-account test

Create user A and user B with different email addresses. As A, create a record (an order, a note, a booking). Copy its URL or ID. Sign in as B in a private window and open that URL. Then, with the browser’s developer tools open on the Network tab, find a request that loads one of B’s records and replay it with A’s ID. You should get “not found” or “forbidden” every time.

Admin pages and roles

Sign in as an ordinary user and type the admin page’s address directly. Then try the admin actions’ backend endpoints directly. Hiding a button is not a permission check; the server must refuse.

If you use Supabase or a similar backend-as-a-service

Supabase’s documentation warns that a table in an exposed schema without Row Level Security is readable and writable by any role with a grant on it, and recommends enabling RLS on every table in an exposed schema. Open the table list and confirm RLS is on for every table, including ones the agent added recently, and that each has a policy restricting rows to their owner.

2. Secrets and keys

A leaked payment or AI key costs money directly. Check this before anything goes public, including a link shared in a small group.

Search what the browser downloads

Open the live app, then developer tools, Sources, and search all files for sk_, sk-, secret, service_role, password and the first characters of each key you use. Vite’s documentation is explicit that variables prefixed with VITE_ end up in client-side code and should not contain API keys; the same applies to Next.js’s NEXT_PUBLIC_ variables.

Check the repository

Make sure .env files were never committed. If any secret was ever in the repository or in a public build, rotate it now, before launch. Using test payment keys until launch day and live keys only in production limits the damage of mistakes.

Limit paid endpoints

Any endpoint that calls a paid API (AI models, SMS, maps) should require sign-in and cap usage per user. Set a monthly spending limit at the provider as a backstop.

3. Sign-up, login and account emails

These flows are where first users get stuck, and they rarely get tested because the developer is already signed in.

Run every flow as a stranger

In a private window, sign up with a brand-new address. Confirm the email. Sign out, sign in. Reset the password, then sign in with the new one. Try signing in with Google if you offer it. Do it once on a phone. Check that all links in emails point at your real domain, not a preview or localhost address.

Make sure email reaches the inbox

Send each email to a fresh Gmail and a fresh Outlook address and check where it lands. Google’s sender guidelines require all senders to Gmail to set up SPF or DKIM, keep spam rates below 0.3%, and require bulk senders (over 5,000 messages a day) to use SPF, DKIM and DMARC. Your email provider gives you the DNS records to add; add them on the domain you send from.

Sessions and account deletion

Check that signing out actually ends the session (press back after signing out), and decide how a user deletes their account. Some privacy laws give users the right to erasure, so you will be asked eventually.

4. Data you can get back

The question isn’t whether a mistake will happen to the data; it’s whether you can undo it when it does.

Know what your plan keeps

Look up backup retention on your exact plan. On Supabase, for example, Pro projects keep 7 days of daily backups, free projects have no automatic backups, and point-in-time recovery is a paid add-on. Write the answer down.

Restore once before launch

Restore a backup or a pg_dump file into a separate, empty database and check row counts on your main tables. If you can’t restore it, you don’t have a backup.

Protect against the agent

After launch, any schema change made by an AI agent touches real data. Take a dump or note the time before migrations, and review destructive SQL (DROP, DELETE, TRUNCATE) before it runs.

5. Errors you will actually see

OWASP’s 2025 list includes Security Logging and Alerting Failures and a new category, Mishandling of Exceptional Conditions. In plain terms: things will fail, and you need to hear about it and fail safely.

Trigger a failure on purpose

Submit a form with a missing field, upload a file that is too large, disconnect your network mid-request. The user should see a clear message, not a blank screen or a stack trace. Then find the error in your host’s logs. If you can’t find it in under two minutes, set up better logging or an error-tracking service before launch.

Get alerted

Turn on uptime checks for the home page and one backend endpoint, and an alert when errors spike. A free uptime monitor emailing you is enough for most launches.

Don’t log secrets or personal data

Check a few log lines: they shouldn’t contain passwords, full card details, API keys or entire request bodies with personal data.

6. Limits, quotas and plan terms

Free and entry plans have rules that are invisible until you hit them, and launch day is when you hit them.

Pausing and sleeping

Supabase pauses free projects after one week of inactivity. Render’s free web services spin down after 15 minutes without traffic, and its free Postgres databases expire after 30 days. Any of these looks like an outage to a user.

Commercial use

Vercel describes its Hobby plan as for personal, non-commercial use. If you charge money or run a business on it, move to a plan whose terms fit.

Rate and size limits

Know your function timeout and request size limit (Vercel’s request and response body limit is 4.5 MB, for example) and test the largest upload you allow. Know your email provider’s daily sending cap.

7. Legal and trust basics

This section is general information, not legal advice. Requirements depend on where you and your users are, so check with a qualified professional for your situation.

A privacy policy that matches reality

If you collect personal data from people in the EU, Article 13 of the GDPR requires telling them, at the time you collect it, who you are and how to contact you, why you process the data and on what legal basis, who receives it, how long you keep it, and their rights to access, correct and erase it and to complain to a supervisory authority. Even outside the EU, a privacy page that lists what you collect and which services process it (hosting, email, analytics, AI providers) is the normal expectation.

Terms, contact and payments

Have a way to reach you, a short terms page if you charge money, and refunds handled the way your payment provider requires. If your app sends user content to an AI model, say so.

Domain and HTTPS

Launch on your own domain with HTTPS working on both the bare and www versions, and redirect one to the other. Changing domains after launch breaks sign-in redirect URLs, email links and anything users bookmarked.

8. Launch day and the rollback plan

Decide these before you post the link anywhere.

How to undo a release

Know the exact steps to put the previous version back, whether that’s a redeploy button, a git revert or a publish history. Practice it once.

Freeze risky changes

Don’t let an agent run a big refactor or a schema migration on launch day. Fix bugs in small changes you can test in a preview first.

Watch the first users

Invite a small group first, read the logs during their first session, and ask them what confused them. Ten users will find most of what a hundred would.

Common mistakes

The pattern behind most launch problems is testing as the developer instead of as a user.

Testing only while signed in as yourself

Your account often has extra permissions or existing data. Test with fresh accounts on a fresh browser.

Data stored in the browser

If saved items disappear on another device, the app is using local storage instead of a database. Fix it before launch, not after users lose work.

Preview URLs in production emails

Hard-coded preview or localhost addresses in email templates and sign-in redirect settings are a classic launch-day bug.

Trusting the agent’s “it’s secure”

Ask the agent to explain how access is checked on each endpoint, then run the two-account test yourself. Verification beats reassurance.

If you’d rather not do this yourself

If you’d rather not assemble the infrastructure behind this list, Floot builds apps with their own sign-up and login (email, Google, Microsoft) with roles, a Postgres database you can download on every plan, email sending, and a live preview where you can run these checks before publishing. You still need to run the two-account test yourself.

Frequently Asked Questions

What should I check before launching an app built with AI?

Start with access control (two test accounts can’t see each other’s data), secrets (no keys in the frontend), backups (you have restored one), account emails (they arrive and links work), error visibility and your hosting plan’s limits.

How do I know if my AI-built app is secure?

No single check proves it, but the two-account test catches the most common serious flaw. Combine it with a search for secrets in the shipped JavaScript and a review of which endpoints require sign-in.

Do I need a privacy policy for a small app?

If you collect personal data such as email addresses, you very likely need one, and laws like the GDPR set out what it must say. This is general information, not legal advice; check the rules where you and your users are.

Why are my app’s emails going to spam?

Usually missing SPF, DKIM or DMARC records on the sending domain, or sending from a domain different from the one in the From address. Add the DNS records your email provider gives you and test with fresh Gmail and Outlook addresses.

Should I launch on a free hosting plan?

For a small test with friends, possibly. For real users, check that the plan allows commercial use, doesn’t pause or sleep when idle, and includes backups.

What is the most common security problem in AI-built apps?

Missing access checks on the backend: the interface hides other users’ data, but the server still returns it when asked directly. It matches the top category on the OWASP Top 10 for 2025, Broken Access Control.

Sources