How to Fix a Vibe-Coded App: Taking AI-Generated Code to Production

To fix a vibe-coded app for production, work in this order: close security gaps first (who can read and change which data, where your keys live, what input you trust), then make failures visible and recoverable (error handling, logging, backups), then make change safe (tests and a repeatable deploy). Most apps built with AI tools do not need a rewrite. They need a careful read of the code by someone who knows what production traffic does to a system, followed by targeted fixes in a deliberate order.

This guide is for founders who built a working product with tools such as Lovable, Bolt, Cursor or Replit, and are now asking how to get it in front of paying users without it falling over or leaking data. It is not a lecture about doing it the "proper" way. Building a working demo in days is a real achievement, and the code it produced is a reasonable starting point. The question is what changes between a demo you control and a product strangers use, and how to close that gap without losing the speed that got you here.

01Can AI-generated code contain security vulnerabilities?

Yes. AI-generated code can contain security vulnerabilities for the same reasons human-written code does, plus one more: the tool optimizes for what you asked for, which is usually "make this feature work", and a feature can work perfectly in a demo while being unsafe for real users. If you never asked who should be allowed to see a record, there is a good chance nothing checks. If the fastest way to call an API was to put the key in the browser, it may be there.

The useful framing is not "AI code is bad" but "unreviewed code is risky". The categories of problem are the well-known ones. The OWASP Top 10, the security community's standard list of the most critical web application risks, puts Broken Access Control first in its 2025 edition, followed by Security Misconfiguration and Software Supply Chain Failures, with Injection, Authentication Failures, Logging and Alerting Failures and Mishandling of Exceptional Conditions also on the list. Every one of those can show up in an AI-built app, and none of them shows up in a demo, because a demo has one friendly user and no attacker.

So when people ask about AI generated code security risks, the practical answer is: assume the common risks are present until someone has checked, and check them in order of how much damage they can do. You do not need statistics about AI code to justify that; you need the same review any codebase gets before it handles other people's data and money.

02What usually breaks between the demo and real users

These are the gaps we look for first in any app that has not yet had a production review. Not every app has all of them, and some apps built with AI tools are in better shape than hand-written ones. But this is the list that matters.

Authentication without authorization

Authentication answers "who are you?"; authorization answers "are you allowed to do this?". Prototypes usually get the first right, because sign-in is a visible feature, and miss the second, because nothing in a single-user demo exercises it. The classic symptom is an API route or database query that fetches a record by ID without checking that the record belongs to the signed-in user. Change the ID in the URL or the request, and you see someone else's invoice. The same applies to admin features hidden in the interface but reachable directly, and to actions such as "delete project" that check you are logged in but not that the project is yours. This is Broken Access Control, the first item on the OWASP list, and it is the first thing we test.

Secrets and API keys in the client

Anything shipped to the browser or a mobile app is public, including environment variables bundled at build time. Some keys are designed to be public: a database's publishable or anonymous key, or a payment provider's publishable key, which only work within the limits the server enforces. Others are not: a database service-role key, a payment provider's secret key, an AI provider's API key, an email service key. If a secret key is in the client, anyone can extract it and use it with your account's full permissions, and with AI provider keys that also means spending your money. The fix is to move those calls to a server function and rotate every key that was ever exposed, because removing it from the code does not remove it from old builds, browser caches or the repository's history.

Database rules and row-level security left open

Many AI-built apps talk to the database directly from the browser through a hosted backend, which is a legitimate design as long as the database itself enforces who can read and write each row. Row-level security (RLS) is a Postgres feature that does exactly that: policies attached to each table decide which rows a given user can see or change. Supabase's documentation, for example, warns that a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and that its service-role key bypasses RLS and must stay on the server (Supabase row-level security guide). Other hosted databases have equivalent rule systems. Tables created quickly during a build, with policies added later or never, are one of the most common serious findings in apps of this kind.

Input you trust without checking

Validation in the form is a convenience for honest users; validation on the server is the security control. Prototypes often do the first and skip the second, so a direct request can submit a negative quantity, a price of zero, a role of "admin", a 50 MB string or a script tag that is later rendered into another user's page. Every server endpoint should check types, ranges and ownership of anything it receives, and never accept fields such as price, role or account ID from the client when the server can work them out itself.

No error handling, no logging

