Is your app ready for real users?

Every secret and API key (Stripe, database, third-party) lives only in server-side environment variables — none are in the frontend bundle or committed to the repo.

Every admin or privileged page and API endpoint checks authentication and authorization on the server — not just by hiding the button in the UI.

If you use Supabase, Firebase or a SQL database, row-level security (or equivalent rules) is ON, with policies scoped to the user — not left off, in test mode, or USING (true).

In any multi-user or multi-tenant feature, the server decides which data a request can see from the session — it never trusts a user_id, org_id or team_id sent by the client.

Your lists, feeds and dashboards are paginated and the queries are indexed — they won’t load an entire table or fire a query per row as data grows.

Endpoints that cost money or call third parties (LLM calls, emails, sign-ups) have rate limiting or abuse protection.

Production and development use separate credentials and databases, and you have a backup or a way to restore data if something goes wrong.

User input is validated on the server and errors are handled — the app doesn’t crash or show a raw stack trace when it gets unexpected input.

You can roll back a bad deploy quickly, and you don’t push untested code straight to production.

Your dependencies are reasonably current and you’d notice if one had a known vulnerability.

You’ve tested the unhappy paths — wrong password, expired session, duplicate submit, empty and error states — not just the demo happy path.

Someone other than you — and other than the AI that built it — has actually read the code for security and correctness.