Is Your AI-Built App Ready for Production? A 15-Point Checklist

You described your idea, an AI tool built it, and now there's a working app on your screen. Sign-up works. The dashboard loads. Payments go through in test mode. It feels ready.

It probably isn't. Not because AI tools are bad (I use them every day), but because they're optimised to make the thing work, not to make it safe, fast, and maintainable once strangers start using it. Those are different goals, and the gap between them is where most vibe-coded apps get into trouble.

I wrote about the bigger picture in Vibe Coding Apocalypse. This post is the practical follow-up: the checklist I run through when I look at an AI-built app before it goes live. You don't need to be a developer to use most of it. If you can't confidently tick an item, that's your sign to dig deeper or get a second pair of eyes.

Prefer to tick boxes as you go? Take the interactive version of this checklist. It takes about 3 minutes and gives you a score plus a prioritised fix list.

Security: The Things That Get You in the News

1. No secret keys in the browser

Open your app, right-click, choose View Page Source or open the browser dev tools, and search for sk_, secret, api_key, or the name of any service you use (OpenAI, Stripe, Supabase service role).

If a secret key shows up there, anyone can copy it and run up your bill or read your data. Public keys (like Stripe's pk_ or Supabase's anon key) are fine to expose. Secret keys must only live on the server.

AI tools get this wrong a lot, because putting the key directly in the frontend is the quickest way to make a demo work.

2. Database access rules are switched on

If your app uses Supabase or Firebase, the database is often reachable directly from the browser. That's by design, but it means access rules are the only thing stopping one user from reading another user's data.

• Supabase: every table should have Row Level Security (RLS) enabled, with policies that limit rows to their owner.
• Firebase: your security rules shouldn't contain allow read, write: if true.

A quick test: log in as User A, copy a request from the network tab, change the ID to one that belongs to User B, and send it again. If you get User B's data back, you have a problem.

3. Permission checks happen on the server

Hiding the "Delete" button from non-admins isn't security. If the server doesn't also check who's asking, anyone who finds the endpoint can call it.

Every action that changes or reveals data should check, on the server: is this person logged in, and are they allowed to do this to this specific record?

4. Secrets aren't in your Git history

Even if you've moved your keys into environment variables, they may still sit in an old commit. If your repo was ever public, or might become public, assume any key that was committed has leaked. Rotate it (generate a new one and revoke the old one) and add .env files to .gitignore.

5. User input is validated

Forms should check what they receive on the server, not just in the browser: lengths, formats, allowed values. Anything that ends up in a database query, an email, or rendered back on a page needs to be handled safely. Modern frameworks protect you from a lot of this by default, but AI-generated code sometimes works around those defaults to get a feature working.

Reliability: The Things That Break at 2 AM

6. You'll know when something breaks

If an error happens and nobody sees it, it'll keep happening. Set up error tracking (Sentry, PostHog, or similar) before launch, so you find out about crashes from a notification instead of an angry email.

7. Rate limits exist on expensive or sensitive actions

Login, sign-up, password reset, contact forms, and anything that calls a paid AI API should limit how often one person can hit them. Without this, a single bot can drain your OpenAI credits overnight or brute-force your login page.

8. Your data is backed up, and you've tested restoring it

Check that backups are actually running. Then try restoring one, at least once. A backup you've never restored is a hope, not a plan.

9. Payments are confirmed by the payment provider, not the browser

If your app marks an order as paid because the browser said "payment succeeded", someone can fake that message. Stripe and similar providers send a webhook to your server to confirm payment. Your app should only unlock paid features after receiving and verifying that webhook.

10. Errors don't show your internals

When something fails, users should see a friendly message, not a stack trace with file paths, database names, or query details. Those details are a map for anyone looking to break in.

Performance: The Things That Make Users Leave

11. Pages load quickly with real data

Your app is fast with 10 test records. Is it fast with 10,000? AI-generated code often loads entire tables and filters them in the browser, or runs a separate database query for every item in a list. Both are invisible in testing and painful in production.

Run your main pages through PageSpeed Insights and load them with a realistic amount of data.

12. Images are compressed

A 5 MB hero image will make your landing page crawl on mobile. Resize and compress images, and use your framework's image component if it has one.

Maintainability: The Things That Slow You Down Later

13. The code follows one way of doing things

This is the one that bit me. When you prompt features at different times, the AI picks whatever pattern seems right in that moment. You end up with three ways of fetching data, two approaches to permissions, and components that almost-but-don't-quite match. Each one works, but every change becomes harder than it should be.

14. The core flows have tests

You don't need 100% test coverage. You do need automated tests for the flows that would hurt most if they broke: sign-up, login, payment, and whatever your app's main job is. Without them, every new feature is a gamble on breaking an old one.

15. Someone understands how it works

If the only "person" who understands your codebase is an AI chat history, you're one bad prompt away from a mess you can't untangle. Make sure there's at least a short README explaining how the app is structured, how to run it, and where the important pieces live.

How Did You Score?

Get your score instantly with the interactive checklist →

• 13 to 15: You're in good shape. Keep an eye on monitoring after launch.
• 8 to 12: Normal for an AI-built app. Fix the security items (1 to 5) before launch, then work through the rest.
• Under 8: Don't launch yet. The security items alone could put your users' data at risk.

AI Got You Here. Don't Let It Take You Over the Edge

AI tools have made it possible for more people than ever to build real products, and that's a good thing. But getting to "it works" is the first half of the job. The second half is making sure it keeps working, keeps your users safe, and doesn't fall apart the first time you need to change something.

If you went through this list and found more question marks than ticks, that's exactly what I help with. I'll review your AI-built app, tell you what's risky, and fix what needs fixing before your users find it for you.