In a demo, an error means refreshing the page. In production, an error is a customer who could not pay, or a background job that silently stopped three days ago. AI-generated code often handles the happy path well and treats failures as an afterthought: unhandled promise rejections, empty catch blocks, error messages that leak stack traces or SQL to the user. You need errors caught and turned into sensible responses, logged with enough context to debug, and routed to an alert someone will actually see. OWASP lists both Logging and Alerting Failures and Mishandling of Exceptional Conditions in its current Top 10 for this reason.

No backups, or backups nobody has restored

Find out what your database host backs up, how often, for how long, and how a restore works. Then do one. A backup you have never restored is a hope, not a plan. Also check what happens to files users upload, which often live in separate storage with separate (or no) retention.

No tests, so every change is a gamble

Prompting a tool to change one feature can quietly change another. Without tests, you find out from users. You do not need full coverage on day one; you need tests around the paths that cost money or trust when they break: sign-up and sign-in, permissions on the key records, checkout and payment webhooks, and anything that sends email or messages.

Cost blow-ups

Usage-priced services are wonderful in a prototype and dangerous with an exposed key or an unbounded loop. Common causes are AI API calls with no per-user limits, functions that re-run on every render, queries without pagination, and file storage with no size caps. Set spending limits and alerts on every provider that offers them, rate-limit expensive endpoints per user, and look at the bill weekly for the first months. Infrastructure choices matter as well: our team, including in its earlier work as GreenBorn Infotech, cut one client's monthly cloud bill from about $800 to about $150, mostly by matching the hosting to the actual load.

Production running on a prototype host

Preview environments are built for iterating, not necessarily for your customers' data. Before launch, decide where production lives, who controls the accounts, how a release happens, how you roll back, and whether development and production share a database (they should not). If the only way to deploy is "click publish in the tool", that is fine for now as long as you know what it does, but you want a path to releases you can repeat, review and undo.

03How to fix a vibe-coded app: triage security first

If you are thinking "fix my vibe coded app, but where do I start?", sort every finding on two axes: how bad is it if exploited or triggered, and how much effort is the fix. Then work the grid in a fixed order. High severity and low effort comes first, every time, because those are the fixes that remove the most risk per hour. High severity and high effort comes next, planned properly rather than rushed. Low-severity items get batched, and the rest goes to the backlog.

In practice, the first day of triage usually looks like this:

1. Inventory the secrets. List every key the app uses, where it is stored and whether it ever reached the client or the repository. Rotate anything that did, then move the calls server-side.
2. Check the data rules. For every table or collection, write down who should be able to read and write it, then compare with what the database actually enforces. Turn on row-level security or equivalent rules and test them as a second, unrelated user.
3. Probe access control. Sign in as one user and try to reach another user's records by changing IDs in URLs and requests. Try admin routes as a normal user. Try actions on resources you do not own.
4. Look at the bill and the limits. Set spending caps and alerts on every usage-priced provider, and rate-limit the endpoints that call them.
5. Confirm you can recover. Find the backups, check their schedule and retention, and restore one into a scratch environment.

Only after those five do you move on to robustness and maintainability work. It is tempting to start with the code that looks messiest, but messy code that is safe can wait; tidy code that leaks data cannot.

04A production-readiness checklist for AI-built apps

This is the checklist we work through with founders. It is deliberately short enough to finish. Each item is a yes or no question you can answer about your app today.

If your app takes payments, add one more area: webhook handling. Payment providers send events to your server, sometimes late, sometimes twice, and a handler that is not idempotent can grant access twice or miss a cancellation. Our guide to Stripe webhooks best practices covers the pattern in detail.

05Lovable production apps and other AI-built stacks: does the tool matter?

Founders often search for "lovable production apps" or similar phrases to find out whether an app built in a particular tool can go live at all. The answer is that the tool matters less than the code and configuration it left behind. Lovable, Bolt, Cursor and Replit produce ordinary application code in ordinary frameworks, typically connected to ordinary hosted databases and APIs. Once you export or check out that code, it can be reviewed, tested, hardened and deployed like any other codebase.

What differs between tools is mostly where things live: which database or backend the app talks to, how environment variables are handled, where it is hosted by default and how deploys happen. Those are exactly the questions the triage above answers. So rather than asking whether a tool is production-ready in general, ask whether your app is, by working through the checklist. Some apps pass most of it with a few days' work. Others need deeper changes, which is the subject of the next section.

06Rebuild or repair?

This is the decision founders worry about most, and the default answer is repair. Rewrites are slow, they reintroduce bugs the original had already fixed, and they stall the product while users wait. Most AI-built apps have a usable structure: reasonable pages, a sensible data model for the first version, working integrations. Fixing the gaps in place keeps all of that.

