Vibe Coding: Why an AI Prototype Is Not a Product

A founder came to me recently with a sentence I now hear more and more often: "I've already built the app, it works, I just need someone to finish the last bit." I opened his screen and, sure enough, it worked. Clean interface, buttons that clicked, data that appeared. The whole thing had been built in a few days with Lovable, barely a line of code written by hand. The problem was that "the last bit" turned out to be everything that separates a demo from a product. And there was more of that "last bit" than there was of everything he'd already done.

This phenomenon has a name now: vibe coding. It was Collins Dictionary's Word of the Year for 2025, so most readers already know it. In this article I'll explain what it actually is, why it's brilliant for a prototype and dangerous for a product, exactly what a vibe-coded app lacks, when it's genuinely enough (yes, sometimes it really is), and how to turn that prototype into a real, production-ready product without setting fire to your budget.

What vibe coding actually is

Vibe coding is building an app not by writing code, but by describing what you want to an AI tool in plain English. "Build me a to-do app with login and a dark mode" and a few seconds later you've got a working screen. Don't like the colour? Ask it to change. Missing a button? Ask it to add one. You're not writing code line by line; you're steering by vibe: ask, look at the result, ask it to fix.

The tools that do this are well known by now: Lovable and Bolt generate a whole app, v0 spins up the interface, Cursor, Replit and ChatGPT write code from a conversation. It's genuinely impressive and I'm not knocking it; I use AI coding assistants every day in my own work. The question was never "can AI write code". It's "will what it wrote survive the real world".

Because vibe coding has one invisible property: it's optimised to look like it works. The AI generates code that passes the obvious test, where you click a button and something happens. But "works on my screen" and "works in production for real customers" are two completely different things, and between them sits exactly the work the AI doesn't do on its own. It builds you 80% and the last 20% is the hard part.

Brilliant for a prototype, dangerous for a product

A prototype has one job: to prove the idea. It's enough for it to work, once, for you, on the happy path (my name for the scenario where the user does everything right and nothing falls over). If you want to show an investor what your service will look like, or check for yourself whether the idea has legs at all, vibe coding is unbeatable here. What used to take a week and a few thousand pounds now takes an afternoon. That's a real, enormous upside.

A product has a completely different job. A product has to work not for you, but for strangers. On a bad connection. With data typed in wrong. With someone deliberately trying to break it. At 3am while you're asleep. Six months from now, after a library changed underneath it. With a thousand users at once, not one. That's where a vibe-coded prototype starts to crumble, and it crumbles not where you can see it, but where you can't, until it's too late.

7 things a vibe-coded app lacks

When I take on a vibe-coded project, the same seven things are almost always missing. Not because the AI is "bad", but because it generates what you ask for, and nobody asks for these, because you don't even know they exist until they become a problem.

What's missing	Why it matters in production
1. Automated tests	Without tests, every change is a gamble. You fix one thing and silently break another. Vibe-coded code almost never has tests, so the project gets more fragile the more anyone touches it.
2. Error handling	What happens when the connection drops, the server doesn't answer, or a user pastes in rubbish? In a prototype: a white screen or a crash. In a product you need a clear message, a fallback path and the error quietly logged so you can act on it.
3. Security	Exposed API keys sitting in the code, an open Supabase or Firebase database where anyone can read other people's records, no input validation. This is the most common and most dangerous vibe-coded gap, and it gets exploited in minutes.
4. Data migrations	When you add a field or change the structure, the user data you already hold has to move across without loss. In a vibe prototype the schema is changed by deleting and recreating; in production that means deleted customers.
5. Monitoring	In production you need to know about a problem before your users do. With no error tracking or logs, you can't see that half your users can't log in. You find out only when they stop coming back.
6. Scale	Code that's fine with one user can fall over with a hundred. Unoptimised queries, no caching, everything on one thread: irrelevant to a prototype, fatal to a product on its first successful day.
7. Maintenance	Libraries age, security holes appear, payment and login rules change. A product needs ongoing upkeep. Vibe-coded code that nobody understands becomes unfixable after the first serious outage.

Notice the pattern: not one of these seven is visible to the user while everything is fine. They all surface on that one bad day, and they're precisely why a product is slower and more expensive to build than a prototype. This isn't polish for the end. It's the foundation. It's also where most of the "technical debt" people talk about quietly accumulates.

When vibe coding is genuinely enough

Now for the most important and most honest part of this article. Vibe coding isn't "bad". There are plenty of cases where it isn't just enough but is the smartest choice you can make. If you land in one of these, don't hire me, save your money and build it yourself.

When vibe coding is no longer enough

And now the other side. There's a line beyond which "looks like it works" becomes a risk that costs far more than you saved by building it. You cross that line the moment people you don't know start using the app, or the moment money moves through it.

Vibe coding is enough	You need a professional rebuild
Only you or a small trusted circle use it	Real customers you've never met use it
No money in the system	Payments, subscriptions, checkout (Stripe, PayPal, Apple Pay)
Data doesn't matter or is public	Personal data, UK GDPR, ICO registration, customer privacy
A breakage costs nothing	Downtime means lost customers or reputation
Lives for a few weeks	Has to run and be maintained for years

