The message always arrives in roughly the same shape. "I built the whole thing in Lovable over a weekend, it was working, and now it just won't deploy." Or: "Bolt got me 90 percent there but every time I ask it to fix the login it breaks the checkout." Or my personal favourite, sent at 1am: "ChatGPT built my app, it looks brilliant, but I have no idea what any of this code does and now it's down."
If that is you, take a breath. You have not done anything stupid. Vibe coding is a genuinely useful way to validate an idea cheaply, and the tools, Lovable, Bolt, v0, Cursor, Replit, are far better than the no-code platforms we had a few years ago. The problem is not that you used them. The problem is the well-worn truth of this whole category: the AI builds you 80 percent, and the last 20 percent is the hard part. That last fifth is where production lives, and it is exactly where these tools quietly fall over.
I am a senior developer, and a growing slice of my work is now taking over apps that started life in one of these tools. So this is the practical version: where each tool tends to break, why the AI keeps re-breaking the same code, what to get ready before you reach out to anyone, and how to decide whether your project is worth rescuing or cheaper to rebuild. Prices are in pounds, ex-VAT, the way a UK buyer actually receives a quote.
Why AI gets you to 80 percent and then stalls
The reason is structural, not a skill issue on your part. These tools are extraordinary at producing the visible, well-trodden parts of an app: a tidy landing page, a form, a dashboard layout, a CRUD screen that looks the part. There are millions of examples of those in the training data, so the model is fluent.
The last 20 percent is the bit that is specific to your app and rarely written down: the awkward edge cases, the security rules, the integration that needs a real API key and a webhook that actually fires, the error handling for when a payment fails, the data model that has to stay consistent as the app grows. That is the work a human developer is actually paid for. The AI does not skip it because it is lazy; it skips it because that part cannot be pattern-matched from a prompt. It is judgement, and judgement is precisely what does not generalise.
The 80/20 in plain terms
The 80 percent the AI nails is what you see in the demo. The 20 percent it misses is what keeps the thing alive in production: security, data integrity, reliability under real users, and UK compliance. The demo convinces you it is done. Production is where you find out it is not.
Where it breaks, tool by tool
Each tool has a characteristic failure mode. Knowing yours saves a lot of guesswork.
Lovable — deploy and the database
Lovable is one of the strongest tools for getting a full-stack app stood up quickly, usually on Supabase. The two places it bites are deploy and data. The app runs beautifully inside Lovable's preview, then refuses to deploy, or deploys and immediately throws errors because environment variables, build settings or the Supabase connection were never properly wired for the real world. The deeper issue tends to be the database: row-level security rules left wide open (so anyone can read everyone's data), a schema that drifted as you added features, and migrations that were never tracked. The fix usually starts by exporting to a GitHub repo so you are working with the actual codebase, not the editor.
Bolt — state and integrations
Bolt (bolt.new) is fast and great fun, and it tends to break on state and integrations. As the app grows, the client-side state gets tangled: data that should persist resets, a value updates in one place but not another, and the longer you ask it to patch, the more fragile it gets. Integrations are the other wall, the Stripe checkout, the email send, the third-party API, that work in a happy-path demo but have no error handling and fall over the moment a real user does something slightly unexpected.
v0 — beautiful UI, no backend
v0 (from Vercel) is, frankly, excellent at what it is for: generating gorgeous, on-brand React and Tailwind interfaces. The trap is expecting it to be more than that. v0 produces the front end. It does not give you a real backend, a database, authentication or business logic. People build a stunning UI, assume the app is "nearly done", and then discover that none of the buttons actually do anything because there is nothing behind them. That is not v0 failing; it is v0 being used for the whole job when it only does the front half.
Cursor — it generates, but you have to understand it
Cursor is a different animal. It is an AI coding assistant inside a real editor, aimed at people who can read code. It will happily generate large amounts of working code, and that is the catch for non-developers: it produces a real, full codebase that you then own and have to maintain. If you cannot read what it wrote, you cannot tell good architecture from a quietly accumulating pile of technical debt, and you will not spot the security hole or the broken assumption until it is in production. Cursor does not protect you from yourself, and it does not pretend to.
The UK gaps almost every AI build ships with
- No privacy policy or lawful basis. UK GDPR and the Data Protection Act 2018 apply to every business, with no small-business exemption. The AI does not write these for you.
- No cookie or PECR consent. If there is analytics or tracking, you need a proper consent banner, not a decorative one.
- No ICO registration. Most businesses processing personal data must register with the ICO and pay the annual fee. AI builds never mention it.
- Insecure Supabase or Firebase rules. Default-open database rules are common, meaning anyone can read or write your users' data.
- No real error handling. When a payment or API call fails, the app often just breaks instead of recovering gracefully.
Why the AI "fixes" it and then breaks it again
This is the moment that drives people to despair, and it has a clean explanation. You ask the AI to fix the login. It fixes the login, and breaks the checkout. You ask it to fix the checkout. It fixes the checkout, and re-breaks the login. You are now in a loop, burning a weekend, convinced the thing is cursed.
It is not cursed. The model has no durable memory of your whole project. Each time you prompt it, it only sees a slice of the codebase, the part in its context window, not the entire system and all its interdependencies. So when it changes one screen, it cannot see the constraint three files away that depended on the old behaviour, and it quietly violates it. The bigger your app gets, the smaller the fraction the AI can hold in its head at once, so the regressions get more frequent, not less. This is context loss, and it is fundamental to how these tools work, not a bug that the next version patches away.
A human who actually understands the full system holds the whole model in their head, or at least knows where to look. That is the line you cross at a certain size: below it, prompt-and-pray works; above it, you need someone who can reason about the entire codebase. I dig into where that line sits, and how to tell a throwaway prototype from a real product, in my piece on vibe coding: prototype versus product.
What to prepare before you reach out
If you are going to ask a developer to look at your broken AI build, a little prep turns a vague, expensive guessing game into a precise diagnosis in hours. Here is exactly what I ask for, and why it helps.
Your pre-rescue checklist
- Export the code to a Git repo. Lovable, Bolt and Cursor can all push to GitHub. The repo is the real codebase; the visual editor is not enough to work from. Share access.
- List the tools you used. Lovable, Bolt, v0, Cursor, ChatGPT, Claude, Replit, in what order. It tells me instantly where to expect the weak points.
- Describe what the app is meant to do. In plain English, the intent. What is it for, who uses it, what is the one thing it must do reliably.
- Note exactly what breaks. Which screen, what you click, what you expected, what actually happened. Steps to reproduce are gold.
- Gather the access. Hosting (Vercel, Netlify), the database (Supabase, Firebase), Stripe or PayPal, any API keys. You do not have to hand them over blind, but knowing what exists matters.
With that in front of me, the first conversation is real engineering, not archaeology. Without it, the first few hours are just me reconstructing what you already know.
Rescue or rebuild?
This is the question everyone wants answered, and the honest answer is "it depends, but the deciding factors are knowable". Here is how I actually triage it.
| Situation | What I do |
|---|---|
| Deploy fails, but the app runs locally | Rescue. Usually environment config, build settings or keys. Fixable in hours, not weeks. |
| One integration is broken or unfinished (Stripe, email, an API) | Rescue. Wire it properly, add error handling, test the failure paths. Contained work. |
| Supabase or Firebase rules are wide open | Rescue, urgently. Lock down access, add proper auth checks. This is a data-breach risk, not a nice-to-have. |
| The data model is wrong and everything depends on it | Lean rebuild. A bad schema poisons everything above it; cheaper to redo the foundation than patch around it forever. |
| Every change breaks three other things | Rebuild. The architecture has no clean seams. Reuse the UI and the idea, rebuild the structure properly. |
| Security can't be fixed in place (auth, payments, data handling) | Rebuild on a solid base. You cannot bolt safety onto an unsafe foundation, especially with UK GDPR in play. |
My rule of thumb: if I would spend longer understanding and untangling the AI code than writing it cleanly, a rebuild is cheaper over the life of the product. And a rebuild rarely means starting from zero. The design, the copy, the validated idea, the bits v0 made look lovely, all of that carries over. What gets rebuilt is the part underneath that was never production-grade in the first place.
Which tool suits what — and where its wall is
None of these tools is bad. They are just being asked to do jobs they were not built for. Here is the honest map.
| Tool | What it's good for | Where the wall is |
|---|---|---|
| Lovable | Full-stack prototypes fast, validating an idea with real data on Supabase | Deploy config, database security, schema drift once the app grows |
| Bolt | Quick working web app, demos, getting an MVP in front of users | State management at scale, real integrations and error handling |
| v0 | Beautiful, on-brand React and Tailwind UI, design exploration | No backend, no auth, no database, no business logic at all |
| Cursor | Speeding up a developer who can read code, real codebases | Useless as a safety net if you can't review what it writes |
| ChatGPT / Claude | Snippets, explaining code, unblocking a specific problem | Whole-app context, consistency across a growing project |
Real price bands
UK buyers want numbers, ex-VAT, and they want them straight. So here they are. Independent senior developer day rates run roughly £400 to £650/day (~€470 to €760/day) + VAT, with London and very senior at the top of that. A £450-a-day quote is not the expensive option; it is the rate of someone who can actually ship to production, as opposed to a £5-an-hour marketplace gamble that turns into a second rescue job.
| Engagement | Typical cost (ex-VAT) | What you get |
|---|---|---|
| AI app health check / audit | £500 – £1,500 (~€590 – €1,750) | A clear, plain-English diagnosis: what's broken, what's a security risk, rescue or rebuild, and a fixed quote for the next step |
| Remediation / finishing work | £3,000 – £15,000+ | Fixing deploy and integrations, securing the database, adding error handling and UK GDPR basics, getting it live |
| Full production rebuild (simple web MVP) | £12,000 – £25,000+ | A clean, owned codebase built to ship and scale, reusing your validated idea and design |
| Complex / AI / compliance-heavy rebuild | £25,000+ | Heavier data, integrations, accessibility (WCAG) and regulatory requirements done properly |
Payments, by the way, are where the rebuild often pays for itself: a properly hosted Stripe or PayPal flow keeps you out of PCI-DSS scope, and Apple Pay and Google Pay are now expected at UK checkout. The AI build rarely sets any of that up correctly. There is a fuller breakdown of how these "free" AI builds add up in my article on the real cost of a free AI-built website.
Your AI project broke and won't un-break?
Start with a fixed-price health check (£500–£1,500 + VAT). I'll tell you plainly what's wrong, whether to rescue or rebuild, and what it costs. I take it over and own the outcome.
Book a health checkFrequently Asked Questions
In short
You used the right tool for the right job, validating an idea fast, and then asked it to do a job it was never built for, running in production with real users and real data. That is not a failure on your part; it is the predictable seam in vibe coding, and it is exactly where a senior developer earns their keep.
Export your code, write down what it is meant to do and what breaks, and get an honest health check before you sink another weekend into the fix-and-re-break loop. Whether the answer is a quick rescue or a clean rebuild, the goal is the same: something that actually works in production and is safe to put your name on. If you would like me to take a look, get in touch or read more about how I approach app and web development. The first conversation is free, and I will tell you straight.