A weekend of prompting can now produce a working app. You describe the feature, an AI writes the code, and by Sunday night there is a demo that clicks through and looks real. This style of building has a name now: vibe coding. It is genuinely useful for getting an idea in front of people quickly. The trouble starts when that same prototype gets pushed toward real customers without anyone cleaning up what the model left behind. Claude Code is well suited to that cleanup, and doing it deliberately is the difference between a demo and a product you can stand behind.
What vibe coding leaves behind
A prototype built through fast prompting tends to work on the happy path and nowhere else. The code runs for the exact demo you showed, but the structure underneath is usually thin. Because each prompt solved a local problem, the codebase accretes rather than gets designed. You end up with duplicated logic, inconsistent naming, secrets pasted into source files, and no tests to tell you when something breaks.
Duplicated logic copied across files because each prompt fixed one screen in isolation
Hardcoded API keys and passwords sitting in the repository instead of environment variables
No error handling, so a single bad input takes down the whole page
Missing or fake tests that pass without checking anything real
Dependencies pinned to whatever version the model happened to suggest that day
None of this makes the prototype worthless. It means the prototype is a draft, and drafts need editing before they ship. The goal of a cleanup is not to make the code perfect. It is to make it safe, readable, and cheap to change.
The cost of shipping a prototype as-is
The bill for skipping cleanup arrives later, and it is larger than the time you saved. A Sydney startup that pushes a vibe-coded app straight to production often spends its first month firefighting: a customer hits an unhandled case, a leaked key forces a credential rotation, a small change breaks three other screens because nothing is tested. At a developer rate of around $1,200 a day, two weeks of that firefighting is $12,000 that a two-day cleanup would have avoided. Rebuilding the same app properly from scratch, by contrast, can run past $45,000 once you account for the discovery and design you skipped the first time. Cleanup sits in between, and it is usually the cheapest sensible option.
A cleanup sequence that works with Claude Code
The instinct is to ask the AI to fix everything at once. That produces a large, unreviewable change and usually makes things worse. A better approach treats Claude Code as a careful pair, working in small passes you can read and approve. The sequence below has held up across several rescues.
Get the app under version control and commit the raw prototype untouched, so you always have a baseline to compare against
Ask Claude Code to produce a plain-English map of the codebase: what each file does and how data flows through it
Pull secrets out of source into environment variables and rotate anything that was ever committed
Add real tests for the core paths before changing any logic, so refactors have a safety net
Refactor in small, reviewed commits rather than one sweeping rewrite
Start with a map, not a rewrite
Before touching anything, ask Claude Code to read the repository and describe it back to you. A written map of the modules, the data flow, and the obvious risks does two things. It gives you a shared reference to work from, and it surfaces the parts the original prompting glossed over. You will often find a function doing three unrelated jobs, or two files that quietly duplicate the same logic. Fixing those is far easier once they are named.
Make the tests the source of truth
Vibe-coded projects rarely have tests worth keeping, and the ones the model wrote often assert nothing. Before refactoring, have Claude Code write tests that describe how the core features actually behave, then confirm they pass against the current code. Now every later change has a check behind it. If a refactor breaks a real behaviour, a test fails and you catch it in seconds rather than in a customer's inbox.
Where a rescue beats a rebuild, and where it does not
A cleanup is the right call when the prototype proves the idea works and the core is sound, even if the edges are rough. If the data model is roughly correct and the app does something people want, editing it is faster and cheaper than starting over. A rebuild makes more sense when the foundation is wrong: the wrong database for the job, a security model that cannot be patched, or a structure so tangled that reading it costs more than rewriting. Claude Code can help you make that call by mapping the code first, so the decision rests on what is actually there rather than a guess.
Getting started without breaking what works
Begin with the smallest safe step. Commit the prototype as-is, ask for the map, and fix the secrets before anything else. From there, work one reviewed pass at a time, and keep the demo working at every commit so you never trade a running app for a broken refactor. Australian teams that treat their prototype as a first draft, rather than a finished product, tend to reach a shippable state in days rather than the weeks a full rebuild demands. If you would like a hand turning a vibe-coded prototype into something you can safely put in front of customers, book a brainstorm and we will map the cleanup with you.
