Ship checklist for AI-built apps

Run through this before you put an AI-built app in front of users. Each check is one line, with a short note on why it matters and how to confirm it.

Secrets and security

1. No API keys or secrets in client code or the repo.
Why: anything shipped to the browser can be read.
Check: search the built bundle and git history for key prefixes.
2. Server-side checks on every write.
Why: the UI hiding a button doesn’t stop a direct request.
Check: call each write endpoint without the UI and confirm it’s refused when it should be.
3. Database access rules are on (for example, row-level security).
Why: default-open tables let any signed-in user read others’ data.
Check: query another user’s rows with a test account.
4. User input is validated on the server.
Why: client checks are easy to skip.
Check: send an empty, oversized, and malformed value to each form endpoint.

5. Password reset and email change work end to end.
Why: these are the flows most often left half-built.
Check: run each one with a test inbox.
6. Signed-out users can’t reach signed-in pages or data.
Why: a missing route guard exposes private pages.
Check: open private URLs in a private window.

7. Paid access is granted from the payment provider’s webhook, not the success page.
Why: a success URL can be opened without paying.
Check: visit it directly with no purchase.
8. Refunds and cancelled subscriptions remove access.
Why: otherwise access outlives payment.
Check: cancel a test subscription and reload.
9. Test mode is off and live keys are set in production only.
Why: with test keys in production, customers can’t actually pay.
Check: confirm which keys each environment uses.

10. Errors are logged somewhere you’ll see them.
Why: users rarely report bugs; they leave.
Check: throw a test error in production and find it.
11. The app shows a useful message when a request or AI call fails.
Why: AI and third-party calls fail and time out.
Check: break the key or network and watch the UI.
12. Rate limits or spend caps on paid APIs.
Why: one loop or abusive user can run up a large bill.
Check: confirm a cap is set in each provider’s dashboard.
13. You can restore the database.
Why: a backup you’ve never restored may not work.
Check: restore to a scratch database once.

14. A privacy page says what you collect and which services receive it.
Check: compare it with your analytics and third-party scripts.
15. Users can ask to have their account and data deleted, and you know how to do it.
Check: delete a test account fully.
16. Each launch-blocking item has acceptance criteria you’ve checked.
Why: “done” should mean something testable.
Check: every item above is ticked or has a ticket.

Free. No sign-up. It’s a markdown file you can paste into your repo or tracker.