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: "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 I see apps that started life in one of these tools all the time. My own path with them is always the same: I don't take over or patch the broken code; I use the prototype as the specification and build the product from scratch. 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. Market rates are in pounds, ex-VAT; my own prices are in euros.
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, backend needs work
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 is strongest at the front end. It can generate backend code, database connections and authentication too, but those parts still need careful configuration, testing and security review. 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 fix your broken AI build — whoever built it or another programmer — a little prep turns a vague, expensive guessing game into a precise diagnosis in hours. Here is exactly what they will need, 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 them 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 them, the first conversation is real engineering, not archaeology. Without it, the first few hours are just someone reconstructing what you already know. If you choose a clean rebuild with me instead, I only need the intent (point 3) and a link to the prototype: I don't take over the code, so no repo access is needed.
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 to triage it yourself.
| Situation | What to choose |
|---|---|
| Deploy fails, but the app runs locally | Rescue — yourself or with whoever built it. Usually environment config, build settings or keys. Fixable in hours, not weeks. |
| One integration is broken or unfinished (Stripe, email, an API) | Rescue — yourself or with whoever built it. Wire it properly, add error handling, test the failure paths. Contained work. |
| Supabase or Firebase rules are wide open | Rescue, urgently — whoever built it should lock down access and 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. The UI and the idea become the specification; the structure is rebuilt properly from scratch — this is exactly my work. |
| 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. |
The rule of thumb: if a developer 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 doesn't mean your work is lost. The design, the copy, the validated idea, the bits v0 made look lovely, all of that carries over as the specification and visual reference. What gets built from scratch is the part underneath that was never production-grade in the first place. I'm just as open about what I do myself: only the clean rebuild — rescuing and patching I leave to you or whoever built it.
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 | Backend, auth and database are generated, but need careful review |
| 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, and they want them straight. For context, independent senior developer day rates in the UK 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. I don't offer fixing or finishing on existing code, so here are my own prices for a clean rebuild from scratch, with your prototype as the specification:
| Scope | Price | What you get |
|---|---|---|
| MVP / PWA | from €2,900 | Sign-in, data and deployment, iOS and Android from one codebase, built to ship |
| Business app | from €6,900 | Payments and local integrations (Stripe, GoCardless, Xero + HMRC MTD) included in the scope, with your validated design as the specification |
| Complex platform | from €14,900 | Heavier data, many 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 reduces your 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.
AI project broke? Don't patch it — rebuild it.
Your Lovable, Bolt or v0 prototype becomes the specification: I keep the screens and flows and build a solid foundation underneath from scratch — backend, data, payments and deployment. MVP from €2,900. Describe what you're building and I'll send a quote within 24 hours — no fog. I own the outcome.
Get a rebuild quoteFrequently 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.
Before you sink another weekend into the fix-and-re-break loop, decide which path is yours: fixing the existing code (yourself or with whoever built it) or a clean rebuild. Whichever it is, the goal is the same: something that actually works in production and is safe to put your name on. If you choose the rebuild, get in touch and tell me what you are building — your prototype becomes the specification — or read more about how I approach app and web development. The first conversation is free, and I will tell you straight.