An app built in a few days with Lovable, barely a line of code written by hand, can look finished: a clean interface, buttons that click, data that appears. But what looks like "the last bit" is often everything that separates a demo from a product, and there is more of it than of everything done so far.
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 know these tools well. 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.
The most dangerous vibe coding illusion
When an app looks 90% finished, your instinct says there's 10% of work left. The reality is the opposite: the visible part (the interface, the buttons, the screens) is the easy bit that AI does well. The invisible part (security, data, edge cases, deployment) is both the hardest and the most expensive. That hard 30% is the bit nobody quotes you for. I covered it separately in "You started building an app with AI and got stuck: what to do next".
7 things a vibe-coded app lacks
In the vibe-coded prototypes people show me, 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.
Here, vibe coding really is enough
- An internal tool for a few people. A calculator, a tracker, a simple system your team uses. If it holds no one else's data and takes no money, build it with AI and don't overthink it.
- A demo for an investor or client. You need to show what the idea will look like. Nobody cares what's under the bonnet when the goal is to convince, not to serve real users.
- Visualising an idea for yourself. You want to see whether your concept has any legs before investing real money. A vibe prototype answers that question for the lowest possible cost.
- A personal project. A hobby, a side tool, something just for you. If it breaks, it breaks for one person, and you'll live with it.
The rule of thumb is simple: if the app holds no one else's data and takes no money, vibe coding is probably enough for you.
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, I don't take over or patch its code — I build the product cleanly from scratch, and the prototype becomes the specification and visual reference. The general logic is worth knowing either way: whether to build on the existing code or rebuild is driven by the structure of the code, not the amount of it. If the logic and data model are sound, the missing layer can be added on top of the existing code — by you or by whoever built it. 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".
The path from prototype to production
- Specification. From the prototype I take the screens, flows and logic you've already worked out, and write down what the product has to do — including what the prototype never did.
- A solid foundation. A secured database, proper authentication (Auth0, Clerk, Supabase Auth, passkeys), hidden keys, input validation: the things you can actually build on.
- The hard 30%. Payments, integrations, error handling, edge cases. In the UK this usually means real integrations the AI won't wire up: Stripe or PayPal checkout (hosted, to reduce PCI-DSS scope), GoCardless for Direct Debit subscriptions, Xero or QuickBooks for accounting and HMRC Making Tax Digital for VAT.
- A safety net. Tests, monitoring and logs so you hear about a problem before your customer does.
- Deployment and maintenance. A real domain, real hosting, backups, accessibility (WCAG matters once larger or public-sector clients are involved) and a clear agreement on who maintains it next.
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 build it and own the outcome.
The real numbers
Concretely on cost, because you'll ask anyway. A clean rebuild based on your vibe prototype — with authentication, security and deployment — starts from €2,900 (MVP / PWA, iOS and Android from one codebase). A business app with payments, accounting integrations and an admin panel starts from €6,900, a complex platform from €14,900. Timelines are usually 2 to 6 weeks, depending on scope and on how clearly the prototype already defines what the product has to do.
You don't have to commit blind, either: tell me what you're building, send a link to the prototype, and you'll get a fixed quote and timeline for the clean rebuild — I don't need your code for that. For comparison, independent senior UK developers typically charge £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.
Got a vibe-coded prototype? I'll turn it into a real product.
Your Lovable, Bolt, v0 or Cursor prototype becomes the specification: I keep the screens and flows and build a solid foundation underneath from scratch — security, data, payments and deployment. MVP from €2,900. Tell me what you're building and within 24 hours you'll get a quote with price and timeline. Run by Webxpert, MB, a registered company, with a real UK-facing contact.
Rebuild my prototypeFrequently 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 what the product has to do. A clean rebuild based on your prototype — with authentication, security and deployment — starts from €2,900 (MVP / PWA, iOS and Android from one codebase). A business app with payments, accounting integrations and an admin panel starts from €6,900, a complex platform from €14,900. The hardest and most expensive part is always that final 30%, not the start.
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, adding the missing production layer on top of the existing code can make sense — that's something you can do yourself or with whoever built it. If the code is chaotic, with exposed keys and unmanaged state, a clean rebuild is faster and cheaper than patching. I only work the second way: I don't take over someone else's code; I build the product from scratch, using your prototype as the specification.