What I check before an AI-built app goes live
The first hour of a production readiness review: secrets, auth on every route, database access rules, model costs and the states nobody tested.
Apps built with Lovable, Bolt, v0, Cursor or Claude Code usually work. The happy path is fine, the UI looks finished, and the demo lands. What they rarely have is the layer that only matters once strangers start using them. These are the checks I run first, in this order, because each one is cheap to find and expensive to discover in production.
1. Secrets in the browser
Open the deployed site, open the network tab and search the JavaScript bundles for sk-, service_role, secret and the names of your providers. In Next.js, anything prefixed NEXT_PUBLIC_ is shipped to every visitor by design. A model API key or a Supabase service role key in the client means anyone can spend your money or read your whole database.
The fix is boring: move the call to a server route or server action, keep the key in server-only environment variables, and rotate the key that leaked. Rotation is the step people skip.
2. Auth on every route, not every page
A page that redirects logged-out users is not protection. The API route or server action behind it is a public URL that anyone can call with curl. I list every route handler and server action and check each one for two things: is there a session, and does this session own the record it is touching? The second check is where most bugs live. GET /api/invoices/123 returning someone else's invoice is the most common serious issue I expect to find.
3. Database access rules
If the frontend talks to the database directly (Supabase, Firebase), the access rules are the backend. I check that row-level security is on for every exposed table and that no policy is just true. I wrote up the Supabase side in more detail in Supabase row-level security, the step AI builders skip.
4. Unbounded model calls
Every route that calls a model needs a ceiling: a max_tokens (or equivalent) on the request, a rate limit per user and per IP, a cap on input size, and a step limit on anything agentic. Without them, one script in a loop turns into a bill. I also check that the model call happens after the auth check, not before it.
5. Webhooks and payments
Stripe and similar webhooks must verify the signature before trusting the payload. Otherwise anyone can post checkout.session.completed to your endpoint and give themselves a paid plan. Generated code often parses the body first and verifies later, or never.
6. The states nobody clicked
Slow network, empty list, expired session, model timeout, a provider returning a 529. I throttle the network, revoke the session mid-flow and force the model call to fail. Generated UIs tend to show a spinner forever or a blank screen. Real users see these states every day.
7. Personal data in logs and prompts
Check what is logged on the server and what is sent to the model provider. Full request bodies with emails, addresses or health details in the logs, or whole user records pasted into a prompt, are both a GDPR problem and a breach waiting for a leaked log file.
None of this means the app was built wrong. Building fast with AI tools is a sensible way to find out if anyone wants the product. These checks are the part that comes next, before real users arrive.
The output of a review is a list like this, ranked by severity, with the fix for each item. Most apps need a handful of targeted changes, not a rewrite.
Got a demo that needs to survive real users?
Tell me what you have and what has to ship, on a call or by email with a link to the repo or the live app. I'll tell you honestly whether I can help, and what I'd look at first.