# How to Clean Up a Vibe-Coded App: A Two-Week Plan

> How to clean up a vibe-coded app in two weeks: inventory, secrets, access, structure, tests on money flows, deployment and docs, day by day, no rewrite.

Published: 2025-01-29 · Source: https://subxcat.com/articles/clean-up-vibe-code · Author: SUBXCAT

An app built with Lovable, Bolt, Cursor or Claude Code works, and that is exactly why it's scary to touch. To clean up a vibe-coded app doesn't mean rewriting it. It means spending two weeks getting to a point where you know what you have, who can access it, and how to change code without a small prayer before every deploy.

Below is the plan we use ourselves. It assumes one or two people and a project that already has users. New features are frozen for those two weeks; otherwise the order you're building will chase the mess and never catch it.

## Days 1–2: inventory

You can't tidy what you can't see. Start with a list, not with code:

- where the code lives and how many copies exist (a repository, an export from the builder, a folder on someone's laptop);
- which external services are connected: database, hosting, email, payments, AI, analytics;
- whose accounts they're registered to and which card pays for them;
- which domains you own, where DNS lives, who renews them.

This step usually turns up a surprise or two: a service billed to a former freelancer's personal card, or a second database everyone forgot about. Write it all into one file in the repository. It becomes the base of your documentation.

## Days 3–4: secrets and access

Go through the code and the commit history looking for keys. Anything that has ever been in the repository or the client bundle should be treated as leaked: rotate it and move it into environment variables. Add a `.env.example` file listing variable names without values.

Then access. Remove people who no longer work on the project from every service. The company should own the accounts, not a contractor. Turn on two-factor authentication wherever it's missing. This is dull work, and it's usually the most valuable part of the two weeks.

## Days 5–7: structure

Now the code. The goal isn't beauty, it's predictability: you and your AI assistant should both find the right place on the first try.

- Group code by feature: everything about payments together, everything about profiles together.
- Move database and external API calls out of UI components into their own modules.
- Delete obviously dead code: commented-out blocks, unused files, the third version of the same function.
- Rename anything called `data2`, `newHandler` or `utils`.

Do it in small commits, one change per commit. If something breaks, you'll find the cause in a minute instead of an evening.

## Days 8–10: tests on money flows

You don't need to test everything. You need to test whatever costs money or trust when it breaks: sign-up and login, payments and crediting, access to other people's data, anything that sends email or spends quota.

Start with one end-to-end test of the main user path: signed up, paid, got what they paid for. Then add checks for the classic vibe-code holes: a request for someone else's record must be refused, and a repeated payment webhook must not credit twice. Five honest tests beat fifty that confirm the button is blue.

## Days 11–12: deployment

If deploying today means "click the button in the builder" or "SSH in and run `git pull`", make it repeatable. The minimum:

- separate development and production environments with different databases and keys;
- builds and tests run automatically on every push;
- release with one command or on merge to the main branch;
- a clear way to roll back to the previous version.

Test the rollback for real, not in theory. While you're there, confirm a database backup exists and can actually be restored.

## Days 13–14: documentation

Spend the last two days making sure none of this gets lost. Update the README: how to run the project locally, which environment variables it needs, how the main parts fit together, how to deploy, and where the traps are. Move the inventory from day one into it.

A good test of done: a new developer gets the project running on their machine within an hour without messaging you once. If they can't, the README isn't finished.

## What not to do while you clean up a vibe-coded app

Changing the stack, rewriting from scratch, moving to microservices, perfect test coverage. Any of these might be needed eventually, but decide after the clean-up, when you can see what's actually in the way. Quite often, after two weeks of order, nobody wants to rewrite anything anymore.

## In short

- To clean up a vibe-coded app is to make it understandable, safe and predictable, not to rewrite it.
- Start with an inventory of services and accounts, then rotate secrets and prune access.
- Restructure in small commits: by feature, with data access pulled out, minus the dead code.
- Test money, login and access to other users' data first.
- Finish with repeatable deploys, a working rollback and a README that gets the project running without you.

If you don't have the hands for two weeks of this, SUBXCAT can run the plan alongside your team.