What is a vibe-coded app, and what it takes to put one into production

A vibe-coded app is an app built mostly by describing what you want to an AI tool, such as Lovable, Bolt, Replit or v0, and letting it write the code. It's the fastest way there has ever been to get a working product in front of people. Getting that product ready for paying customers is a different job, and this guide explains what it involves.

Taking AI-built and no-code products into production is the main work we do at Exline Labs, so this guide is written from what we see when founders bring them to us.

What is a vibe-coded app?

The term comes from Andrej Karpathy, a co-founder of OpenAI. In February 2025 he described a new way of building software: you tell an AI model what you want in plain English, accept what it writes, and keep going without reading the code closely. He called it vibe coding. By the end of the year Collins had named it its word of the year.

A vibe-coded app is anything built that way. In practice, founders usually make them with one of two kinds of tool:

• App builders such as Lovable, Bolt, Replit, Base44 and v0. You describe the app in a chat, and the builder writes the code, sets up a database and puts a preview online.
• AI coding tools such as Cursor and Claude Code. These work inside a real codebase, and you need some technical knowledge to use them well.

With most of these tools, the result is real code, usually React and TypeScript with a hosted database behind it. That makes it different from no-code platforms such as Bubble, where your app lives inside the platform and you can't take the code with you.

Why a vibe-coded app works so well in a demo

AI tools are very good at the parts of an app you can see. In an afternoon, they can produce screens, forms, sign-up, a dashboard and a database that saves what you type. For a founder testing an idea, that's a huge change. You can put a minimum viable product in front of customers before you spend money on a development team, and many good products now start this way.

The demo works because everyone using it is friendly. The founder clicks the buttons in the right order, uses one account and never tries to break anything.

What changes when real customers arrive

Real customers do things a demo never sees. They sign up with odd email addresses, open the app on old phones, share links, and some of them go looking for gaps. Vibe-coded apps tend to struggle at the same points, because the AI was asked to make the app work, and nobody asked it to plan for what real users do.

These are the problems we find most often:

• Exposed keys. API keys and secrets sitting in the front end, where anyone who opens the browser's developer tools can read them.
• Open data. Database access rules switched off or set too loosely, so one user can see or change another user's records.
• Weak sign-in. Login, password reset and user roles that are easy to get around.
• No limits. Forms and APIs with no rate limiting, open to spam and to running up your bills.
• No safety net. No backups, no monitoring and no separate test copy, so one bad change can take the product down.
• Store rejection. Mobile apps that fail App Store or Google Play review on privacy, payments or stability.

It has already happened at scale. In 2025, a check of 1,645 apps built with Lovable found that 170 of them let anyone read personal data, because of how their database rules were set up. The flaw was recorded as CVE-2025-48757. Lovable disputed it, saying each customer is responsible for securing their own app's data. For a founder, that's exactly the point: whatever the tool, the data is yours to protect.

The tools did their job. A demo and a product are two different stages, and the second one needs someone to check what the first one skipped.

What production-ready means for a vibe-coded app

"Production" is the version real customers use and pay for. Before a vibe-coded app gets there, these things need to be in place:

1. Security basics. Secrets kept on the server, database rules that only let each user reach their own data, sign-in and roles tested properly, and rate limits on anything public.
2. Your data looked after. Automatic backups you've tested restoring from, and personal data handled under UK GDPR, with a privacy policy that matches what the app actually collects.
3. A test copy. A separate staging version where changes are tried before they reach customers.
4. Monitoring. Alerts when the app goes down or errors spike, so you hear about problems before your customers tell you.
5. Real payments and email. Payment providers switched from test mode to live, with failed payments and refunds handled, and emails sent from your own domain so they don't land in spam.
6. Speed under load. Pages and queries that stay quick when hundreds of people use the app at once.
7. Code you control. The code in a repository you own, such as GitHub, with someone who understands it and can change it safely.

Most of these are quick to put right once someone looks properly. The hard part is knowing which ones apply to your app.

Fix it, rebuild part of it, or start again

Most vibe-coded apps don't need throwing away. When we assess one, it usually falls into one of four routes:

That third case is more common than you'd think. One recent example is an online sailing school's iOS lessons app. The code was written with AI, and it had never been built or run on a phone until we set it up.

What you can check yourself this week

You don't need to be technical to spot the biggest risks. Try these:

• Sign up as a second user. Create two accounts and see whether one can reach the other's data by changing a link or an ID in the address bar.
• Look at your database rules. If your app uses Supabase, open each table and check that row level security is turned on and that each table has rules limiting who can read and change its rows.
• Search your front-end code for keys. In your builder, search the code for "key", "secret" and "sk_". Anything private found there needs moving to the server.
• Check where your code lives. Connect your project to a GitHub repository in your own name, so you're never locked into one tool.
• Find out whether you have backups. If you don't know, assume you don't.

If any of these turn up a problem, that's normal. It's also a sign the app needs a proper review before you take payments.

When to bring in a developer

Keep building with AI while you're still testing the idea with a few friendly users. Bring in a developer when any of these is true:

• You're about to take payments, or store personal data about people you don't know.
• You keep asking the AI to fix the same bug, and each fix breaks something else.
• You need a mobile app in the App Store or Google Play.
• A customer, investor or partner asks how their data is protected, and you can't answer.
• Your monthly bills from the builder and its database are growing faster than your users.

That's the point where a few days of expert work saves months of patching later.

Not sure where your app stands?

If you've built your product with AI or no-code tools and want to know what it needs before real customers arrive, see how we take AI-built and no-code apps to production, or book a call with Tharsh. We'll tell you honestly whether it needs a fix, a partial rebuild or a full one.