Your AI tool built the app in a weekend. Lovable, Bolt, Cursor, v0, Replit — they are genuinely good at getting from an idea to something that runs. Then you try to put real users on it, and the same handful of things break every single time.
This isn't an "AI code is bad" post. The code is often fine. The problem is that these tools optimize for the demo — the thing that works on your laptop, in one browser tab, with one user (you). Production is a different test: many users, hostile inputs, real money, 2am outages, and nobody watching. That operating layer is the part the generator skips, because it isn't visible in the preview.
Here's the checklist I run on every AI-built app before I'd let real users depend on it. If you built something with one of these tools, go down this list honestly.
1. Secrets in the client bundle
The number one finding. API keys, database URLs, and service tokens end up in the frontend bundle or committed to the repo. Open your deployed app, view source, and search the JS for sk_, key, secret, postgres://. If your Stripe secret key or Supabase service-role key is reachable from a browser, nothing else on this list matters yet — fix that first and rotate the keys.
2. No rate limiting on auth and payment endpoints
Generated apps almost never rate-limit /login, /signup, password reset, or checkout. That's how you wake up to credential-stuffing, thousands of junk signups, or a card-testing attack running through your Stripe account. A basic per-IP limit on the sensitive routes is the minimum.
3. Row-level security that was never actually proven
If you're on Supabase or any multi-tenant Postgres, the demo works because you are the only tenant. RLS policies are easy to write and easy to get subtly wrong. Test it the mean way: log in as user A, grab a record ID that belongs to user B, and request it directly. If you get B's data back, your data boundaries are open.
4. CORS wide open, CSRF missing, weak sessions
Access-Control-Allow-Origin: * on an authenticated API. No CSRF protection on state-changing forms. Session tokens that don't expire or rotate. Each of these is a one-liner to check and a real hole to leave open.
5. No input validation — injection surface
The generated form posts straight to the database or into a template. SQL injection, XSS, and prompt injection (if there's an LLM in the loop) all live here. Every input that reaches a query, a page, or a model needs validation and escaping — not "the ORM probably handles it."
6. No backups, no restore, no rollback
"We have backups" and "we have tested restoring from backups" are different sentences, and only one of them saves you. Plus: when a bad deploy ships, can you roll back in one command, or are you editing production live while users watch? If you don't know, you don't have it.
7. No monitoring, alerting, or on-call
The app is down and you find out because a customer emails you. There's no uptime check, no error tracking, no alert. For an app real people pay for, "I check it sometimes" is not a monitoring strategy.
8. Dependency and supply-chain risk
AI tools pull in a lot of packages fast. Unpinned versions, abandoned libraries, known CVEs sitting in your package.json. Run npm audit (or the equivalent) once and read the output — it's usually sobering.
9. Error handling: the 500 you can't explain
"The contact form sometimes 500s and I have no idea why" is the most common sentence I hear. Unhandled promise rejections, missing try/catch around external calls, no structured logging. When something breaks, can you find out what, or do you just redeploy and hope?
10. Cost-to-scale you haven't modeled
The free tier is fine at 10 users. What happens at 10,000? Unbounded queries, no caching, N+1 database calls, an LLM call on every page load. The app that costs $0 today can cost $4,000/month at modest scale — or fall over entirely.
11. Auth beyond the happy path
Login works. But: password reset, email verification, session expiry, "log out everywhere," account deletion, and what happens when a token is stale. The demo only ever walks the happy path. Users don't.
12. No CI, no staging, no tests
Every change goes straight to production by hand. There's no pipeline, no staging environment, and no test that would catch a regression before your users do. This is the one that turns every future change into a gamble.
None of this means you shouldn't have used the AI tool
You should have. Getting to a working prototype in days instead of months is a real advantage — it's how you find out if the thing is worth building at all. The mistake is treating "it runs" as "it's ready." Those are separated by exactly the list above, and none of it is glamorous work, which is precisely why the generators skip it.
Want a second set of eyes — for free?
I do this for a living (managed hosting plus an on-call engineer for AI-built apps), so I built a free tool for the top of this list. Paste your deployed app's URL or GitHub repo and it runs a safe, automated first-pass snapshot — reachability, HTTPS, redirects, exposed signals, obvious launch blockers:
Free automated snapshot: https://primeautomationsolutions.com/app-readiness-review.html
If you want the deeper version, send a link and I'll send back a one-page audit covering the 12 things above — specific to your app, within 48 hours, no sales call and no drip campaign:
Free production readiness audit: https://primeautomationsolutions.com/production.html
Either way, run the checklist. Your app works on your laptop. The only question that matters is whether it works at 2am when someone you've never met is depending on it.
— Erik, Prime Automation Solutions. Veteran-owned, built in Atlanta. I take vibe-coded apps to production for a living.
Top comments (0)