Getting an AI-built app ready for production: a checklist

AI can get you a working app in a weekend. It usually can't get you a safe one. In 2025, Veracode's testing found that close to half of AI-generated code samples shipped with a known security weakness, and most were the boring, preventable kind.

I get called in right after the fun part ends. The demo works, the first real users show up, and suddenly there are signups you didn't plan for, data you didn't protect, and a database almost anyone can read. This is the list I actually run through before I'd let an AI-built app take real traffic. Work it top to bottom. Most apps fail in the first three sections.

Auth and access

• Check who can call what. AI tools love to ship API endpoints with no real authorization, just a hidden button in the UI. Hiding a button is not security.
• Turn on row-level access. On Supabase or Firebase, confirm row-level security is actually on and scoped per user. The default of "any logged-in user can read everything" is the single most common hole I find.
• Try the obvious attack. Change an id in the URL and see if you can read someone else's record. That one bug is everywhere.

Secrets and config

• No keys in the frontend. Anything in a NEXT_PUBLIC or VITE variable is public. API keys, admin tokens and service credentials do not belong there.
• Rotate whatever leaked. If a secret ever sat in client code or a public repo, treat it as burned and rotate it.
• Split your environments. Dev and prod should not share keys or a database.

Data and privacy

• Know what personal data you store and why. If you have EU users, this is not optional.
• Encrypt in transit and at rest. HTTPS everywhere, real database encryption, and no plaintext passwords, ever.
• Have a delete path. Users can ask you to remove their data, so you need a real way to do it.

Money paths

• Validate on the server. Never trust a price, a quantity or a "paid" flag that came from the browser.
• Make webhooks idempotent. Payment providers retry. If your code double-credits on a retry, you'll find out the expensive way.
• Log every money event. You want a clear trail when something looks off.

Reliability and observability

• Add error tracking. Something like Sentry, so you hear about failures before your users post about them.
• Set rate limits. AI-built apps almost never have them, and one script can take you down or run up a huge bill.
• Watch the bill. Model calls and serverless functions get expensive fast under real traffic.

Scaling, the part that bites later

• Find the query that dies. There's usually one unindexed query that's fine with 50 rows and falls over at 50,000. Find it before your users do.
• Cache the expensive stuff. The model call you make on every page load is a problem waiting to happen.
• Don't store files in the database. Use object storage.

Rewrite, refactor, or just harden?

Most AI-built apps don't need a rewrite. They need a few days of hardening on the list above, then a plan to replace the riskiest parts over time. A full rewrite is the right call only when the data model is wrong at the core, or the stack can't carry where you're going. When in doubt, harden first and decide later.