Is your vibe-coded app production-ready?

Apps built with Lovable, Bolt, Cursor, Replit or v0 get further in a weekend than a team used to get in a quarter. What the tools skip is everything a demo never shows, because a demo has one user, no attacker, no bad input and no second deploy. This is the list we work through when we audit one. You do not need to read code to use most of it; where you do, ask whoever can.

Authentication and authorisation

• Every route that returns private data checks who is signed in on the server. A check in the browser is a suggestion; anyone can call the API directly.
• Changing an ID in the URL or the request does not show another user’s records. This is the commonest way users end up seeing each other’s data.
• If you use Supabase or Firebase, row-level security or security rules are on for every table, and tested with a second account. With them off, the public key in your browser bundle can read everything.
• Admin actions check an admin role on the server. A hidden button is not a permission.
• Password reset, email change and invitation links expire and work once. These flows are where accounts get taken over.

Secrets and keys

• No secret key is in the browser bundle. Anything shipped to the browser is public, and payment or database keys there can be used by anyone.
• Keys live in environment variables, not in the repository, and the git history has been checked for old ones. Deleting a key from the code does not delete it from history.
• Every key that was ever exposed has been rotated. A leaked key stays valid until someone revokes it.

Data model and migrations

• You can say in one sentence what each table holds. Tables generated prompt by prompt drift into duplicates that disagree with each other.
• The database enforces relationships and required fields, not only the app. When the app has a bug, the database is the last thing standing between you and bad data.
• Schema changes are migration files in the repository, applied the same way everywhere. A change clicked into a production dashboard cannot be reviewed, repeated or undone.
• Backups run, and someone has restored one. A backup nobody has restored is a hope.

Input validation and the API surface

• Every input is validated on the server for type, length and allowed values. The form’s checks do not apply to someone calling the API directly.
• There is a list of every endpoint and who may call it. Generated apps grow endpoints nobody remembers adding, and the forgotten ones are the open ones.
• Endpoints that cost money or send messages are rate-limited. An AI call, an email or a text message in a loop is a bill.
• Errors shown to users carry no stack traces, queries or internal IDs. Those details are a map for whoever is looking for a way in.

Tests

• Sign-up, payment and the core action each have an automated test. Without them, the next change can quietly undo what works.
• Tests run automatically on every change, before it merges. A test nobody runs protects nothing.
• A test proves one user cannot reach another user’s data. It is the bug that costs the most and shows up the least in a demo.

Deployment, rollback, logging and monitoring

• There is a staging environment that is not production. Otherwise every change is tested on your users.
• A deploy is one repeatable step from the repository. Manual uploads and hand-promoted previews make every release a slightly different one.
• You can roll back to the previous version in minutes, and have done it once. The night you need it is not the night to learn how.
• Production errors are logged somewhere you will see them, with enough context to reproduce. “It broke for a customer” is not a bug report.
• Someone is alerted when the app is down or errors jump. Without that, your users are your monitoring.

Dependencies

• A lockfile is committed. Without one, two installs of the same code can run different libraries.
• A dependency audit shows no known critical vulnerabilities. Most of the code you ship is code you did not write.
• Every package is one you use, and none does a job another already does. Generated code adds packages per prompt, and each is something to update and trust.

Documentation and who can read the code

• The code is in a repository you own, not only in the tool’s workspace. If the account or the tool goes, the product should not go with it.
• A README says how to run it locally, which environment variables it needs and how to deploy. The next developer, or you in six months, starts there.
• Someone other than the person who wrote the prompts can explain how a request moves through the app. If nobody can explain it, nobody can safely change it.

How the audit ranks what it finds

Thirty points do not all matter equally, and fixing them in the order of this list would be the wrong order. The audit ranks findings by what breaks first. At the top is anything that can leak data or money today: exposed keys, open endpoints, missing validation, broken auth and permissions, and the bugs your users already hit. Next is what breaks under the next change or the next hundred users: no tests, no staging, no rollback, a data model that will not carry the next feature. Last is what slows the team down without hurting anyone yet: dependencies, documentation, code nobody can read.

What the written report contains

The audit is free, written and back within 24 hours. It covers the architecture, the data model, auth and permissions, secrets, dependencies, test coverage and deployment. Every finding is ranked by what breaks first. It ends with a straight answer on refactor or rebuild, and what each one costs: stabilisation from $10k, a full rescue $20k to $50k, priced from what the audit found rather than from a guess. The report is yours whether or not you hire us.

If you ticked most of the thirty yourself, you may not need us. If you could not answer half of them, that is the finding.