An AI assistant can take you from a blank folder to a working app in an afternoon. What it does not do, as part of that same afternoon, is tell you whether the app can hold up against a real user typing something unexpected into a form, a dependency going down at 2am, or a thousand people showing up at once instead of you and your co-founder testing it on a laptop. That gap has a name (production readiness), and unlike "does it feel done", it can be checked item by item.
This list is organised around the four areas that tend to separate a working demo from something you can safely put your name behind: security, stability, performance and deployment. Three checks per category, twelve in total. None of them require a computer science degree to understand, and none of them require trusting the same model that wrote the code to also mark its own homework.
Security
1. Check for secrets committed to git history, not just your current .env file
A key that isn't in your working directory can still be sitting in commit history from three prompts ago, when the assistant hardcoded it "just to get things running" before you moved it to an environment variable. Search the full git log, not just the current file tree, and rotate anything that turns up.
2. Check that user input reaching a database or shell command is parameterised, not concatenated
String-built SQL, string-built shell commands and unescaped template rendering are the classic injection paths, and they are exactly the kind of thing a model reproduces because its training data is full of both the correct pattern and the broken one.
3. Check authentication and authorisation on every route, not just the ones you tested
It is common for a generated app to correctly gate the routes you explicitly asked for auth on, and quietly leave an admin or export endpoint open because it wasn't part of the original prompt. Walk the full route list, not the happy path.
Stability
4. Check that every external call has a timeout and an explicit failure path
A database query, a third-party API call or a webhook with no timeout will eventually hang, and when it does, it tends to take the whole request (or worker) down with it rather than failing on its own. Every external call needs an answer to "what happens if this never comes back".
5. Check for tests on the paths that touch money, auth or data deletion
You don't need full coverage to launch. You do need tests on the handful of operations where a silent bug costs a customer money, exposes another customer's data, or deletes something that can't be undone.
6. Check what happens when a dependency is slow or down, not just when it's absent
Most generated error handling assumes a dependency either works or throws immediately. Slow-but-technically-responding is the more common real-world failure, and it's the one that isn't tested by default.
CodeRabbit's December 2025 "State of AI vs Human Code Generation" report, which analysed 470 open-source pull requests, found that AI-co-authored PRs contained roughly 1.7 times more issues overall than human-only PRs, largely concentrated in exactly this kind of error handling and edge case logic. Separately, GitClear's 2025 AI Copilot Code Quality report, based on 211 million lines of changed code, found that the share of changed lines associated with refactoring fell from about 25% in 2021 to under 10% by 2024, while code churn (code rewritten or reverted within two weeks of being written) roughly doubled over the same period. Less refactoring and more churn both point the same way: fixes are being layered on rather than the underlying structure being corrected.
Performance
7. Check for a query-per-item loop on any endpoint that returns a list
Fetch a list of orders, then loop over each one to fetch its line items separately, and you have an N+1 query pattern that looks instant with ten test rows and falls over with ten thousand real ones. Search for database calls inside loops.
8. Check that anything returning "all rows" has pagination or a hard limit
An endpoint that returns every record with no limit is fine in a demo and a liability the day a table crosses a few hundred thousand rows, whether that shows up as a slow page or a server that falls over.
9. Check cold start time and bundle size if you're on serverless infrastructure
Generated code tends to import broadly rather than precisely, which is invisible in local development and shows up as slow cold starts or unnecessarily large deploy artefacts once you're running on a platform that spins functions up and down.
Deployment
10. Check that secrets and config are managed per environment, not hardcoded
Development, staging and production should never be reading the same API keys or pointing at the same database by accident. If your config file has one set of values with no environment branching, that's worth fixing before launch, not after.
11. Check that you can roll back a bad deploy in minutes, not hours
The question isn't whether a deploy will eventually go wrong. It's whether reverting it is a one-command operation or something you're improvising under pressure the first time it happens.
12. Check that errors are actually visible to you, not just printed to a terminal no one is watching
Console output on your laptop doesn't help you when the app is running on someone else's infrastructure. Errors, exceptions and failed background jobs need to land somewhere you or your team will actually see them, ideally with an alert attached.
How do I know if my vibe-coded app is ready for production?
Work through the twelve checks above category by category. If you can answer each one concretely (not "probably fine", but "yes, checked, here's how") across security, stability, performance and deployment, you're in reasonable shape. If several categories turn up open questions, that's a sign the app needs a proper pass before real users touch it.
What should I check before launching an AI-built app?
At minimum: secrets aren't committed to git history, user input is never concatenated directly into a query or command, every external call has a timeout, list endpoints are paginated, and you have a rollback path for a bad deploy. These five alone catch most of what turns into an incident in the first month.
Do I need a security audit before launching a vibe-coded MVP?
Not necessarily a formal audit, but you do need someone (ideally not the same AI assistant that wrote the code) to walk through the checklist above with real scrutiny. A formal audit becomes worth it once you're handling payment data, regulated information, or enough users that an outage or breach has real consequences.
If working through this list surfaces more than you want to fix yourself
Connect your GitHub repo, get a fixed-price quote based on its size and complexity, and a named engineer works through exactly these categories and hands the fixes back as a pull request.
See how the quote works →