How to Take a Vibe-Coded App to Production: A Hardening Checklist

To take a vibe-coded app to production: get the code into version control you own, audit it, then fix things in order of risk. First make sure every user can only access their own data (server-side authorization and database row-level security), move all secrets out of the front end and rotate them, and review the data model and migrations. Then check dependencies, add automated tests for critical journeys, set up separate environments, error monitoring, logging and backups, and deploy through a pipeline with rollback. If the audit shows a flawed data model or tangled code, rebuild using the prototype as the specification instead.

Production software needs a home you control. Export or sync the project to a Git repository owned by your company account, not a personal one, and make sure you can build and run it outside the builder. Record which services it depends on (database, authentication, storage, email, payments, AI APIs) and who holds the accounts. Many teams discover at this point that the app's database and keys sit in a founder's personal account.

Spend a few days understanding what you have. A good audit reads the code paths that matter, maps the data model, lists every place data is read and written, tests access controls directly against the API or database, and scans for secrets and vulnerable dependencies. The output is a prioritized list of issues and a recommendation: harden or rebuild.

This is where most AI-built apps fail, and the consequences are the most serious. Generated code often checks permissions in the user interface (hiding a button) but not on the server or database, so anyone who calls the API directly can read or change other people's data.

If the app uses a hosted database accessed from the browser, such as Supabase or Firebase, enable row-level security or security rules on every table and write policies that restrict each row to its owner or organization. Supabase's documentation is explicit that tables exposed through its API need row-level security. CVE-2025-48757 records apps built with one AI builder whose tables were readable or writable without authentication because of missing row-level security (the vendor disputes the record, saying each customer is responsible for their app's data). Whatever the platform, that responsibility is yours.

AI tools often place API keys where they make the demo work: in front-end code, in committed environment files, or in prompts pasted into chat. Anything shipped to the browser is public. Move secret keys (database service keys, payment secret keys, AI provider keys, email and SMS keys) to server-side functions, store them in your host's secret manager, and rotate every key that was ever exposed in code, a repository or an AI tool. Use separate keys for development, staging and production.

Calls to paid AI APIs deserve special care: an exposed key or an unauthenticated endpoint that proxies to a model can run up large bills quickly. Put rate limits and per-user quotas on them.

Prototypes tend to grow their database one prompt at a time. Look for missing foreign keys and constraints, duplicated fields that drift apart, text fields used for numbers or dates, and no record of how the schema was created. Introduce migrations so every schema change is versioned and repeatable, add constraints that protect data integrity, and set up automated backups. Then restore a backup to a test environment to prove it works.

If the data model is fundamentally wrong for the business (for example, single-user tables in what must be a multi-tenant product), that is the strongest signal to rebuild rather than patch.

Review every package the app installs. Remove what is unused, replace abandoned packages, and confirm each one is the real, widely used package rather than a lookalike. Research presented at USENIX Security 2025 found code models hallucinated package names in 19.7 percent of suggestions, and attackers register those names. Turn on automated dependency and vulnerability scanning in your repository and lock versions.

You do not need complete coverage before launch. You need automated tests for the journeys that would cost you most if they broke, running on every change.

Production needs to be separate from where you experiment. Set up at least a staging and a production environment with separate databases and keys. Deploy through a pipeline that runs tests and checks on every change, and make rollback a one-step action. Add error monitoring for front end and back end, structured logs, uptime checks and alerts that reach a person. Decide who responds when something breaks.

Real users bring legal obligations. Publish a privacy policy that matches what the app actually collects, add consent where required, decide data retention, and check where each service stores data. If you are in a regulated sector (health, finance, children's data), get specific advice before launch. Check that AI features do not send personal data to providers in ways your policy does not allow; see AI data privacy.

Going to production does not mean giving up AI tools. It means using them inside a process: changes on branches, reviewed diffs, tests that must pass, and no AI tool with direct access to production data or credentials. Our guides to AI-generated code security and securing AI coding agents cover the guardrails.

A vibe-coded app is a strong starting point and a weak finishing point. Own the code, audit it, fix data access and secrets first, put the data model under migrations, check dependencies, test the journeys that matter, and deploy with monitoring and rollback. When the audit says the foundations are wrong, rebuild from the prototype rather than patching around it. For the strategic view, read vibe coding vs production software.