Is vibe coding bad? Our verdict, and how to check your app before launch.

Vibe coding is good for speed and bad for unreviewed launches. That is our view.

Use it freely for a prototype, a sales demo, an internal tool or a landing page that tests demand, where a bug costs you an afternoon. That changes the day a stranger types a password into your app, a card gets charged, or you store someone's address, health details or payment history. From then on, a mistake leaks data, loses money or loses customers, and the demo code was never tested for any of that.

So the useful question is whether anyone has checked the app since it started holding real data. If nobody has, treat it as a prototype, however finished it looks.

Vibe coding is building software by describing what you want to an AI tool in plain language and accepting the code it writes, often without reading it.

Andrej Karpathy, an OpenAI co-founder, named it in a post on X on February 2, 2025, describing a way of coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." Merriam-Webster lists the term and defines it as "writing computer code in a somewhat careless fashion, with AI assistance."

Tools such as Lovable, Bolt and Replit turn this into a product: you type a prompt, and you get a working web app with screens, a database and a login.

Vibe coding is good at getting from idea to something clickable in days, for very little money. Here is what it does well.

• Testing demand. You can show a working app to ten possible customers before you hire anyone.
• Internal tools. A booking tracker or quote calculator used by five staff members rarely needs more.
• Clear specs. A working prototype explains what you want to a developer far better than a written brief.
• Readable starting code. Lovable, for example, produces standard React code you can sync to GitHub, so the work is not thrown away later.

Keeping a vibe-coded app as it is can be the right call. If it serves a small team, holds no sensitive data and takes no payments, the cost of hardening it may outweigh the risk.

The weak spot is security. Veracode's 2025 GenAI Code Security Report, published July 30, 2025, tested more than 100 AI models on 80 coding tasks and found the models chose an insecure way to write the code in 45% of cases.

They break where a demo never goes: strangers, money, failures and time. We look at eight areas first, and the table in the next section covers all of them. Four have the clearest public record.

Database access rules

Supabase is the database behind Lovable apps, either inside Lovable Cloud or in your own Supabase project. Its documentation says to switch on row-level security (rules on which user may read or change which rows) for every table in an exposed schema; with it off, anyone holding the public key in your app can read the table. On May 29, 2025, the US National Vulnerability Database published CVE-2025-48757 for insufficient row-level security in Lovable-generated sites, a record Lovable disputes, saying customers are responsible for their app data. Semafor reported the same day that researchers, one of them a Replit employee, found the flaw in 170 of 1,645 Lovable-built apps.

Payment webhooks

A webhook is the message your payment provider sends your app when a payment succeeds, fails or is disputed. Stripe's documentation says live events are retried for up to three days, can arrive more than once and should have their signature verified. We look for orders marked paid from the browser, skipped signature checks and repeat events processed twice.

Backups

Supabase's documentation says Pro, Team and Enterprise projects get daily backups, and tells Free plan projects to export their own data. In July 2025, Fortune reported that a Replit AI agent deleted the production database of an app built by SaaStr founder Jason Lemkin during a code freeze; Replit's CEO called it unacceptable and announced automatic separation of development and production databases.

Search visibility

Most vibe-coded apps are single-page applications: the browser builds each page with JavaScript, so a crawler reading raw HTML sees an empty shell. Google's JavaScript SEO guide says "server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript." That rarely matters behind a login, but public pages need it; our guide to how AI assistants find pages explains why.

You can find the worst gaps in about an hour without reading code. The table sums up each risk; the full eight-step founder self-check is on our vibe-coded app to production page.

Fix effort varies by app. The audit sets it for yours.

Lovable as a platform includes real safeguards, and your app is only as secure as its own settings.

Lovable's documentation describes a quick scan that runs before publishing and a deeper scan of access rules, secrets, payments and login. It also says these tools "cannot guarantee complete security" and that you are responsible for your app's security, especially with sensitive data.

Two 2026 reports show both sides. In February 2026, The Register reported a researcher's claim that one Lovable-hosted app exposed 18,697 user records, partly through missing row-level security; Lovable's security chief said every project gets a free scan before publishing and acting on it is up to the user. In April 2026, The Register reported a claim that free accounts could read other users' project data; Lovable said its explanation of public projects had been unclear and patched its API.

What a Lovable app needs before launch is on our Lovable production page. Built with something else? See our guides to taking a Bolt app to production and moving a Replit app to production hosting, or the Lovable vs Bolt vs Replit production comparison.

Usually you fix most of it and rebuild a few weak parts, and we decide which per app in the audit.

Vibe coding cleanup means taking an AI-built app and closing the gaps between the demo and real customers: database rules, login, keys, payments, backups, monitoring, tests and search visibility. The working screens and logic stay wherever they hold up.

A full rebuild makes sense when the data model is wrong for the business, when fixes would touch nearly every file, or when the app has grown into something the builder handles poorly. If you need software designed from scratch, our custom development service covers that path.

It scores your app on seven areas and tells you, in plain language, what must be fixed before launch.

The seven areas are security, authentication, database, hosting, performance, error handling and SEO, and the eight places above map onto them. You order through our app audit form, and within one business day (Monday to Friday) we confirm the scope by email with a payment link.

The terms are fixed. The audit costs $299, and the report arrives within five business days of access to your project, or you get your money back. We need collaborator access to your builder project and read access to GitHub and Supabase, and we sign your NDA first on request. Order the build within 60 days of the report and the fee is credited toward the build.

Production builds start from $4,000, and most small apps cost $4,000 to $15,000. Most are production ready within two to four weeks of starting the build. Apps with payments or sensitive data take longer: we fix the issues the audit finds and tell you what still needs a specialist. All prices are in US dollars; see our app audit and build prices.