20 Mistakes That Break Apps in Production (and How to Avoid Them)

An app that "works" on the developer's screen and an app that's ready for production are two different things. Between them sits an invisible layer: security, performance under load, reliability when something goes wrong, and the code quality that lets you fix things without breaking everything else. Code generators and no-code tools optimize for the first thing — the demo that works. They almost never think about the second.

The outcome is always the same: a flawless demo, then a crash at the first traffic spike, a $500 cloud bill overnight, or worse, a data breach. Here are the 20 mistakes we see most often when we take over an MVP to make it production-ready — sorted into four families, from the most critical to the most subtle.

🔒 Security: the flaws that cost the most

This is the densest block, and that's no accident. A performance flaw slows your app down; a security flaw can cost you every user account, your GDPR compliance, and your reputation in a single night. Here are the nine we encounter most.

1. No rate limiting on API routes

With no cap on requests per user, anyone can hammer your backend in a loop. Best case, your app slows down; worst case, you wake up to a $500 cloud bill because a script called your email endpoint or your LLM API 100,000 times overnight.

At App Studio: we apply per-IP and per-user rate limiting on every exposed route, with caps tuned to the real cost of each endpoint.

2. Auth tokens stored in localStorage

Storing an auth token in localStorage makes it readable by any JavaScript running on the page. A single XSS flaw — a compromised third-party script, a poorly filtered input — and the attacker reads every token, and therefore every account.

At App Studio: tokens live in httpOnly, Secure cookies, invisible to JavaScript, with refresh-token rotation.

3. No sanitization of form inputs

Yes, SQL injection still works in 2026 — specifically on apps where nobody validated or escaped user input. One naïve search field, and the attacker can read or wipe your database.

At App Studio: parameterized queries everywhere (never SQL string concatenation), server-side schema validation, and systematic output escaping.

4. API keys hardcoded in the frontend

A secret key sitting in frontend code is readable by anyone who opens the browser's "Network" or "Sources" tab. As a rule, it gets found and exploited within 48 hours of launch.

At App Studio: no secret key ever touches the client. Every sensitive call goes through a backend or edge function that holds the secrets server-side.

5. Stripe webhooks without signature verification

If you don't verify the signature on Stripe webhooks, anyone can send a forged request to your endpoint and fake a successful payment. The result: subscriptions activated without a single cent being charged.

At App Studio: every webhook (Stripe and the rest) is verified against its signature and secret before any processing happens.

6. Sessions that never expire

A session with no expiry is a stolen token that grants lifetime access. A lost device, an unlucky link share, and the account stays open indefinitely.

At App Studio: short-lived access tokens, revocable refresh tokens, and forced logout on password change.

7. Password-reset links that don't expire

A reset link that's valid forever is a permanent way in. An old email recovered from a compromised inbox is enough to take over the account months later.

At App Studio: single-use reset tokens that expire in 15 to 30 minutes and are invalidated the moment a new one is requested.

8. No CORS policy

Without a strict CORS configuration, any website can call your API from your users' browsers. That's an open door to cross-site attacks and data exfiltration.

At App Studio: an explicit allowlist of permitted origins, never a wildcard * on authenticated routes.

9. Admin routes with no role check

Hiding an "admin" button in the UI protects nothing: if the backend route doesn't check the role, any logged-in user can call it directly and reach the admin panel.

At App Studio: server-side authorization checks on every sensitive route, plus Row Level Security on the database so access is enforced all the way down to the data layer.

⚡ Performance & scalability: what breaks at 1,000 users

These mistakes are sneaky: everything runs perfectly in the demo and for the first few weeks. Then traffic climbs, and the app that responded in 200 ms suddenly takes 8 seconds — or falls over entirely.

10. No indexes on queried columns

A query with no index scans the whole table on every call. Fine with 100 rows, catastrophic with 100,000: the database spends its time scanning, and response times explode as soon as you have real users.

