Is Your App Actually Production-Ready? A Pre-Launch Check

Your app is production-ready when a stranger can't read your secrets, can't reach data they shouldn't, can't take you down or drain your budget with a simple script, can't learn your internals from an error message, and when you'll actually know within minutes if something breaks. "It runs and the demo works" is a different, earlier milestone. The gap between the two is a short, testable checklist — six layers, each with a question you can answer honestly with a yes or no. If any answer is no, you're not ready yet, and that's useful to know before launch day rather than after.

Why "it works" fools you

A demo exercises the happy path: you log in as the right user, click the right buttons, and everything responds. Production is the opposite — it's every path you didn't click, run by people who don't know or care about your intended flow. The checklist below is really a list of "unhappy paths" that a working demo never tests, turned into questions you can check off deliberately instead of discovering in the wild.

The six checks

Go through these in order. The first two are the ones that cause the worst headlines; don't skip ahead.

1. Secrets. Are all your API keys and credentials in server-side environment variables, with nothing sensitive in the code that reaches the browser? Test: search your repo and your built bundle for sk- and api_key. If anything shows up, you're not done.
2. Authorization. Does the server check who the user is and what they can do on every protected route and API call — not just the frontend? Test: can someone bypass a protected page by deleting JavaScript or hitting the API with curl? If yes, you're not done.
3. Rate limits. Are there per-user and per-endpoint request limits? Test: can one bad actor with a 10-line script take the app offline or hammer your endpoints? If yes, you're not done.
4. Cost ceilings. If your app calls AI APIs, are there per-user daily limits, per-tenant caps, and billing alerts? Test: can you state your worst-case bill if you go viral tomorrow? If you can't, you're not done.
5. Errors. Do production errors return sanitized messages, with no stack traces, schema details, or internal paths? Test: does triggering an error teach a user anything about your architecture? If yes, you're not done.
6. Observability. Do you have error tracking, uptime monitoring, and one dashboard you watch? Test: when something breaks at 3 a.m., will you know in minutes or hours? If hours, you're not done.

What each failure actually costs

These aren't theoretical. A hardcoded key in the browser gets scraped and used to run up charges on your account. A frontend-only auth check means anyone with the network tab can pull data you thought was private. No rate limit plus no cost ceiling means a single script can either take you offline or hand you a shocking API bill — sometimes both. Verbose errors hand an attacker a map of your internals to probe. And no monitoring means the way you find out about any of it is an angry user or a drained account, days later. The whole point of running the check before launch is to make those failures boring config changes instead of live incidents.

If you fail a check

Failing checks is the expected starting state for a vibe-coded app — the AI builder wasn't trying to pass them. Most fixes are a specific instruction you can hand back to the same tool that built the app, or a small config change. The secrets guide covers the highest-leverage fix in detail, and the how-to-secure-an-app-you-didn't-fully-write guide is written for exactly the non-expert case. For the full picture of what tends to break and why, the vibe-coding security guide ties all six layers together.

When you want the checklist as a packaged audit — each of the six layers with its testable question, plus the paste-back fixes and a monitoring template for Vercel, Cloudflare, AWS, and Supabase — that's the Vibe-Coded App Hardening Kit ($79). It gets you to roughly production-safe; a real penetration test and professional scanners are the separate, later step it deliberately doesn't replace.

If the app has an AI feature, that layer carries its own readiness question. The free LLM Security Audit asks 21 questions about the prompt, output and data-handling path and returns a verdict with the one thing to fix first. A self-assessment of design — not a penetration test, and the last stretch still wants a professional.