What is vibe coding cleanup?
Vibe coding is building software by describing what you want to an AI tool and accepting what it writes. It is genuinely fast at reaching a working screen, which is why so many ideas now get their first version this way.
Cleanup is the engineering pass between that demo and a product people can pay for. Someone who did not write the code reads all of it, tests the flows that carry money and data, and fixes the places where it would fail under real use.
It is not a rewrite by default. Most cleanup keeps the screens and the decisions that already work and repairs the parts a demo never had to prove.
What are the signs an AI-built app needs cleanup?
An AI-built app can look finished from the outside. These are the signs I look for when someone sends me one to inspect.
- Nobody can explain what the database tables are for, or the same fact is stored in two of them.
- Sign-in was added last, so some private screens can still be opened without it.
- Keys or passwords sit in the browser code where any visitor can read them.
- One failed payment or a dropped connection leaves a blank screen.
- There are no tests, so nobody can change a screen without guessing what else breaks.
- The same rule is written in three places and the three versions disagree.
- Nobody has loaded it with more than a handful of records.
- It has never been through store approval, or it was rejected and nobody knows why.
What does cleanup involve?
The work follows whatever the code read turns up, in the order that removes the most risk first. In most projects it lands in the same few areas.
| Area | What gets checked | What usually changes |
|---|---|---|
| Data | Tables, relationships, duplicates and missing rules | A structure and migrations that match how the app actually works |
| Access | Sign-in on every private screen, and what each user can see | Permission checks on the server, not just hidden buttons |
| Secrets | Keys in the browser, in the repository and in the logs | Keys moved to the server and replaced |
| Payments | Failure, refund, retry and a double tap on Pay | One payment path with states that can be tested |
| Errors | What a user sees when a request fails | A message and a retry instead of a blank screen |
| Tests | Which flows are covered and what breaks on change | Tests on the flows that carry money and data |
| Speed | First load, long lists and a weak connection | Pagination, caching and lighter screens |
| Stores | Privacy, permissions and store rules | The settings and disclosures Apple and Google require |
Cleanup or rebuild: which is cheaper?
A rebuild is not automatically cleaner. Starting again throws away the screens that work and every decision already tested with users, and it can repeat the same mistakes if the plan does not change.
Rebuild when the data model is wrong at the root, when the tool cannot give you usable code, or when every screen depends on every other one and no part has ever been tested. Clean up when the main flows work with real data and the problems are concentrated in a few areas.
A code read decides it. I read the code, test the main flows and write a verdict that prices both routes, whether or not you hire me for the work.
| What the read finds | Cleanup | Rebuild |
|---|---|---|
| Main flows work with real data | Usually the cheaper route | Rarely worth starting over |
| The tool cannot export usable code | Not possible | Rebuild in code you own |
| The same fact is stored in three tables | Possible, but expensive | Often cheaper over time |
| The problems are access, keys and payment states | This is cleanup work | A rebuild repeats them unless the plan changes |
What does vibe coding cleanup cost?
Cleanup is quoted as one fixed price after a code read, because the number follows what is actually in the repository rather than what the demo shows. Small jobs start at $50 for a single fix or a look at one screen.
A cleanup that touches payments, permissions and tests is a build-sized job. It is still usually less than a rebuild, and you keep the parts that already work. The code read is the cheapest way to find out which route you are on, so ask for it before agreeing to any number.
Can you work with apps built in Lovable, Bolt, Base44 or Replit?
Yes. What the tool exported matters more than which tool it was. If it gives you a code repository, the cleanup happens in that code and nothing has to be thrown away first.
If it only gives you a hosted app with no usable export, the first job is getting the data out and deciding whether the screens are worth rebuilding. Either way, you end up owning the code, the data and the accounts.
What should I prepare before a code read?
The read goes faster when I can see the app as a user sees it and reach the code in the same session.
- A link to the live app, and a test login for each kind of user.
- Access to the code repository, or an export from the tool that built it.
- A short list of what worries you most, even if it is only a feeling.
- The flow that makes money, described in a sentence, so I test that one first.
What to remember
- A working demo is the start of the engineering, not the end of it.
- AI writes plausible code. Permissions, payments and failure states still need a person to check them.
- Cleanup beats a rebuild when the data model and the main flows are sound.
- Get a written code read before you agree to a cleanup price or a rebuild.
Sources
Primary documentation, for anyone who wants to check the details.