Contents6 sections
Vibe Coding Cleanup: What Breaks After the Demo
An app built in Lovable or Claude Code works on the day it is shown. What fails later is everything around the code, and a cleanup is the wrong unit to buy.
The demo worked
Somebody built a CRM in Lovable over two weekends. Somebody else wired fourteen n8n workflows together over a year, one a week. A sales director opened Claude Code on a Sunday night and by Monday there was an app the whole team uses to book deliveries. Each of those worked on the day it was shown, and each is now a thing the business runs on.
The code the tools write is mostly fine, and where it is not, it is fine in the way a junior developer's code is fine: it does the thing, and it does not know what happens around the thing. The failures that arrive six weeks later are almost never in the function that was demonstrated. They are in what nobody was asked to write.
What actually breaks
Six things, in the order a reading finds them.
The secrets are in the code. The Supabase service key is in the client bundle because that is where the prompt put it. The OpenAI key sits in a file that went into the repository on the first day and has not moved since. Anyone who can open the browser's developer tools has the database; anyone who can read the repository has the bill.
The deployment reproduces on one laptop. It runs where it was built, with the environment variables that were set there once and never written down. The first time somebody else has to deploy it, usually the week the builder is on holiday, nobody can.
The database has no way back. The backups either do not exist or have never been restored from, and there are no migrations, so the schema is whatever the last edit in the dashboard left. The first restore happens on the day it matters, which is the worst day to find out it does not work.
Nobody is watching. Logs either do not exist or go to a console nobody opens, and the auth failing, the queue backing up or the webhook returning a new shape alerts no one. The system fails the way an integration changes underneath you: quietly, on wrong data, for weeks.
The floor moves. Every API key, every webhook format and every model version the system depends on will change without asking. The model it was tuned for gets a retirement date, a provider adds a wrapper to a payload, and the tool the builder used is acquired along with its free tier. Each of these is a change some provider shipped without telling you, because you were never on their list, and none of them will ever show up as an outage.
The runbook is a person. The only documentation is the memory of whoever built it, and they built it on a weekend, which means they do not remember either. Ask them how it deploys and the honest answer is that they would try things until it did.
Why "cleanup" is the wrong unit
The market has already named this work. Search for vibe coding cleanup and the first page is outsourcing shops offering exactly that, a refactor of whatever repository you send, with a quote attached. A Hacker News thread called it cleanup as a service. The shops have the work right and the purchase wrong.
A cleanup is a project. It has a start, a scope and an invoice, and then it ends, and the system is yours again. The next Friday evening it breaks, the person who cleaned it is on another contract, and you are exactly where you were, with a tidier repository. The business needed somebody whose job the system is, and a tidier repository is not that.
That changes the purchase from "how much to fix this" to "what would it take for somebody to be responsible for this", which is a question about the surrounding infrastructure rather than about the code. It is the same question a company used to answer with a systems administrator, when the things it depended on were servers and an accounting package. The things it depends on now are a Lovable CRM, a dozen workflows and an agent, and the question has not changed.
The reading comes before the repair
A cleanup vendor invites you to start fixing. The order that works is to read first, and to read with a fixed list.
- Where do the secrets live?
- Does the deployment reproduce anywhere but the laptop?
- Is there a backup, and has anyone restored from it?
- Does anything log, and is anyone alerted?
- Which APIs and model versions does it depend on, and when do they change?
- Is there a way back that does not go through the builder?
That reading takes about a week for a typical estate, and it ends in one of three sentences. The system can be run as it is, and somebody takes it on. The system can be run after a specific repair, with the scope written down and priced, and nothing outside that scope. Or the repairs would rebuild the architecture rather than surround it, replacing is cheaper than repairing, and the report says so before anyone has spent a month finding out.
The third answer is the one a cleanup never gives, because a cleanup is paid to clean. An agent that decides refunds on its own with no clean line to a person needs a different design, not a tidier repository, for the reasons the last chatbot failed, and knowing that in week one is the cheapest thing on this page.
What it costs to make it somebody's job
There are three, in sequence, and only the first is certain.
The first is a week of reading, priced as a floor because a single Vercel app takes a day and a CRM with eight workflows and two databases takes the whole week. The second is the repair, and only where the reading called for one: deployment, migrations, backups, secrets, logs, the obvious holes, whatever has to hold before somebody is on call. That sprint adds no features, because a repair that grows features stops being a repair. The third is a month that stays a month: monitoring, backup verification, a response window, updates when the floor moves, and a report you can read. New functionality is scoped and quoted on its own, which is what keeps the month predictable.
The comparison worth making is against the cost of the Friday evening, multiplied by how many Fridays a business has before the person who built it leaves, rather than against the cleanup quote; it is the same arithmetic the maintenance line in any automation budget already carries. The vendor comparison on this site puts that row under "yours entirely, including the maintenance nobody scheduled", and it was written about Zapier and Make before anybody had vibe-coded a CRM. It still is.
The estate will grow
A year ago the phrase did not register in search volume. In September 2026 it is a hundred and ten thousand searches a month in the United States and thirty-three thousand in Brazil, and a company that had three IT systems is on its way to having a CRM, eight internal tools, fourteen workflows, three agents, two databases and a project on Vercel that the sales director wrote one Sunday night. There is no arguing against it: it is cheaper software, built by the people who know the process, and it is going to keep coming.
What it needs is a way for the things they build to become somebody's job, and that is what taking a system over is for: the reading, the repair where one is called for, and then the month in which somebody understands how it is built, sees when it breaks, and can put it back.
01Can a vibe-coded app run in production at all?+
Often, yes. The code an AI tool writes is rarely the thing that fails; what is missing is everything around it. The usual findings are secrets sitting in the repository, a database that has never been backed up, a schema without migrations, failures that reach no one, and a deployment only the builder remembers, and each one is a repair with a known scope rather than a reason to throw the app away. Whether a particular app can is what a week of reading decides, and the reading can also conclude that replacing it is cheaper than repairing it.
02What is the difference between a vibe coding cleanup and managed care?+
A cleanup is a project. Somebody refactors the code, fixes what they found, hands it back, and the next incident is yours again, on a Friday evening, with the person who did the cleanup on another contract. Managed care is responsibility: the cleanup happens where a reading says it must, and then somebody stays on the system, watching it, updating the dependencies and the model, verifying the backups, and restoring it when it breaks, for as long as you want them to.
03What should a takeover of a self-built system check first?+
In this order: where the secrets live, whether the deployment reproduces anywhere but one laptop, whether the database has a backup schedule and a rehearsed restore, whether anything logs and anybody is alerted, which APIs and model versions the system depends on and when they change, and whether there is any documented way back that does not involve the person who built it. The order matters because the first three decide whether the system can be handed over at all.
04How do you tell when it is cheaper to replace than to repair?+
When the repairs would rebuild the architecture rather than surround it. An app whose only problems are secrets, backups and deployment is a stabilization sprint. An agent that decides refunds and complaints on its own with no clean line to a person, or a workflow whose data model cannot hold what the business now puts through it, is a rebuild, and a reading that says so early is cheaper than a repair that discovers it in week three.
