Smarter Foundry · Updated
How to use this list
Go through it with your AI tool. Ask it to check one item at a time against your codebase and show you the file and line it's basing its answer on. Coding agents are good at finding these problems when asked directly, and they often don't raise them unprompted. Verify anything that matters yourself.
Accounts and access
- Every server route that reads or writes user data checks who is asking. Hiding a button in the interface doesn't count.
- Changing an ID in a URL or request doesn't show another user's records.
- If you use Supabase or Firebase, database rules restrict every table or collection to the right users.
- Password reset, email verification and sign-out work on your production domain, not just in preview.
- Admin pages and actions are restricted on the server.
Data
- Automatic backups are on, and you've restored one at least once.
- Schema changes go through migrations, not hand edits to the production database.
- Seed users, test records and mock responses are gone from production.
- You can delete a user's account and their data when asked.
Secrets and configuration
- No secret keys in the repository or in front-end code. Check the Git history too; deleting a key in a later commit doesn't remove it.
- Test and live keys are separate, and production uses the live ones.
- Production settings live in your host's environment variables.
Payments
If you charge money:
- Your database updates from Stripe's webhooks, not from the page the customer lands on after checkout. People close tabs.
- Webhook signatures are verified.
- Receiving the same webhook twice does no harm.
- Failed renewals, cancellations and refunds change what the user can access.
Errors and visibility
- Error tracking, such as Sentry, runs on both the server and the browser.
- Logs are searchable when a user reports a problem.
- An uptime check alerts you when the site goes down.
Deploys
- Deploying is one command or a merge to main, not a sequence of steps you have to remember.
- You can roll back to the previous version quickly.
- Before each deploy, something checks the flows that make money: sign-up, sign-in, checkout and the core feature. Automated tests are best; a written checklist you actually follow is better than nothing.
Abuse and cost
- Sign-up, sign-in, password reset and contact forms are rate limited.
- Calls to paid APIs, such as AI models, SMS and email, are limited per user.
- Each paid provider has a spending limit or billing alert set.
Performance basics
- Key pages load acceptably on a phone over a mobile connection.
- Database queries that run on every page load use indexes.
- Lists that grow over time are paginated.
What can wait
You don't need these before your first users: full test coverage, a microservice split, multiple regions, a polished admin dashboard, or a design system. Launch with the list above done, and add the rest once you know what users actually do.
For the launch itself, including domains, email deliverability and what to watch on the day, see the launch checklist. For a closer look at access rules and secrets, see the security checklist.