At App Studio: we index every column used in a filter, a sort, or a join, and we profile slow queries before going to production.

11. No pagination on database queries

A SELECT * with no LIMIT loads the entire table into memory. With a few hundred records, nobody notices; with tens of thousands, the query saturates the server's RAM and takes the app down.

At App Studio: pagination by default on every list (cursor or offset), with hard caps on page size.

12. Images uploaded straight onto the app server

Serving images from your app server instead of a CDN stacks two problems: 8-second load times for distant users, and a bandwidth bill that climbs fast. Your app server was never meant for this.

At App Studio: dedicated object storage (S3, Supabase Storage) served through a CDN, with resizing and modern formats (WebP/AVIF).

13. No database connection pooling

Without a connection pool, every request opens and then closes its own connection to the database. At the first traffic spike, the number of concurrent connections exceeds the database limit — and everything collapses at once.

At App Studio: connection pooling configured (PgBouncer or a managed pooler) and sized for the expected load.

🛡️ Reliability: knowing when it breaks, and limiting the damage

The question isn't if something will go wrong, but when. The difference between a pro team and a patched-together MVP is that a pro team knows it will happen and prepares the app to detect it, contain it, and recover from it.

14. No error boundaries in the UI

With no safety net, a single render error crashes the entire interface: the user is left staring at a blank screen. And a user facing a blank screen generally doesn't come back.

At App Studio: error boundaries that isolate failures to a single component, with a clean fallback state and a clear message instead of a dead screen.

15. No environment variable validation at startup

A missing or mistyped environment variable, and the app boots anyway — then breaks silently in the middle of a user action, often with no explicit error. You lose hours hunting for it.

At App Studio: all environment variables are validated at boot against a typed schema. If a key is missing, the app refuses to start and says so clearly.

16. No health check endpoint

Without a health check endpoint, your app can go down without anyone knowing. You find out from an unhappy customer — the worst possible way to discover an incident.

At App Studio: a /health endpoint that checks the database and critical dependencies, wired into monitoring that alerts before users do.

17. No logs in production

When something breaks and there are no logs, you're blind: no idea where it came from, when, or which user it hit. Debugging turns into guesswork.

At App Studio: centralized structured logs and error tracking (Sentry-style), with request IDs to trace each incident end to end.

18. No database backup strategy

A failed migration, an accidental deletion, and with no backup, all user data is gone. There's no "undo" button in production.

At App Studio: automated backups, point-in-time recovery enabled, and — crucially — restores actually tested to confirm the backup is genuinely usable.

🧱 Code quality: the debt that slows everything down

These mistakes don't crash the app right away, but they turn every future fix into a minefield. This is the debt that makes a "quick" change take three days and break three other things along the way.

19. Emails sent synchronously inside request handlers

Sending an email directly inside a request handler ties the response time to the SMTP server's speed. A sluggish email provider, and the whole app starts to hang — when the email should have gone out in the background.

At App Studio: emails and other heavy tasks go through a queue processed asynchronously, with retries. The request responds immediately.

20. No TypeScript on AI-generated code

This is the most dangerous blind spot in AI-generated apps. The model writes confident, fluent code… that's sometimes wrong, with implicit types that hide the bugs. With no typing, those errors only surface in production, on a case nobody tested.

At App Studio: strict-mode TypeScript end to end, types shared between frontend and backend, and a CI that refuses to merge code that doesn't compile. AI stays an excellent copilot — as long as a system forces it to tell the truth.

From demo to production: what actually changes

None of these 20 mistakes is exotic. They're engineering fundamentals — known, documented, solved for years. The problem isn't that they're hard; it's that a code generator or a no-code tool used without judgment never adds them on its own. Nobody "decides" to leave a flaw in: it's simply there by default, because nothing filled the gap.

That's exactly the line between a demo and a product. And it's where a real engineering team makes the difference: not by writing the cleverest code, but by methodically checking each of these invisible layers before anything reaches real users.