The moment real customers or payments appear, each of those seven missing things turns into a liability. An unprotected database full of your customers isn't a technical nicety any more; under the UK GDPR and the Data Protection Act 2018 it's a breach, with no small-business exemption. A vibe-coded app typically ships no privacy policy, no lawful basis, no cookie/PECR consent and no ICO registration, all baseline expectations. Payments with no error handling are money that vanishes between you and your acquirer. At this point it's no longer a vibe coding question. It's a product question.

How to turn a vibe prototype into a product

The good news: a vibe prototype is rarely wasted work. It's an excellent head start. You've already decided what the app does, how it looks, what the logic is. That's the most valuable and the hardest-to-write part of any spec, and it's already done. What's left is closing that hard 30% that's the reason a prototype isn't a product.

When someone comes to me with a vibe-coded project, the first thing I do is review the repo and decide one question: build on the existing code, or rebuild it cleanly. The decision is driven by the structure of the code, not the amount of it. If the logic and data model are sound, I build on them and add the missing layer. If the code is chaotic, with exposed keys and unmanaged state, a clean rebuild is faster and cheaper than patching. I write more about what happens when AI code starts breaking and "fixing" it makes things worse in "Lovable, Bolt, v0, Cursor: what to do when your AI code breaks".

My offer is never "I'll tidy up your code". It's "I'll build it so it works and earns". The difference is fundamental: tidying code is cosmetics, whereas building a product means your customers can use it, pay through it and come back without drama, and you can sleep at night. I take it over and own the outcome.

The real numbers

Concretely on cost, because you'll ask anyway. If a vibe prototype already has the logic and screens, a clean rebuild to production (authentication, security, deployment and basic integrations) typically costs from £3,000 to £8,000 + VAT (~€3,500-€9,400). More complex products with payments, accounting integrations and an admin panel start from around £8,000 + VAT. Timelines are usually 2 to 6 weeks, depending on how far the prototype got.

If you'd rather not commit to a full rebuild blind, the sensible first step is a fixed-price health check at £500 to £1,500 + VAT: I review the repo and tell you, with a fixed quote and timeline, whether to build on the existing code or rebuild. My day rate sits in the normal range for an independent senior UK developer, £400 to £650 + VAT per day, the rate you'd expect from someone who can actually ship to production rather than a £5/hr marketplace gamble.

That might sound like a fair amount for an "almost finished" project. But remember the seven missing things: you're not paying for polish, you're paying for the foundation, without which the app isn't a product, just a photograph of one.

Frequently asked questions

What is vibe coding?

Vibe coding is building an app by describing what you want to an AI tool in plain English (Lovable, Bolt, v0, Cursor, ChatGPT) and letting it generate the code. You don't write code line by line; you steer by vibe: ask, look at the result, ask it to fix. It's brilliant for a quick prototype, but the generated code usually lacks what production needs: tests, error handling, security, monitoring.

What is the difference between a prototype and a product?

A prototype only has to prove the idea, so it's enough that it works on your screen on the happy path. A product has to work in production for real users, on bad connections, with rubbish inputs and bad actors. The difference is tests, error handling, security, data migrations, monitoring, scale and maintenance, which is exactly what a vibe-coded prototype usually does not have.

Can I launch a vibe-coded prototype straight into production?

You technically can, but I wouldn't advise it for real customers or payments. A vibe prototype typically lacks security (exposed API keys, an open Supabase or Firebase database), error handling and monitoring, and frequently ships no privacy policy or GDPR basics, which is a real legal exposure in the UK. The first bad actor or first unexpected input topples it. Before launch you need someone to close the hard 30%: security, data, deployment and edge cases.

When is vibe coding genuinely enough?

Vibe coding is enough when the app holds no one else's data and takes no money: an internal tool for a few people, an investor demo, a quick visualisation of an idea, a personal project. If only you or a small trusted circle use it, a vibe-coded build saves real time and money, and in that case I genuinely wouldn't suggest hiring a developer.

How much does it cost to turn a vibe prototype into a real product in the UK?

It depends on how far the prototype got. If the logic and screens already exist, a clean rebuild to production with authentication, security, deployment and basic integrations typically costs from £3,000 to £8,000 + VAT. More complex products with payments, accounting integrations and an admin panel start from around £8,000 + VAT. The hardest and most expensive part is always that final 30%, not the start. A fixed-price audit first costs £500 to £1,500 + VAT.

Should I keep building on the vibe-coded code or rebuild from scratch?

The decision is driven by the structure of the code, not the amount of it. If the prototype's logic and data model are sound, I can often build on them and just add the missing production layer. If the code is chaotic, with exposed keys and unmanaged state, a clean rebuild is faster and cheaper than patching. I decide after reviewing the repo, and I always choose the path that gets you to a working, maintainable product for less.