Vibe Coded App to Production: Getting Your Lovable, Bolt or Cursor App Ready

Taking a vibe coded app to production means turning a Lovable, Bolt or Cursor prototype into something strangers can sign up for, store data in and pay through without that data leaking or disappearing. It comes down to five steps: an audit, security, data and GDPR, testing, and hosting with monitoring. Most prototypes are worth saving, but almost none are ready as they are.

Full disclosure: this is a service I sell, so weigh my advice accordingly. It's also why there's a section below on when you don't need a developer at all.

The short answer

How much work your app needs depends on two things: who uses it and what data it touches. Here's the rule of thumb I use:

The line isn't a number of users. It's the moment a stranger can create an account, or the app starts storing data you'd hate to see leaked. From then on it's a product, and it needs to be treated like one.

New to the term? Start with what vibe coding is and where it stops working.

Why vibe coded apps break in production

AI app builders are tuned to produce something that works when you click through it. They aren't tuned to resist someone who is actively trying to break it. That gap is the whole difference between a prototype and a product.

Access control is the big one: who can read and change which data. Lovable and Bolt give you a built-in backend or connect your app to a Supabase project, and the frontend talks to the database directly using a public key that sits in the browser. That's by design, and it's fine, as long as every table has rules about who can read and write it. Supabase's Row Level Security docs state that a table in an exposed schema without RLS is readable and writable by any role with a grant on it. In a typical Supabase project, that includes anyone holding the public key.

This has already happened at scale. In 2025, security researcher Matt Palmer analyzed 1,645 apps built with Lovable and found 170 projects where data could be pulled without permission. His write-up of CVE-2025-48757 lists emails, phone numbers, API keys and payment records among the exposed data.

It isn't a single-tool problem either. When Veracode tested code from more than 100 language models, 45% of the samples introduced OWASP Top 10 vulnerabilities, and security didn't improve with newer or larger models (Veracode 2025 GenAI Code Security Report). Broken access control sits at number one on the OWASP Top 10:2025, the industry's standard list of web app security risks.

What I check first

When I audit an AI-built app, I start with the same short list, because that's where most of the risk sits:

• Tables with no access rules, or rules that let everyone in.
• Secret keys for Stripe, OpenAI or your email provider sitting in frontend code where anyone can read them.
• Permission checks that only exist in the interface ("only admins can see this page") with nothing enforcing them on the server or in the database.
• No automated tests, so every new prompt can quietly break something that worked yesterday.
• Database changes made by hand in a dashboard, with no history and no way to rebuild the schema.
• No backups, or backups nobody has ever restored.
• Errors that vanish silently because nobody gets alerted.

I go through each of these with examples in my post on the most common vibe coding security issues.

The five-step path to production

Order matters. There's no point writing tests for code you're about to throw away, or picking a host before you know whether the backend is staying put.

Step 1: Audit what you actually have

Get the code out of the tool and into a Git repository you own. Most of these tools can sync or export to GitHub, and with Cursor the code is already on your machine. Without version control you can't see what changed, and you can't roll anything back.

Then map the app:

1. Data model: which tables exist, how they relate, and where personal data lives.
2. Roles: who can do what, for example regular user, admin and organization owner.
3. Integrations: payments, email, LLM APIs and anything else the app calls.
4. Secrets: where keys and passwords are stored, and who can see them.
5. Where code runs: in the browser, in edge functions (small serverless functions, for example on Supabase) or on a proper server.

The output should be a prioritized list in three buckets: fix before launch, fix in the first month, and can wait.

The audit also answers the big question: rescue or rewrite? My default is rescue. The interface an AI tool generates is usually fine to build on. It's the data model and the access logic that decide it. If those are a mess, everything on top gets expensive to fix. I've written a full guide on whether to rewrite or refactor a vibe coded app.

Step 2: Lock down security

This is where the real risk is, so it's where I spend the most time.

1. Turn on Row Level Security for every table and write rules that match your business: users see only their own rows, admins see only their own organization, and so on.
2. Test those rules by trying to fetch another user's data, both logged in as a regular user and logged out. That's exactly what an attacker will try.
3. Move secret keys to the server. Only the public key belongs in the frontend. Supabase's service_role key bypasses every rule and must never reach the browser.
4. Enforce anything involving permissions, prices or payments on the server or in the database, not only in the interface.
5. Finish authentication: email verification, password reset, sessions that expire, and two-factor login for admins.
6. Rate-limit logins and forms so nobody can brute-force passwords or flood your database with junk.
7. Check that file storage buckets aren't public unless they need to be.

Running Lovable on Supabase? Work through my Lovable and Supabase security checklist line by line.

Step 3: Get your data and GDPR in order

Once access is locked down, the goal is simple: never lose data, and be able to change the database without holding your breath.

Store database changes as migrations: small files in your repository that describe each change. That lets you rebuild the database from scratch, try changes on staging first and see who changed what. While you're at it, add the constraints AI tools tend to skip, like unique email addresses or orders that can't exist without a customer.

Find out exactly what backups your plan includes, how often they run and how long they're kept. Then restore one to a test environment, so you know it works before you need it.

If your company is in the EU, or you offer your app to people in the EU, GDPR applies the moment you store personal data. I'm based in Denmark, so it's the default for everything I build. In practice:

• You'll usually need a data processing agreement (DPA) with every vendor that handles personal data for you: database, hosting, email and LLM providers.
• Pick an EU region for your database, backups and hosting where the platform allows it.
• Collect only what you actually use, and delete what you no longer need.
• If there's a breach, Article 33 requires you to notify your supervisory authority without undue delay and, where feasible, within 72 hours, unless the breach is unlikely to put people at risk (GDPR full text on EUR-Lex). Good logging is how you find out what was actually exposed.

