How to Take a Vibe-Coded App to Production

What Does Taking a Vibe-Coded App to Production Actually Involve?

It means accepting four responsibilities a prototype never had: other people's data, other people's money, uptime someone relies on, and a way back when a release goes wrong. The features may not change at all; what changes is that every screen must hold up against a stranger trying to misuse it.

This guide assumes the app is worth keeping. If you are unsure, read where the line between prototype and production sits first, and whether AI-written code is safe to ship has its own article. Here the question is practical: what to check, in what order, at what cost.

The failure mode is not hypothetical. Moltbook, a social network for AI agents that Infosecurity Magazine describes as vibe-coded, shipped a Supabase API key in its client-side JavaScript with no row-level security policies behind it. Wiz researchers found it with a non-intrusive review; roughly 1.5 million API tokens, about 30,000 email addresses and a few thousand private messages were exposed, the magazine reported on 3 February 2026, and the issue has since been fixed. None of it showed in the interface.

Which Problems Show Up First in Lovable, Bolt and Replit Apps?

The same handful, because the tools optimise for a working screen and these problems never appear on one. Supabase's row-level security guide is direct about the first: any table the public API can reach is open to every role that has been granted access to it until RLS is switched on, so turn it on for all of them. With RLS on and no policies, the publishable key reads nothing, which is the safe default.

The trap comes next. Policies do not withdraw broad grants a table already carries, so a policy-only table can still let anonymous visitors insert rows until those grants are revoked. Supabase's master checklist for vibe-coded apps, published in August 2025, covers the same ground, from logged-out tests to backups and monitoring. Use the table as a self-audit before you pay anyone.

What Changes in Supabase Before the End of 2026?

Supabase's migration guide says the legacy anon and service_role keys are deprecated by the end of 2026, with no exact day given. The anon key becomes a publishable key (sb_publishable_) for browsers, mobile apps and anything the public can inspect. The service_role key becomes a secret key (sb_secret_) for servers, edge functions and workers only. Secret keys bypass row-level security, so Supabase rejects them with an HTTP 401 when sent from a browser, and because you can create several, giving each service its own key means a leak costs you one rotation instead of all of them.

It is not the only year-end date. Zeabur, a hosting platform that deploys straight from GitHub, suffered a second breach on 14–15 October 2026 that exposed about 3.2 million environment-variable records and information on 321,810 accounts, BleepingComputer reported on 20 October. It stops renewals on 1 December, shuts down by 31 December and told users to rotate secrets. The lesson for any host: keep secrets rotatable and a deployment you can move, and data migration and cleanup covers moving the data.

The key migration doubles as an audit, because it makes you find every place a key lives. If you are not technical, hand this list to whoever built or set up the app. The guide's steps, in our own words:

• Create the new publishable and secret keys; the legacy keys keep working while you migrate.
• Put the publishable key in all client code: web, mobile and desktop builds, and scripts you ship.
• Put the secret key in server code only, never in a browser bundle or the repository.
• Update database webhooks and pg_net calls to send the secret key on the apikey header, read from Vault.
• Update edge functions to read the new key variables and authorise each request in your own code.
• Check easy-to-miss callers: app versions already on users' phones, CI/CD, cron jobs, workers and integrations.
• Deactivate the legacy keys; the guide says this is reversible if a forgotten client breaks.

What Is the 10-Step Checklist to Take a Vibe-Coded App to Production?

Work through it in this order. The early steps stop the bleeding; the later ones make sure a machine, not a customer, catches the next problem. Each step produces something you can prove, which is what separates a production app from a hopeful one.

Steps 6 and 9 cover the paths that lose money; how to test software before launch covers what to test beyond them.

1. Get the code into GitHub. At the time of writing, Lovable's GitHub sync runs both ways and lets you deploy outside Lovable.
2. Inventory and rotate every secret. Assume anything pasted into a prompt or committed to the repository is exposed.
3. Turn on row-level security for every exposed table, then test logged out and as a second ordinary user.
4. Move privileged operations — admin actions, refunds, anything needing a secret key — into server code that checks the caller.
5. Separate staging from production, each with its own database and keys.
6. Run CI with tests on every pull request, starting with sign-up, login, checkout and anything that changes a balance.
7. Turn on scheduled backups and time one restore. At the time of writing, Supabase backs up Pro plans and above daily and advises free-tier projects to export their own data.
8. Add error and uptime alerts that reach a named person; monitoring and alerting is a 3–7 day build.
9. Verify payment webhook signatures and make handlers idempotent: Stripe warns an endpoint can receive the same event more than once and retries live deliveries for up to three days. See payment gateway integration.
10. Hold the domain, cloud, database and payment accounts in the company's name, with two admins.

Should You Harden the Code You Have or Rebuild It?

