Keep the behavior. Lose the slop.
Cleanup is the wrong product. If your Lovable or Replit or Bolt app is breaking under real customers, the fix is not paying someone to patch generated code that nobody, including the machine that wrote it, ever understood. The patches compound the mess.
The fix is extracting what your app already knows and rebuilding on it. Here is how that works, and what it costs.
you are not the only one
Your situation is normal, and it is measured.
vibe coded apps found publicly exposing sensitive data in a May 2026 scan, most without basic authentication.
The Hacker News →more security flaws in AI-generated code than human-written code, per Veracode.
VeracodeYour prototype was never the problem. Shipping the prototype as the product was.
the reframe
Your broken app is a working specification.
The app in front of you demonstrates, click by click, how your business is supposed to work. Which fields matter on the intake form. What happens when an order is paid but not fulfilled. Who gets the email and when.
You spent weeks encoding that knowledge through prompts, and it lives in the running app right now, even though the code underneath is a hairball.
That behavior is the asset. The code is disposable.
Code used to be expensive, so the default for a broken app was salvage: refactor, patch, limp along. That math assumed the costly thing was writing code. It is not anymore. The costly thing now is a precise understanding of what the app is supposed to do, and your running app already contains it.
the process
Five steps, and you hold the proof at every one.
-
1
Extract the stories
I point Claude Code at your codebase and your running app and pull out the user stories: every workflow, every rule, every edge case your prompting baked in. You review the list. You will find things you forgot were in there, and things that were wrong all along. Better to know before the rebuild than after.
-
2
Pin the behavior in executable specs
I write behavior specs against your running app through the browser: log in as this user, submit this form, expect this result. The specs capture your app's behavior, not its code. That makes them portable. They describe your business, not your codebase.
-
3
Recover the business rules
Stories plus specs plus a read of the code surface the real rules of your operation, in plain language you can check. This document outlives any codebase.
-
4
Rebuild against the specs
I build spec first on a deliberately boring stack that stays up. The specs written against your old app now run against the new one. When they pass, the rebuild is done. Done is a test result, not a vibe.
-
5
You keep everything
Stories, specs, rules document, code. If you ever leave, you leave with the full written record of how your software works. No vendor, including me, gets to hold that hostage again.
None of this is my invention. It is characterization testing, Michael Feathers' twenty-year-old discipline for taming legacy code: capture what the system actually does, then hold it steady while you replace everything underneath. It was always the right way to take over a codebase nobody understands. It was also expensive enough that almost nobody did it. Agents changed the price, not the idea.
And I will be straight with you: the spec-driven build loop is how I build and run CodeMySpec every day, in the open. Pointing that discipline backwards at an existing app is the newer move, and on the call I will tell you exactly how proven each step is.
what it costs
A conversation, then a quote.
A small app with a handful of workflows lands close to that. A real operation costs real money, and you hear a specific number before anything starts. No hourly meter.
Running it: email on your domain, live chat, publishing, reporting.
Stays free, whether or not you ever hire me.
questions
Straight answers.
Why trust this over an agency?
Look at how cleanup agencies describe the work: audit, refactor, contact us for a quote. The deliverable is cleaner code, which you cannot evaluate, on a timeline you cannot verify. This process produces its proof as it goes: the stories and specs land in your hands early, in plain language, and you check them against your own business before the rebuild starts. I have not found a cleanup service that hands you the specification as an artifact you keep. Here it is the point.
What do you need from me?
Access to the running app and the code export, plus a few conversations. You are the oracle for step one: only you know which behaviors are features and which are bugs you have been living with.
Can my current app keep running during the rebuild?
Yes. Nothing in the process modifies your app or its code. The specs drive it through the browser the way a user would, against a test account or a staging copy. You switch over when the new app passes.
What if I only want the specs?
That is a valid stopping point. The stories and specs are written against your business, not my stack. Take them anywhere.
Doesn't "never rewrite from scratch" apply here?
The famous warning is about losing accumulated knowledge: years of edge cases and bug fixes encoded in old code nobody remembers. The warning is correct, and this process is built around it. The first three steps capture that knowledge in executable form before a single line gets rebuilt. A rewrite without specs is a gamble; a rewrite against specs extracted from the running system is a migration with a checklist. The warning also assumes battle-tested code carrying years of fixes. A vibe coded app is months old and carries the opposite: generated bulk nobody ever reviewed.
If your app is holding up and you would rather drive the rebuild yourself, the harness is free to use and this is the same process it runs.
Bring what's broken.
You will get a straight answer on whether a rebuild makes sense, and what it would cost.