If your app sends user data to an LLM, read my guide to GDPR and LLM APIs too. I'm a developer, not a lawyer, so get proper advice if you handle sensitive data.

Step 4: Test the flows that can't break

You don't need to test everything. Pick the three to five flows where a bug costs money or trust: sign-up, login, the core job of the app, checkout and account deletion.

1. Write end-to-end tests (a script that clicks through the app like a user, for example with Playwright) for exactly those flows.
2. Test your access rules: can user A read or edit user B's data? The answer has to be no, and a test should prove it.
3. Set up a staging environment with its own database, so you never experiment on real users' data.
4. Run the tests automatically on every change (continuous integration), so bugs surface before users find them.
5. Check by hand on mobile and in a couple of browsers, especially error messages and empty screens.

Tests matter twice as much if you plan to keep prompting. An AI change in one corner of the app can easily break another, and without tests you'll hear about it from a customer.

Step 5: Set up hosting, operations and monitoring

Lovable and Bolt can host your app, and for plenty of projects that's fine. Consider moving if you need control over the server region, background jobs, heavier business logic or integrations with systems like accounting software. What I usually recommend is keeping the frontend and moving the heavy logic to a proper backend, often Laravel. That isn't always necessary, though. A Supabase backend with well-tested rules can run in production just fine.

Wherever it runs, you need:

• Your own domain with SSL, and email sending set up properly (SPF and DKIM) so your emails don't land in spam.
• Error tracking (Sentry, for example) that alerts an actual person.
• Uptime monitoring and logs you can search.
• A way to roll back a release that breaks things.
• A clear view of running costs: database, hosting, email and any AI calls.

If the app calls an LLM, cost per user can climb fast. Run the numbers before launch with my guide to estimating LLM API costs.

What it costs and how long it takes

It depends on the size and state of the app, and nobody can give you a reliable price without looking at the code. That's why I start larger jobs with a paid, fixed-price discovery project: you get the prioritized list and an estimate, and you know the price of the rest before you commit.

What moves the price up or down:

• The number of tables, user roles and screens.
• How tangled the data model and access logic are.
• Whether the app handles personal data, payments or other sensitive information.
• How many integrations there are, such as payments, accounting and LLM APIs.
• Whether the backend stays on Supabase or moves somewhere else.

As a rough guide, auditing a small app takes a few days. Cleanup and production setup usually take a couple of weeks or more, and longer with payments, many roles or several integrations. That can feel like a lot for something that already works. The alternative is finding the holes after launch, when they cost you the trust of users you've only just won.

When you don't need a developer (yet)

It would be convenient for me to say every AI-built app needs an audit. It doesn't. You can safely wait if:

• The app is a prototype for testing an idea with users or pitching investors, and it runs on test data.
• You don't know yet whether anyone wants it. Spend the money finding out first.
• It's an internal tool for a few colleagues, with no personal data and no access to critical systems. Still switch on access rules, but skip the rest for now.
• What you actually need is a marketing website. A website builder will be cheaper and simpler.

On the flip side, a freelancer isn't the answer if you need a full-time team from day one. I'm one person. If the product needs several developers working on it full-time, hire in-house or bring in an agency.

Not sure which side you're on? Here are the signs it's time to hire a developer for your AI-built app.

After launch: keep shipping without breaking things

The work doesn't stop at launch. Dependencies need updating, platforms change under you, and users find bugs you'd never have found yourself.

You can keep using AI tools after launch. Just stick to a few ground rules:

• Make changes on a separate Git branch, never directly on the code that's live.
• Run the tests before anything ships, and review changes to access rules by hand.
• Try changes on staging before they reach production.
• Ask the AI for small, scoped changes rather than sweeping rewrites.

I cover this in more depth in maintaining AI-generated code. If you're choosing a tool for your next project, see how Lovable, Bolt and v0 compare. And if the app is meant to become a subscription business, read how to build a SaaS with AI without painting yourself into a corner.

Next steps

Use this checklist to see how close you are. If you can tick every box, you're further along than most.

Missing a few boxes, or just want someone else to check? My AI app to production service covers the audit, the fixes and the production setup, and you own the code throughout.

Frequently asked questions

Do I need to move off Supabase to go to production?+

No. Supabase can run in production just fine if access rules, backups and monitoring are set up properly. I only recommend moving logic elsewhere when the app needs something Supabase isn't a great fit for, such as heavy background jobs, complex integrations or business rules that are awkward to express in the database. Often you move part of the logic and keep the rest where it is.

Can't the AI tool fix the security issues itself?+

Partly. Once you know exactly what's wrong, the tool can often fix it, and built-in security scanners are a useful first pass. But a scanner can't know who should see what in your particular business. It can confirm that a rule exists, not that the rule is right. That's why access rules need testing by someone who understands both the code and how the business works.

Can I keep building in Lovable or Bolt after a developer has cleaned it up?+

Yes, as long as you agree on how changes get into the code. The safest setup is that every change, including those from the AI tool, goes through Git and gets tested before it ships. Changes to access rules and payments should always be reviewed by a developer. That way you keep your speed without undoing the work that made the app secure.

Does it matter where my developer is based?+

For GDPR, where your data is stored and which vendors process it matter more than where your developer sits. But if a developer can access production data containing personal information, they're effectively a processor, so you'll want a DPA with them too, and access from outside the EU raises transfer questions. An EU-based developer removes the transfer issue, though the DPA still applies. This isn't legal advice, so check your setup with a privacy lawyer.