Vibe coding to production: what to fix before your AI-built app meets real users
AI app builders can get you a working prototype in a weekend. Getting it safely in front of paying users is a different job. Here is what usually breaks between vibe coding and production, and how to fix it without starting over.
Going from vibe coding to production is the step most AI-built apps never plan for. Tools like Lovable, Bolt, v0, Replit and Cursor can turn a description into a working product in days. Founders validate ideas, operations teams build internal tools, and agencies ship demos that used to take a month. That part is real, and it is a good thing.
The problem starts when the prototype quietly becomes the product: real customers sign up, real payments go through, real personal data lands in the database. Code that looks finished is not the same as code that is safe to run. This guide covers what usually breaks, a checklist to close the gaps, and how to decide between hardening what you have and rebuilding parts of it.
Why vibe-coded apps break in production
AI coding tools are optimised to make the thing you asked for work. Security, permissions, failure handling and cost control are rarely in the prompt, so they are rarely in the code.
The data backs this up. Veracode’s 2026 GenAI Code Security Report found that modern models write syntactically correct code nearly every time, yet roughly 44% of the AI code generation tasks it tested introduced a known security vulnerability. The average security pass rate was 56%, barely changed from 55% in its first report. In plain terms: the code compiles, the demo works, and almost half the time something exploitable is hiding inside.
The best-known example is CVE-2025-48757. A security researcher found that many apps generated with Lovable on top of Supabase had missing or ineffective row-level security. According to Superblocks’ write-up of the incident, a follow-up scan found 303 vulnerable endpoints across 170 projects, exposing emails, phone numbers, payment status and API keys to anyone who knew how to change a query. Nobody “hacked” those apps in the movie sense. The database was simply open.
The seven gaps we see most often
1. Authorization that only lives in the UI
The button is hidden for non-admins, but the API behind it accepts anyone. In Supabase and Firebase apps, this usually means row-level security is missing, too broad, or “enabled” with a policy that allows everything. The test is simple: log in as user A and try to read or change user B’s records directly through the API.
2. Secrets in the browser
Payment keys, AI provider keys and service-role database keys end up in front-end code, where anyone can open developer tools and copy them. A leaked AI key can turn into a large bill overnight.
3. No server-side validation
Prices, quantities, discounts and user roles are trusted because the form “only allows” correct values. Attackers do not use your form.
4. Payments without webhooks
The app marks an order as paid when the user lands on the success page, instead of when the payment provider confirms it. Closed tabs, retries and refunds then leave your data out of sync with your money.
5. No environments, migrations or backups
Changes are made directly on the live database through a chat prompt. There is no staging copy, no migration history and no tested restore. One bad prompt can drop a column with a year of customer data in it.
6. Nothing is watching
No error tracking, no logs you can search, no uptime alert. You learn about failures from customers, if they bother to tell you.
7. Code nobody can maintain
Each prompt solved the next problem on top of the last one. The result is duplicated logic, dead files and components nobody fully understands — including the AI that wrote them. Every new feature gets slower and riskier.
A vibe coding to production checklist
Before you invite paying users or store anything sensitive, work through this list. It is roughly in order of risk.
- Inventory the data. List every table, what it stores, and who should be able to read and write each row. This becomes your permission model.
- Enforce access on the server. Write and test row-level security or API middleware for every table and endpoint. Test it with at least three roles: anonymous visitor, normal user, admin.
- Move secrets server-side. Rotate any key that has ever been in the front end or in a public repository. Call third-party APIs from server functions only.
- Validate everything on the server. Prices, totals, roles, file types and sizes. Never trust what the browser sends.
- Make payments webhook-driven. Your database changes when the payment provider says so, not when a page loads.
- Add staging, migrations and backups. Separate test and live environments, versioned schema changes, and a backup you have actually restored once.
- Add observability. Error tracking, structured logs, uptime monitoring and spending alerts on every API with usage-based pricing.
- Rate-limit and protect forms. Login, sign-up, password reset and any AI endpoint need limits, or they become an attack surface and a cost risk.
- Check the legal basics. Privacy policy, cookie consent, data processing agreements with your providers, and — if you serve EU users with AI features — the transparency duties in the EU AI Act.
- Get an independent review. Someone who did not write the prompts should read the code and try to break it.
Harden, refactor or rebuild?
Most vibe-coded apps do not need to be thrown away. The front end, the screens and the product thinking are often the most valuable part, and they are usually fine. What needs attention is what sits underneath.
| Situation | Usual decision |
|---|---|
| Clean structure, few users, problems mainly in permissions and secrets | Harden: fix security, add monitoring and backups, keep building |
| Working product, but every change breaks something else | Refactor: keep the UI, restructure the data layer and business logic |
| Core logic lives in the browser, data model does not fit the business | Rebuild the backend: keep screens and flows as the specification, replace the engine |
| Prototype was only for validation and you now have funding or customers | Planned rebuild: use the prototype as a living spec for a proper MVP |
A good rule: if fixing the permission model means touching most of the code, it is usually faster to rebuild the backend than to patch it table by table.
A realistic example
Imagine a small clinic network that built a booking portal with an AI app builder. Patients can register, choose a doctor and pay a deposit. It works. A review finds three things: any logged-in patient can read other patients’ bookings through the API, the payment key sits in the front-end bundle, and deposits are confirmed on page load. None of these show up in a demo. All three would show up in an incident report.
The fix here is not a rewrite. It is a focused hardening sprint: row-level policies per patient and per clinic, a server function for payments with webhook confirmation, rotated keys, staging, backups and error tracking. The patients never notice anything except that the portal keeps working.
How AI coding fits a professional workflow
None of this is an argument against AI coding. We use AI coding tools every day. The difference is that in a production workflow the AI writes code inside guardrails a person designed: a clear data model, tested permissions, code review, automated tests and a deployment pipeline. Speed comes from the AI; safety comes from the system around it.
If you are planning a product rather than rescuing one, our SaaS product build service starts with exactly that foundation — authentication, billing, tenancy and permissions — so you can keep moving fast after launch.
Frequently asked questions
Is a vibe-coded app safe to launch?
It can be, but not by default. Treat it as an unreviewed first draft: check authorization, secrets, validation and payments before any real user data goes in.
Can I keep using Lovable, Bolt or Cursor after hardening?
Yes. Many teams keep prototyping new screens with AI tools. The key is that changes go through version control, review and staging instead of straight to the live database.
How long does it take to make a prototype production-ready?
For a small app with a sound structure, a focused hardening pass often takes one to three weeks. If the backend has to be rebuilt, plan for longer. A short code review first will tell you which case you are in.
What is the single most important fix?
Server-side authorization. If users can read or change data that is not theirs, nothing else matters yet.
Get your AI-built app production-ready
If you have a prototype built with an AI tool and real users are about to arrive, send us a short description and access to the repository. We will review the security, data model and infrastructure, tell you plainly whether to harden, refactor or rebuild, and — if you want — take it to production and look after it afterwards.
I take on a small number of projects at a time. Tell me what you are building and I will tell you honestly whether I am the right person for it.
Get in touch →Keep reading
Si ta testosh një agjent AI para publikimit: udhëzues praktik për biznese
Një agjent AI që duket i shkëlqyer në demo mund të dështojë me klientët realë. Ja si ta testosh dhe vlerësosh para se ta lësh të prekë procese reale.
How to Test an AI Agent Before Launch: A Practical Evaluation Guide for Businesses
An AI agent that looks great in a demo can still fail on real customers. Here is a practical, business-friendly way to evaluate and test an AI agent before you let it touch real workflows.
AI Policy for Employees: How to Handle Shadow AI at Work Without Banning It
Most of your team is probably already using AI tools you never approved. Here is how to write a practical AI policy for employees, reduce shadow AI risk and replace risky habits with tools that work.
4 comments