
A founder builds an app with an AI app builder over a weekend and shares the link on Monday. By Friday, the app has paying users, and someone asks a simple question: what happens if the database breaks? That question marks the line between a working app and a production app.
AI app builders such as Lovable, Bolt, Replit, and v0 now handle hosting, a database, and sign-in for a single app. What they typically do not give you is the infrastructure a growing product depends on:
Moving to production usually means exporting the code to Git and deploying it to a platform that provides these pieces. The rest of this guide explains what builders cover today, where apps tend to break, and how to close each gap.
AI app builders give you far more than a prototype. Most now include hosting, a managed database, sign-in, and some form of Git export. The table below summarizes what the four most popular builders provide natively.
Builder | Hosting | Database and auth | Git | Environments and recovery |
| Lovable | Built in | Lovable Cloud, built on Supabase, with auth, storage, and edge functions | Two-way GitHub sync | Backups can be restored; no separate staging environment documented |
| Bolt | Built in | Bolt Cloud database with auth and file storage | Export and version control | Version history does not restore the database |
| Replit | Built in | Separate development and production PostgreSQL databases | GitHub, GitLab and Bitbucket | Point-in-time restore for production; deployment previews |
| v0 | Through Vercel | Not built in | Branches and pull requests on GitHub | A Vercel preview deployment for each branch |
That is real progress, and for many apps it is enough. The gaps appear when an app gains paying users, a team, or data obligations. Those gaps are where most production problems start.
Vibe-coded apps usually break for operational reasons, not because the idea or the interface is wrong. Two public incidents show the pattern.
In July 2025, an AI agent on Replit deleted a live production database during a code freeze. The database held records for more than 1,200 executives and about 1,190 companies. The data was recovered through a rollback, and Replit then separated development and production databases by default.
In May 2025, researcher Matt Palmer disclosed CVE-2025-48757. More than 170 Lovable-built apps had missing or weak row-level security rules. Anyone with the public API key could read data such as emails, phone numbers and payment status. Lovable has since added quick and deep security scans.
Wider studies point the same way. A June 2026 scan of 1,072 vibe-coded apps by Symbiotic Security found at least one security flaw in 98% of them, and a critical flaw in 16%. A CodeRabbit analysis of 470 open-source pull requests found that AI-written code had about 1.7 times more issues than human-written code. Both studies come from companies that sell code security or review tools, so treat the exact figures with some care. The direction is still consistent: AI-generated apps need the checks that production software has always needed.
A production app needs a set of capabilities around the code. Builders cover some of them for a single app. The table shows where the gaps usually sit.
Need | What builders usually provide | What production requires |
| Testing changes | A preview, or nothing | An environment for each change, with production services and data |
| Data | A managed database with some restore options | Scheduled backups, tested restores, reviewed migrations and access rules |
| Background work | Short edge or serverless functions | Long-running workers, scheduled jobs and queues |
| Visibility | Basic logs | Logs, metrics and alerts in one place |
| Security | Scanners for common issues | Secrets and environment configuration kept out of the code, plus human review |
| Team workflow | Git export or sync | Code review, automated tests and a deploy history |
| Compliance and portability | Platform-level certifications | Region choice, audit evidence, and code and data you can move |
Most builders let you preview a change, but the preview rarely runs against production-like services and data. That hides the bugs that matter most, such as a migration that fails on real records. On Upsun Cloud, every Git branch can get a preview environment that clones production apps, services, and data in seconds.
Builder-managed databases are convenient, but they can be hard to move. Lovable's documentation states that there is no one-click migration from Lovable Cloud to your own Supabase project, and the region cannot change after setup. A production database needs scheduled backups, a restore you have tested and migrations that someone reviews.
Real products send emails, process payments and sync data on a schedule. Edge functions handle short tasks well, but long-running workers and scheduled jobs need their own runtime. Upsun Cloud defines workers and cron jobs in the same configuration file as the app.
Without logs, metrics, and alerts, your users become your monitoring system. A production setup shows errors, slow requests, and resource use in one place, and alerts someone before customers notice.
One vibe-coded app is easy to track. Five apps across Lovable, Replit and Vercel mean five deploy processes, five database consoles, and five sets of access rules. This sprawl slows down security reviews and audits, because the evidence lives in separate places.
An app is ready for production when it passes each of these checks. Each item stands on its own, so you can work through them in any order.
Moving a vibe-coded app to production takes nine steps. Most apps do not need a rewrite.
On Upsun Cloud, this is a single .upsun/config.yaml file that defines the app, its database, and its scheduled jobs
The right home depends on how much the app has grown. Staying on the builder is a sound choice for some apps.
Option | Right call when |
| The builder's own hosting | The app is an internal tool or an early experiment with few users |
| Vercel or Netlify with a hosted backend | The app is mostly front-end, and the team is comfortable running the backend separately |
| An application platform such as Upsun Cloud, Render, or Railway | The app has several services, real user data, or a team shipping changes |
| A hyperscaler such as AWS, Azure or Google Cloud | The company already has platform engineers and wants full control |
Upsun Cloud fits teams that want every app, database, and environment in one place, across the cloud regions they choose. The platform holds ISO 27001, SOC 2 Type 2, PCI DSS Level 1, and HIPAA certifications.
Yes. Moving to production changes where the app runs, not how fast you can build. Coding agents such as Claude Code can deploy and inspect Upsun projects through the Upsun skill and the Upsun MCP server.
For teams, Upsun Dispatch adds structure to that work. It turns an issue into a pull request when someone comments @upsun-dispatch implement, pauses at human gates for decisions, and logs every run, including its plan, approver, and cost.
Do I need to rewrite a vibe-coded app to put it in production?
Most vibe-coded apps do not need a rewrite. They need an audit, a Git repository, secrets and environment configuration moved out of the code, and a hosting setup with backups, monitoring, and test environments.
Is code from AI app builders secure?
Code from AI app builders is not secure by default. The most common problems are missing database access rules and API keys exposed in the browser. Builder security scans help, but a human review is still needed for apps that handle personal or payment data.
Can I keep using my AI builder after moving?
Yes, if the builder syncs with Git. You can keep editing in the builder, push changes to your repository and deploy from there.
Can a vibe-coded app handle real traffic?
Many vibe-coded apps handle real traffic without trouble. Hosting capacity is rarely the first limit. The usual limits are testing changes safely, recovering data and working as a team.