Going from vibe code to production means adding everything the demo skipped: real auth, locked-down database rules, secrets off the client, tests, CI, monitoring, and rate limiting. The UI is usually fine. The backend, data security, and operational layer are the work. Plan one to three weeks of hardening, not a weekend.
Your Lovable or Bolt build works. You click through it, the flows run, the AI did its job. So why isn't it a product yet?
Because a demo proves the happy path. Production survives everyone else: the user who pokes at your API, the bot hammering your signup, the attacker reading your client bundle for keys. The gap between those two states is real engineering work, and the AI tool didn't do it because you didn't ask and it doesn't volunteer. Here's what's actually in that gap.
The frontend is usually the part that's done. The UI renders, the buttons work, the copy reads fine. The work lives underneath, in seven layers the model treats as optional.
Vibe-coded auth is often a login form with no enforcement behind it. The page checks if you're logged in; the API doesn't. That means anyone who reads your network tab can call your endpoints directly, logged in or not. Real auth means sessions, token validation on every protected request, password reset that works, and roles that actually gate access on the server.
This is the most common and most dangerous hole. On Supabase, Row-Level Security is the thing that stops user A from reading user B's rows. AI builders frequently leave it off, so every record in your database is one crafted request away from any visitor. We see it on nearly every rescue. If your app stores anything private, RLS is not optional. See our guide on hardening Supabase RLS in Lovable and Bolt apps.
AI tools love to drop API keys straight into the frontend so the call "just works." That key now ships in your JavaScript bundle, visible to anyone who opens dev tools. Stripe keys, OpenAI keys, database URLs: we've found all of them exposed. Production means secrets live on the server, scoped, rotated, and never in the client. More in exposed API keys in AI-built apps.
Vibe-coded apps ship with zero tests. That's fine until you change one thing and silently break three others, with no signal until a user finds it. You don't need 100% coverage. You need tests on the flows that lose money or leak data if they break: auth, payments, anything that writes to the database.
A demo runs on the AI tool's preview. A product needs a real deploy: a build pipeline, environment variables managed properly, a staging environment, and a way to roll back when a deploy goes wrong. Continuous integration means a push runs your tests before it ever reaches users, instead of you finding out live.
If your app throws an error in front of a user right now, would you know? Most vibe-coded apps have no error tracking and no logs you can search. Production means you see failures before your users email you about them, and you have enough context to fix them fast.
With no rate limiting, one script can hammer your signup, your login, or any expensive endpoint until your bill spikes or your database falls over. It's a few lines of work that prevents a very bad day. Almost no AI build includes it.
It depends on the app, but the shape is consistent. Use this as a rough map.
| Layer | What the demo has | What production needs |
|---|---|---|
| Auth | A login screen | Server-side enforcement on every protected route |
| Data | Open tables | RLS or equivalent, tested per role |
| Secrets | Keys in the client | Server-side, scoped, rotated |
| Tests | None | Coverage on money and data paths |
| Infra | Preview URL | Real deploy, CI, staging, rollback |
| Monitoring | Nothing | Error tracking and searchable logs |
| Rate limiting | None | Limits on auth and expensive endpoints |
For a self-serve read on where you stand, run the free production readiness check. If you'd rather have a senior engineer find every blocker, that's what the prototype-to-production work does.
The good news: the AI-built code is usually a fine starting point. The structure works, the UI is real, and rebuilding from zero would be slower and dumber. The job is hardening, not rewriting. You keep what works and close the holes the model left open. The decision tree for when a rebuild actually makes sense is in fix or rebuild your vibe-coded app.
You don't have to stay dark for three weeks waiting for "production-ready." The smart move is to sequence it. Close the critical security holes first, the ones that leak data or expose keys, then go live while the rest gets layered in behind real users. Auth and RLS get locked, secrets move server-side, rate limiting goes up. Then tests, CI, and monitoring fill in while the app is earning its keep.
That's how we run it. A fixed-price Week-1 build audit at $4,000 finds every blocker and prices the fix up front. Senior engineers only, a working demo every week before each payment, full code and IP yours from day one, and a 30-day warranty. The guarantee is simple: we find every blocker or the audit is free.
If you want a second set of eyes before you commit, the is my AI app production ready guide and the free 15-minute security audit are good places to start.
For most apps, one to three weeks. The frontend is usually done, so the work is the backend, data security, and operational layer: auth, RLS, secrets, tests, CI, monitoring, and rate limiting. It's real engineering, not more prompting, so a weekend isn't realistic for anything that handles real user data.
Almost never. The AI-built code is usually a solid starting point with a real UI and working structure. The job is hardening what's there, closing the security holes and adding the missing operational layers, not rewriting. A full rebuild is slower and only makes sense in specific cases.
The repeat offenders: Supabase row-level security left off, API keys exposed in the client bundle, no real server-side auth, no rate limiting, secrets committed to the repo, no tests, and no monitoring. We find some mix of these on nearly every rescue.
Yes, if you sequence it. Close the critical holes first, the ones that leak data or expose keys, then go live and layer in tests, CI, and monitoring behind real users. Ship and harden run in parallel once the security floor is in place.
It starts with a fixed-price Week-1 build audit at $4,000 that finds every blocker and prices the fix up front. Full hardening starts from $14,000, fixed price, versus $60k-plus and an open hourly meter at a typical US or UK agency. We find every blocker or the audit is free.
Free 15-min build audit