The 33-point launch checklist tells you what to check before you launch. A few of those checks get the same follow-up question every time: "OK, but how?"
Here are five answers. Each one is something you can do or copy today, without being a developer. No signup, no email, nothing to download.
- A 10-minute Firebase open-data check
- A 15-minute Stripe payment test
- Which spending limits actually stop the spending
- What to do in the first hour after a key leaks
- An account ownership sheet
1. A 10-minute Firebase open-data check
There's already a Supabase check on this blog. If your app uses Firebase instead, the problem is the same: your app's web page talks to the database directly, and the only protection is the security rules.
Everything you need for this test is in your app's firebaseConfig, which every visitor can already see: the projectId, the storageBucket, and, if you use it, the databaseURL. Run these from a terminal, logged out, with no key at all.
Firestore. Replace the project ID and use a collection name from your app, such as users or orders:
curl "https://firestore.googleapis.com/v1/projects/YOUR_PROJECT_ID/databases/(default)/documents/YOUR_COLLECTION?pageSize=5"Realtime Database, if you use it. The shallow option lists only the top-level names, not the data:
curl "YOUR_DATABASE_URL/.json?shallow=true"Storage, which lists uploaded files if the rules allow it:
curl "https://firebasestorage.googleapis.com/v0/b/YOUR_STORAGE_BUCKET/o"- You get documents, names or files back: that data is open to the whole internet. Fix it before anything else.
- You get
PERMISSION_DENIEDor a 403: good. That's what a stranger should see.
Then open the Rules tab for Firestore, Realtime Database and Storage in the Firebase console, and look for three patterns:
allow read, write: if true;means anyone can do anything.if request.time < timestamp.date(...)is the "test mode" rule Firebase sets up for new projects. It's wide open until that date, and then it locks everyone out, including your app.if request.auth != nullon its own means any logged-in user can read every other user's data. Anyone can sign up, so this is barely better than open. A safe rule also checks that the record belongs to that user, for examplerequest.auth.uid == userId.
The Rules Playground in the console lets you test a rule as a logged-out visitor or as a specific user before you publish it.
2. A 15-minute Stripe payment test
Most AI-built apps have only ever been paid with a card that works. These tests cover the other cases. Run them in Stripe's test mode, on a preview or test version of your app.
Send a fake "payment succeeded" message. Your app has a webhook address that Stripe calls when someone pays, often something like /api/webhooks/stripe. Send it a message that didn't come from Stripe:
curl -X POST "https://YOUR-TEST-SITE/api/webhooks/stripe" \
-H "Content-Type: application/json" \
-d '{"type": "checkout.session.completed", "data": {"object": {}}}'Your server should refuse it with an error, usually a 400, because it has no valid Stripe signature. If it answers 200, anyone can tell your app they've paid.
Skip the payment. Copy the address of your "thank you" page after a test purchase, log in with a different account that hasn't paid, and open it. The paid feature should stay locked.
Use cards that fail. Stripe has test card numbers that fail on purpose. Use any future expiry date and any CVC:
4000 0000 0000 0002is declined. Check the customer sees a clear message and gets nothing for free.4000 0000 0000 9995fails with "insufficient funds".4000 0000 0000 0341can be saved to an account, but every charge on it fails. Use it to start a subscription that will fail on renewal.
Fast-forward to the renewal. You don't have to wait a month. Stripe's test clocks (in the test-mode dashboard, under Billing) let you create a customer, start a subscription and move time forward. Do it with the 0341 card and check that access ends when the payment finally fails. Then cancel a subscription and refund a payment, and check access again after each.
If access is still there after a failed payment, a cancellation or a refund, your app isn't listening to the right webhook events. The ones to look for are invoice.payment_failed, customer.subscription.deleted and charge.refunded.
3. Which spending limits actually stop the spending
"Set a spending limit" is on every checklist, including mine. The catch is that many settings called a budget or a limit only send you an email. The bill keeps growing while you sleep.
Menus move around, so look for these by name rather than by path. Check each one in your own account:
- OpenAI and Anthropic. Both let you set monthly limits or alerts, and both can run on prepaid credits. On prepaid credits, your balance is the real cap. That only works if auto-recharge is off, or capped at an amount you can afford to lose. Separate projects or workspaces with their own keys and limits stop one feature from using up the whole budget.
- Supabase. The free plan stops at its limits. On paid plans, look for the spend cap in billing. With it on, you aren't charged for most usage above your plan. Turning it off removes that ceiling.
- Vercel. On the paid plan, Spend Management lets you set an amount and choose to pause your projects when you reach it. Pausing takes your site down, so decide in advance which is worse.
- Google Cloud and Firebase on the Blaze plan. Budgets only send alerts. They don't stop spending. Stopping it automatically means building something that turns off billing when the alert fires. For most small apps, the practical protection is rate limits and login checks in front of anything expensive, plus an alert sent to an address someone actually reads.
- AWS. Budgets alert by default too. Set one anyway, at a low amount, so you hear about surprises within a day rather than at the end of the month.
- Email and SMS providers. Sign-up forms that send a text message are a favourite target for fraud that runs up SMS costs. Check whether your provider lets you block countries you don't serve, and do it.
Whichever you use, test the alert once. Set a budget just above what you've already spent this month, and check the email arrives, and not in spam.
4. What to do in the first hour after a key leaks
You've found a secret key in your browser code, in your GitHub history, or in a screenshot you posted. Do these in this order. The order matters.
- Replace the key before anything else. Create a new key in the provider's dashboard, put it in your app, and revoke the old one. Don't investigate first. Every minute the old key works is a minute someone can use it. On Supabase, newer secret keys can be revoked one at a time. The older
service_rolekey changes only when you rotate the project's JWT secret, which also logs every user out, so do it at a quiet moment, but do it today. - Remove it from where it leaked. Deleting it from your code doesn't remove it from your Git history, and bots scan public repositories for keys within minutes. That's why step 1 comes first: once the key is revoked, the copy in your history is useless.
- Check what it was used for. Look at the provider's usage page or logs for the time the key was exposed. Unusual spikes in AI usage, payments or refunds you didn't make, or database activity at odd hours are the signs.
- Put a spending limit on that provider, if there wasn't one. See section 3.
- Write down what happened. Which key, how long it was exposed, what it could reach, and what the logs showed. Two paragraphs is enough.
- Decide whether you have to tell anyone. If the key could reach personal data, and you're in the EU or UK, a data breach usually has to be reported to your data protection authority within 72 hours, and sometimes to the people affected. Even when you don't have to report it, GDPR expects you to keep a record of it, which is the note from step 5. This isn't legal advice: if personal data may have been read, get some.
A key that can only do something harmless, like Stripe's publishable pk_ key or Supabase's public anon key, isn't a leak. Those are meant to be public. Secret keys are the ones to worry about.
5. An account ownership sheet
An AI-built app quietly depends on eight or ten accounts. Often nobody has written down which ones, whose name they're in, or whose card pays for them. That's fine until someone is ill, leaves, or forgets a renewal and the domain expires.
Copy this into a shared document or spreadsheet and fill it in. Keep the passwords in a password manager, not in this sheet and not in your code.
Service | Used for | Login email | Owner | Backup person | Paid by | Renews on
------------------|-------------------|-------------|-------|---------------|---------|----------
Domain registrar | the web address | | | | |
DNS | where it points | | | | |
Hosting | runs the app | | | | |
Database | stores the data | | | | |
Code (GitHub) | the source code | | | | |
AI builder | Lovable, Bolt ... | | | | |
AI provider | OpenAI, Anthropic | | | | |
Payments | Stripe | | | | |
Email sending | account emails | | | | |
Error tracking | tells you when | | | | |
| it breaks | | | | |When it's filled in, look for three things:
- Any account on someone's personal email. Move it to a company address, or one you control.
- Any account with no backup person. Add a second login, or at least make sure the recovery email and phone number aren't only one person's.
- Any renewal date in the next three months. Turn on auto-renew for the domain. An expired domain takes your app and your email down at the same time.
If a freelancer or agency built your app, ask them to fill this in as part of the handover, before the final invoice is paid.
Want the rest?
These five go deeper on single items. For the whole picture, start with the 33-point launch checklist, then let your AI coding tool run the free launch-readiness check on your code. If you're a business owner rather than the builder, the eight questions to ask are written for you.
And if one of these turned up something you aren't sure how to fix, that's what I do. A quick check looks at the one area that worries you most, and the launch-readiness audit covers the whole app. Or tell me what you found.