Vibe coding to production: what has to change before real customers use the app

Vibe coding is building software by telling an AI tool what you want (Cursor, Lovable, Bolt, Claude Code and similar) and accepting what it produces, judging the result by running it rather than reading the code. The term is also used loosely for any AI-assisted coding. Here it means the narrower sense: the code is accepted without being understood.

It is not the problem. It is a fast, cheap way to learn whether people want the thing, and a working prototype is a better specification than any document. The problem is the gap it leaves: unread code, rules nobody decided, and no record of why anything is the way it is. Even the vendor-side guidance says the user carries that responsibility. Claude Code's own security page states that you are responsible for reviewing proposed code and commands for safety before approval. The tools help you write the code; they do not take over the reading.

Nothing below depends on which tool wrote the app. It depends on what the app now has to do.

A prototype is judged by whether it works for its author on a good day. A production app is judged by what happens on a bad day, to someone who is not the author. Almost every item on the checklist further down is one row of this table turned into a task.

Ten areas, ordered roughly by how expensive the failure is. Each row names the question to answer and the evidence that it is answered. 'It seems to work' is not evidence.

Authentication and authorisation

Use a managed sign-in provider rather than hand-built login code, and check the dull parts: password reset, session expiry, email verification, what an administrator is and how someone becomes one. An admin flag that the browser sends and the server trusts is not a role.

Authorisation is where AI-built apps most often fail, because the screen looks right. A button that is hidden for ordinary users protects nothing if the endpoint behind it answers anyone who asks. The test is quick: sign in as two different users, copy a request for one user's record from the browser's network panel, and replay it as the other. If it succeeds, you have found the first thing to fix.

Secrets and environment variables

In most front-end frameworks, variables with a public prefix are compiled into the code sent to every visitor, so check the name of each one before you decide it is safe. Anything that can spend money or read all the data belongs on the server only. Treat a key as burned if it has ever been pasted into a chat with an AI tool, shown in a screenshot or committed to version control, because deleting the commit does not delete it from history. Rotate it, use separate keys for test and live, and turn on secret scanning in your code host if it offers it.

Database access rules

Many AI-built apps use a hosted Postgres such as Supabase, where the browser talks to the database through an automatically generated interface using a public key. In that design the access policies are the only barrier between a visitor and every row, so a table without row-level security, or with a policy that allows everything, is open. The privileged service key bypasses those policies and must never reach the browser. Supabase's own documentation is the authority on the details and it changes, so confirm them for your own project rather than relying on this paragraph.

Read every policy. The quickest fix for a permission error is to loosen the rule, and a tool aiming at 'it works now' can do exactly that, so search for policies that are simply true. Write select, insert, update and delete separately, and test them as an anonymous visitor, as an ordinary user, and as an administrator. On the school ERP we built, row-level security policies carry both role and branch, so a branch administrator's queries return their branch's rows regardless of which screen asked. On the consent-scoped health app, per-category sharing is enforced in the database, not the interface. The principle is the same in both: the interface reflects the rules, and the database enforces them.

Input validation

Validate on the server, against a schema, whatever the form already checks in the browser. Never assemble database queries by joining strings. Decide where uploaded files go, who can open them, and whether the storage bucket is public. Verify the signature on any incoming webhook, or anyone can post fake payment confirmations to you. Rate-limit sign-up, login and every endpoint that sends email or calls a model.

Error handling and logging

Search the code for empty catch blocks and for errors that are logged and then ignored. A failure that is swallowed is worse than a crash, because nothing tells you. Users should see a plain message and never a stack trace, and a person should be told about the real error. For anything sensitive, such as changing a role, issuing a refund or exporting data, keep a record of who did it and when. On the trading ERP we built, every write appends a field-level entry to an audit table that staff can add to but never edit, so the trail cannot be rewritten through the API. Keep secrets and personal data out of the logs themselves.

Backups