Rebuilding part or all of the app makes sense in a narrower set of cases:

• The data model is wrong for the business. If the core tables do not represent how your customers, accounts or orders actually relate, every feature built on them will fight you. Fixing the model usually means rebuilding the code that depends on it.
• Authorization cannot be added without touching everything. If data access is scattered through hundreds of client-side queries with no common layer, putting a proper permission model in place can be more work than rebuilding the data layer around one.
• The architecture cannot meet a hard requirement. Some compliance, multi-tenant or performance requirements need a different shape, such as server-side processing the current design cannot accommodate.
• Nobody can change it safely. If every edit breaks something unrelated and there is no way to add tests around the important paths, a structured rebuild of the worst parts can be cheaper than continuing.

Even then, a full rewrite is rarely the right move. A partial rebuild, replacing the data layer or the backend while keeping the interface, usually captures most of the benefit. The audit's job is to tell you which case you are in, with reasons, before you spend money either way.

07What a technical audit looks like

A technical audit is a fixed-scope review of your codebase and infrastructure by engineers who were not involved in building it, ending in a written list of problems ranked by risk and a plan to fix them. A good one is specific: not "improve security" but "the orders endpoint returns any order by ID without checking ownership; here is the file and the fix".

Our Technical Audit costs $1,500 and is delivered in five business days. It starts as soon as we have access to the repository and covers:

• Code and architecture review: how the app is structured, where data flows, what is fragile and what is sound.
• Security and data-handling issues, ranked by risk: access control, secrets, data rules, input validation and the other gaps described above.
• Deployment and hosting review: where production runs, how releases happen, backups, environments and cost exposure.
• A written plan with a fixed price for the fixes: what we would change, in what order, and what it costs.

The report is yours. You can hand it to your own developers, use it to brief another team or ask us to do the work. The point is to replace a vague sense that the app is "not ready" with a ranked, costed list.

08Audit, sprint, launch: a realistic path

If you want us to do the fixes, the next step is a Production Sprint: fixed-scope work, scoped from the audit findings and priced in writing before it starts, from $6,000. A sprint fixes, hardens and deploys. That typically means authentication and authorization, input validation, secrets, error handling, logging and backups, then deployment to infrastructure you own, such as Docker on AWS or servers you control, with a repeatable release process and handover notes. Changes to the scope are re-quoted, not absorbed silently.

The audit comes first for a practical reason: nobody, including us, can price the fixes honestly before reading the code. A fixed price after an audit protects both sides. You know what you are paying for, and we have seen enough of the codebase to stand behind the estimate.

09Keeping momentum while you harden

The biggest risk in hardening is not technical. It is that the product stops moving for a month while the founder waits, users drift and the original builder's knowledge goes stale. A few habits keep things moving:

• Freeze features briefly, not indefinitely. Pause new features while the high-severity fixes land, usually a short window, then resume. Running feature work and security fixes in parallel on a codebase without tests is how regressions happen.
• Keep building with your tools, on a branch. You can keep prototyping new features with AI tools while the hardening happens, as long as changes come back through review and the tests around critical paths. The tools are good at producing features; the review is what keeps them safe.
• Write the rules down. Once access rules, validation patterns and the release process exist, document them in the repository where both people and AI tools can read them. Prompts that reference those conventions produce code that follows them.
• Ship in small releases. Each fix goes out on its own where possible, with a way to roll back. Large batches of changes are harder to test and harder to undo.
• Decide who owns the code next. After launch, someone has to own it: you, a hire, a dedicated engineer or a team on retainer. Our comparison of dedicated developers, freelancers and agencies covers the trade-offs.

Hardening is also a chance to keep what is good. Apps built with AI tools often have strong interfaces and quick, sensible feature work. A careful repair keeps that, adds the guardrails, and leaves you with a codebase that both you and future engineers can change with confidence.

From here, this article is about Cevrynt

10How Cevrynt takes AI-built apps to production

Cevrynt, Inc. sells engineering services alongside its underwriting software. Our team is led by Arindam Pradhan, who has built production software since 2018, with four senior engineers who each have six or more years of experience. As a team, including our earlier work as GreenBorn Infotech, we have delivered more than 300 projects. We read the code, fix what is broken and keep what works, whether the app started in Lovable, Bolt, Cursor or Replit or was left half-built by a previous team.

Start with a $1,500 Technical Audit, delivered in five business days, then decide whether you want a Production Sprint, from $6,000, scoped from the findings and priced in writing before work starts. See Production Sprint for details, or send us your repository and goals and we will reply with next steps.