Harden it in most cases. If the data model matches how the business works, the faults sit at the edges — access rules, keys, server checks, tests — and can be fixed without discarding screens users know. Rebuild when the core is wrong: tables that do not reflect real entities, rules copied across dozens of components, or no way to enforce permissions on the server. Then every fix touches everything.

A rebuild still starts from the prototype, which is the best specification you will have. A SaaS MVP with auth and billing is quoted at $1,800–$2,500 over 18–28 days, and the MVP-in-14-days sprint at $2,000–$2,500 for 14 days. Keep the new repository and accounts in your name; who owns your code lists what to check.

Ask three questions in order. The tree carries no price on purpose, because the answer depends on the code in front of you.

Does it hold other people's data or take payments?
  NO  -> keep building in the platform; run its scans
  YES -> Does the data model match the business?
           NO  -> rebuild the core as a SaaS MVP
           YES -> Are access rules enforced server-side?
                    NO  -> harden: RLS, keys, server checks
                    YES -> ship: staging, CI, backups, alerts

How Long Does It Take, and What Does Each Step Cost?

Each step maps to a build in PINCLER's published catalogue, with its advertised band and quoted window. Most apps need some of these rather than all six, run as separate fixed-price phases.

The security review itself is not a separate line item. Reviewing access policies, key placement and interface-only checks is scoped into the fixed quote after the free 30-minute call, inside the same $500–$2,500 band, because AI drafts the fixes and senior engineers review, test and harden each one. There is no typical hardening price to publish; it depends on the app's tables, roles and integrations.

For context, the three Cloud & DevOps builds in the catalogue have a median advertised price of $850 and a median quoted window of 5 days; with so few records, the fixed-price report treats that median as indicative only, so budget from the per-step table below.

Who Should Pay for Hardening, and When Is the Platform Enough?

Pay for it when failure would hurt someone other than you: paying customers, personal data, payments, or staff who stop working when the app is down. Then one leak or a week of lost orders costs more than a fixed-price phase, and the work is easier while the data is still small.

Do not pay for it while you are still testing demand. Keep building in the platform, run its scans before every publish, and spend the money learning whether anyone wants the product: how to validate an MVP covers that, and building an MVP with AI covers timelines. The platform is enough when losing the data would be an inconvenience, not an incident.

• Good fit: paying users, or paid plans with a launch date.
• Good fit: personal data such as phone numbers, health details or documents.
• Good fit: payments, refunds or balances moving through the app.
• Good fit: staff or partners whose daily work depends on it.
• Poor fit: a demand test with no users yet.
• Poor fit: a personal or internal tool holding nothing you would have to report if leaked.

What Are the Most Common Mistakes When Hardening an AI-Built App?

Each of these leaves an app looking fixed when it is not, which is worse than the original gap because nobody keeps looking.

The pattern is the same: a control was switched on but never exercised. Prove each one works, ideally with an automated test that fails if someone switches it off.

1. Rotating keys without checking old mobile builds: deactivate the legacy key too early and users on old versions are locked out.
2. Enabling RLS but never testing as a second user. Sign in as user B and try to read user A's rows.
3. Adding policies while broad grants still stand. Policies pick rows; grants pick operations. Revoke what the public role does not need.
4. Testing only as the admin, whose account often bypasses the very rules being tested.
5. Never doing a restore test, so nobody knows how long recovery takes or whether it works.

PINCLER's Perspective on Hardening AI-Built Apps

PINCLER is an AI-first custom software development studio, so we have no quarrel with AI-written code; our own builds start that way. AI drafts, and senior engineers review every change, design the access model, run the security pass and own the release. Hardening someone else's generated app is the same discipline in a different order: review, fix, then add the tests and alerts that keep it fixed.

The stack is familiar. Across the 79 builds in PINCLER's published fixed-price catalogue, Next.js is listed on 61, PostgreSQL on 57, Vercel on 34 and Supabase on 22; the median advertised price is $1,450 and the median quoted delivery 13 days. That is a published price list rather than a delivery record, set out in what you can build.

Every phase uses the same fixed pricing bands and process: a free call, a one-page fixed-price scope within a working day, an early working preview, senior review and hardening, and handover with code, cloud accounts and data in your name. If an app needs compliance certification or a rewrite far beyond one phase, we split it into phases or decline it.

The Bottom Line

A vibe-coded app is ready for production when you can prove who can read what, where every key lives, and how a bad release is rolled back and last night's data restored. Most get there by hardening, not rebuilding, in fixed phases of $500–$2,500, because AI drafts the fixes and senior engineers review, test and harden every change. On Supabase, do the key migration first.

If your app has paying users, personal data or payments, run the self-audit table above, then fix what it finds or bring it to us: a free 30-minute call returns a written fixed quote within a working day, and the cloud deployment and CI/CD setup page shows what a deployment and rollback phase contains.