A backup you have never restored is a hope. Find out what your database plan includes, how far back it goes and how to restore, then do a restore into a scratch copy and check the result. Keep the code in version control in an account you own, not only inside the AI tool's workspace, and keep a separate export of anything customers upload.

Dependencies and licences

AI tools add packages freely. List what the app depends on, remove what it does not use, commit the lockfile and run your package manager's vulnerability audit. Check that each package is the one you think it is: a name the tool mistyped or invented can be registered by someone else. Record the licences of the direct dependencies, because some constrain how you may distribute a commercial product, and read the AI tool's own terms on who owns what it generates. If either matters to your business, ask a lawyer; this article is not legal advice.

Tests for the money and permission paths

Do not chase a coverage figure. Pick the handful of failures that would hurt most: charging the wrong amount, a refund that does not reverse, a user promoted without approval, one customer reading another's records, data deleted that should not be. Write those tests first, and run them against a real database where you can. State the expected outcome in plain English before any code, because tests the tool writes to match its own code will pass whether or not the code is right.

Deployment and rollback

Give staging and live their own database and their own keys, and deploy from version control through a repeatable step instead of editing the only copy. Know how to go back to the last good version, and rehearse it once when nothing is on fire. Database changes are the hard part of rolling back, so apply them to a copy first and keep them small. For anything that acts on its own, such as sending messages or moving orders, run it in a mode that records what it would have done before you let it do it. We used that shadow-mode approach on the fleet order automation before go-live.

Cost limits on AI and API calls

An unauthenticated endpoint that calls a model is a public line of credit. Keep the key on the server, require sign-in, set a per-user limit, cap the length and number of calls per request, and set a spend cap and an alert at the provider if one is offered. If the app runs an agent in a loop, cap the steps. Our article on AI agents for operations covers cost control in more depth. We do not quote prices here, because they change; use the provider's current published rates for your own estimate.

Ask one question: can someone other than the AI tool explain where each permission is enforced? If yes, harden. If the honest answer is 'somewhere in the screens, probably', the data and permission layer needs rewriting, and that usually costs less than finding every gap in code nobody understands.

The middle route is often the right one. Keep the prototype as the specification, because its screens and flows are what users reacted to, and rebuild the layer beneath them. That is the reverse of a classic rewrite, which throws away what was learned.

For a small internal tool, the minimum is still real: sign-in in front of it, secrets off the client, a backup you have restored, and the code in an account you own. The rest of the checklist scales with how bad a leak or a wrong number would be.

1. 01Read-only access first: the repository, the database schema and policies, the deployment settings and a list of third-party accounts. No access to live customer data and no ability to change anything.
2. 02A map of what the app does, who uses it, what data it holds and what a failure would cost. The consequences set the priorities.
3. 03Findings ranked by consequence, each pointing to a file or a policy and showing how to reproduce it. A finding nobody can reproduce is an opinion.
4. 04A decision on harden, rewrite part, or rewrite, with the reasons written down.
5. 05The fixes that block launch, tests on the money and permission paths, a staging environment, deployment from version control, restored backups and spend caps.
6. 06A handover: the repository, hosting and database accounts in your name, and a short runbook covering how to deploy, roll back, rotate a key and restore a backup, plus a list of known gaps.

A review is not a penetration test, a certification or legal advice, and it cannot make an app compliant with data-protection or financial rules on its own. Apps that handle health or payment data need specialist assessment on top. The same applies to anything the review did not look at, which the handover should list.

Our own track record: the closest published example is the materials marketplace, an app first generated on an AI app builder that we audited and moved onto its own database. It was a migration, not a measured before-and-after, so treat this checklist as a method. It rests on the controls in systems we wrote and reviewed by hand, such as the school ERP, the trading ERP and the fleet order automation, and on the reading of vendor documentation we cite below. Our vibe-coding-to-production page describes the review we offer; our custom development page covers a full rebuild.