Real reasons and concrete fixes. AI optimizes for a working demo, not a production system. With 15–30 silent architectural decisions per feature at ~70% accuracy each, the probability of ALL being correct is practically zero.
“It works on my machine” is the oldest joke in software engineering. With AI-generated apps, it’s not a joke — it’s the default state. AI doesn’t think about production. It doesn’t know what a load balancer, connection pool, or secrets manager is. It sees only one thing: your local context, your file, your attempt to run it.
When AI builds a feature, it makes 15–30 silent architectural decisions: which database, how to connect to an API, where to store keys, how to handle errors. Each decision has roughly a 70% chance of being correct. But for the entire feature to work in production, all decisions must be correct. The probability? With 20 decisions: 0.7^20 = 0.08%. Practically zero.
This article covers the six most common reasons AI apps work locally and crash in production — with concrete examples and fixes. If you’re building with Cursor, Bolt, Lovable, Replit, or any other AI tool, this guide is for you.
This is the most obvious and simultaneously most common reason for production failures: configuration that only works locally. Your .env file on your laptop has real API keys, correct URLs, working secrets. In production? Placeholders, missing variables, or entirely different addresses.
AI never thinks about configuration management — it only sees local context. When it generates code that connects to an API, it writes http://localhost:3000 directly in the code. When it needs an API key, it creates a variable with a default value. When it builds a database URL, it hardcodes the connection string.
Typical problems:
http://localhost:3000/api instead of an environment variable. Works locally, points to nowhere in production..env file. You need to set variables in your hosting panel (Vercel, Railway, Render).http://, production requires https://. Mixing protocols causes browser blocking (mixed content) and CORS errors.Your local .env has real keys. Production might have placeholders, wrong URLs, or missing secrets. AI never thinks about config management — it only sees local context.
Externalize ALL configuration. Every URL, every key, every secret should come from an environment variable — never from source code. Use a secrets manager (e.g., Doppler, AWS Secrets Manager, Vercel Environment Variables). Create an .env.example file with the name of every required variable (without values) and add it to the repository as documentation.
AI loves SQLite. It’s simple, requires no server, it’s just a file. Perfect for a prototype. The problem? Serverless platforms (Vercel, Netlify Functions, AWS Lambda) don’t support SQLite because each request can hit a different instance — there’s no shared filesystem.
But the database isn’t just the engine. It’s a whole set of assumptions AI makes silently:
AI uses SQLite because it requires no server. But serverless platforms break SQLite — each request can hit a different instance with no shared filesystem. Queries that work on 50 rows take 30 seconds on 50,000 without indexes.
Use PostgreSQL or MySQL in production. Configure connection pooling (PgBouncer, Supabase has it built-in). Add indexes on columns used in WHERE and JOIN. Plan a migration strategy — use a tool like Prisma Migrate, Drizzle, or plain SQL files with versioning. Never modify your production schema manually.
A Georgetown CSET study found that 45% of AI-generated code contains security vulnerabilities. This isn’t a marginal problem — it’s nearly half of all code. And code that “works” on localhost doesn’t have to be secure.
A scan of 5,600 vibe-coded apps revealed over 2,000 high-impact vulnerabilities and over 400 exposed secrets. The platform Moltbook exposed 1.5 million API keys — Row Level Security on Supabase was never enabled. Lovable had inverted access control across 170 production apps (CVE-2025-48757): authenticated users were blocked while unauthenticated users got full access.
Problems I see regularly:
45% of AI code contains security vulnerabilities. Scan of 5,600 vibe-coded apps: 2,000+ high-impact vulnerabilities, 400+ exposed secrets. Lovable had inverted access control across 170 production apps.
Run an OWASP Top 10 audit. Enable Row Level Security on Supabase. Validate all inputs server-side (never trust the client). Scan your repository for exposed secrets (use gitleaks or trufflehog). Add rate limiting on all public endpoints. Move API keys from frontend to backend.
Your application works for the first 100 requests. Request 1,001 causes a crash — all database connections are exhausted. Why? Because AI never closed them. Every request opened a new connection, but none released it.
The same applies to file handles, WebSocket listeners, timers, and subscriptions. AI creates resources but doesn’t release them. On localhost you don’t notice because restarting the server every few minutes resets everything. In production the server runs continuously — and resources run out.
Even worse are silent failures:
try/catch blocks — payment fails, webhook doesn’t fire, but the user sees no error. Data disappears silently.Database connections that are never closed. File handles left open. WebSocket listeners never cleaned up. Works for the first 100 requests — request 1,001 crashes because all connections are exhausted.
Add error boundaries on the frontend (React: ErrorBoundary). Add a global error handler on the backend (process.on('uncaughtException')). Deploy structured logging (Sentry, LogRocket, Pino). Close database connections after use (or use connection pooling). Clean up listeners and timers in useEffect cleanup. Load test — checking that it works once isn’t enough.
These aren’t theoretical threats. These are incidents that have already happened:
t3.micro costs differently than r5.4xlarge. Cost scaling is something AI never thinks about.plan instead of price), duplicate charges for 2 weeks before anyone noticed.AI promised 10x developers. Instead: juniors became prompt engineers, seniors became code janitors. The cost of fixing AI code often exceeds the cost of writing it from scratch.
The pattern repeats: AI generates code that looks good. It passes code review (because it’s readable). It passes tests (because it tests the happy path). Then it explodes in production because nobody checked performance under load, error handling, security, or infrastructure costs.
Before you deploy your application, go through these points. Every unmet point is a potential production failure. This checklist was built from dozens of AI app audits I’ve conducted for clients.
Because localhost is a perfect environment: same-origin (no CORS), zero network latency, dev mode masks warnings, you’re the only user (no race conditions, no load). In production every one of these conditions is different — and any of them can cause a failure.
Missing environment variables and hardcoded configuration. It’s trivial, but it accounts for the majority of “works locally, fails in production” issues. Your .env has keys — the production server doesn’t. AI hardcodes URLs in source code instead of using environment variables.
Simple question: if you can’t answer “what happens when X fails?” for every critical path, your app is not ready. What happens when the database is unavailable? When the Stripe API returns an error? When 100 users click “Buy” at the same second? If you don’t have answers — you have work to do.
Usually no. Start with an audit. Identify critical gaps (security, database, configuration). Fix them point by point. A full rewrite only makes sense when the architecture is fundamentally flawed — but in most cases you can fix existing code iteratively without losing the work done so far.
Platform doesn’t equal production-ready. Vercel and Netlify are great hosting tools, but hosting alone isn’t “production.” You still need proper CORS configuration, monitoring, error handling, security, a proper database, and load testing. The “Deploy” button is the beginning, not the end.
We’ll help you identify and fix every one of these issues. Audit, fix, deploy — from prototype to production.
Book a free call →