Your vibe coded app has real users. Here is how to make it production ready

You built an app with an AI tool such as Lovable, Bolt, Replit or Cursor. It works, and people use it. Now you want to know if it is safe to grow.

I will show you what usually breaks in a vibe coded app, how to check your own app, and what to fix first. I will also explain when a fix is enough and when a rebuild makes more sense.

What is a vibe coded app?

A vibe coded app is an app that someone built mostly by asking an AI tool for features in plain words. The person often does not read the code the AI writes. Collins Dictionary named "vibe coding" its word of the year for 2025. Andrej Karpathy, a founding member of OpenAI, coined the term in February 2025.

This way of building is fast, and you can test an idea in days. The trouble starts when the app holds real customer data or takes real money. At that point, the parts you cannot see matter most.

Is a vibe coded app safe to put in front of real users?

It can be, but check it first. The research shows real gaps.

• Veracode, July 2026: In its 2026 GenAI Code Security Report, about 44% of AI code tasks produced code with a known security flaw. The average pass rate for security was 56%, almost the same as in its first report. The report also found that AI tools now write code that runs almost every time. So the app works, even when it is unsafe.
• Escape, October 2025: Its team scanned more than 5,600 public vibe coded apps. It found more than 2,000 security flaws and more than 400 exposed secrets. It also found 175 cases of exposed personal data, including medical records and bank account numbers.
• Wiz Research, September 2025: Wiz found that 1 in 5 companies building on vibe coding platforms faced risks that affected the whole system. The main problems were login checks in the browser, keys in the code, open database tables and internal apps with no login at all.

There is also a public security record, CVE-2025-48757. It says weak database rules in Lovable apps, up to April 15, 2025, let strangers read or write data. Lovable disputes this record. It says each customer must protect their own app's data. Either way, the risk lands on you as the owner.

Lovable's own docs say this too. Its built-in scans run when you publish. The docs also say the tools "do not replace a thorough security review" of your app.

What usually breaks in a vibe coded app?

The same problems show up again and again.

Exposed keys and secrets

A key is a password that lets your app use another service, such as OpenAI, Stripe or an email tool. AI tools sometimes put these keys in the code that runs in the user's browser. Anyone can open that code and copy the key. Then they can run up your bill or read your data.

Open database rules

Many AI app builders use Supabase as the database. Supabase protects data with rules called Row Level Security, or RLS. RLS decides which user can see which rows. The Supabase docs say a table without RLS "is readable and writable by any role with a grant on it". In plain words, a stranger could read or change your customers' records.

Login checks that run in the browser

Some apps check who you are inside the browser. A user can change what the browser says about them. So a normal user might reach an admin screen. Wiz found this pattern in its research. The fix is to check every request on the server.

Payments

Stripe tells your app about a payment by sending a message called a webhook. Your app must check that each message really came from Stripe. Stripe's docs warn that, without this check, an attacker could send fake messages to get orders filled or accounts opened. AI tools often skip this step. They also skip refunds, failed card retries and cancelled plans.

Speed when real users arrive

An app that feels fast with 10 users can slow down with 1,000. Common causes are pages that load every record at once, and database searches with no index. An index is like the index in a book. It lets the database find a row without reading every page.

Backups and the live database

In July 2025, an AI agent on Replit deleted a company's live database during a code freeze. Jason Lemkin of SaaStr shared what happened. Replit's chief executive then promised to keep test and live databases apart. Replit's docs now say the agent cannot change the live database.

Check your own backups as well. Supabase lists daily backups for its Pro, Team and Enterprise plans. For free projects, its docs tell you to export your data yourself on a regular basis. If you never set this up, you may have no backup at all.

How do you check your own vibe coded app?

You can do a first check without writing code. Work through this list with your app open.

• Run the built-in scan: Lovable and Bolt both have security checks. Run them and read every warning.
• Look for keys: Ask your AI tool, "List every API key in this project and tell me where each one runs." Any key that runs in the browser needs to move to the server.
• Test the data rules: Make two test accounts. Log in as one and try to open the other's records by changing the web address. If you can see them, your rules are open.
• Try the admin pages: Log in as a normal user and type the address of an admin page. You should get blocked.
• Test a payment: Use Stripe's test mode. Pay, then cancel, then refund. Check that your app updates each time.
• Find your backup: Find out where your last backup is and when it ran. Then try to restore it into a test copy.
• Check who owns what: Make sure the code, the database, the domain and the payment account sit in your company's name.

If any step fails, stop adding features. Fix that first.

What should you fix first in a vibe coded app?

Fix the problems that can hurt customers today. Then fix the ones that will hurt you as you grow.

Order	Problem	What can happen	Typical fix
1	Keys in the browser	Someone runs up your bill or reads your data	Move keys to the server and replace the old keys
2	Open database rules	Strangers read or change customer records	Turn on RLS for every table and write clear rules
3	Login checks in the browser	Normal users reach admin tools	Check every request on the server
4	Payment messages not checked	Fake orders or free access	Verify Stripe webhooks and handle refunds
5	No tested backup	You lose all your data in one bad change	Set up daily backups and test a restore
6	Slow pages	Users leave and costs rise	Add indexes and load data in pages

After these, add error alerts and simple tests for the parts that make money.

When should you rebuild a vibe coded app?

Most apps do not need a rebuild. A good developer can fix the list above in your current code. A rebuild makes sense in a few cases.

• The same bugs keep coming back: Each fix breaks something else, and nobody can explain why.
• Nobody can read the code: The code has many copies of the same logic, and files that run to thousands of lines.
• The data model is wrong: For example, the app stores each customer's data in a way that makes sharing or reporting very hard.
• The tool limits you: You need something the platform cannot do, such as a feature the hosting does not allow.

If you do rebuild, keep the vibe coded version as your working spec. It shows exactly how the app should behave, which saves time on the new build.

When should you leave a vibe coded app as it is?

Some apps are fine as they are. An internal tool for three staff, with no customer data and no payments, may need only a quick check. A test app that you plan to throw away after a month does not need a full review either.

The line moves when you store personal data, take payments or sign a contract with a customer. At that point, a review costs far less than a data leak.

How does Blur Studio make a vibe coded app ready for real users?

Finishing half-built and AI-built apps is a big part of what I do. I work with apps from Lovable, Bolt, Replit, Cursor and Bubble. Here is how I approach one.

• I read the code first: I spend the first days reading and testing. I do not add features until I know what is there.
• I fix the risks in order: Keys, data rules and logins come first. Payments and backups come next. Speed comes after that.
• I explain each fix in plain words: You will know what was wrong and what changed.
• You own everything: The code and every account stay in your name. That includes GitHub, the database, hosting and Stripe.
• I stay after launch if you want: I also take care of software after launch, so someone keeps watching it.

Once I've made the core solid, I also set up a safe environment where you can keep using Lovable, Bolt, Replit, Base44 or whichever tool you like to make small changes yourself, a new page, a copy change, a tweak to a screen. I separate the parts that are safe to touch from the parts that control security, payments and data, so an AI-assisted change you make on a Tuesday afternoon cannot quietly break your database or expose a customer's data. You stay in control without needing to learn to code, and you come to me for anything bigger or anything that touches that protected core.

If you want to hire someone for this work, my guide on hiring a Lovable, Bolt, Replit or Cursor developer covers what to look for. If you are still deciding how to build, read AI app builder vs hiring a developer. If your app runs on Bubble, see Bubble agency vs custom code.