To fix a vibe-coded app, contain the damage before you touch features: rotate exposed keys and lock down data access, then check login and permissions, payments, the data model, error handling, tests and deployment in that order. A one-day assessment then tells you whether to repair the code in place, refactor it behind tests or rebuild it while keeping the data.
Fixing a vibe-coded app means taking software that an AI tool generated without anyone reviewing the code and making it safe, tested and changeable by a developer who did not write the prompts. The work, also sold as vibe coding cleanup, ends in one of three outcomes: repair (fix defects in place), refactor (restructure working code behind tests) or rebuild (keep the data and product knowledge, replace the code).
My guide to AI-assisted development vs vibe coding defines the term and gives a short rescue order; this one covers the triage, a one-day assessment, the decision and the handover.
What should you fix first in a vibe-coded app?
Fix what can hurt people or money today, then what decides whether later fixes hold. Apps from Lovable, Bolt, v0, Replit, Cursor or Claude Code tend to fail where a demo never looks: the second user, the failed payment, the error nobody prompted for. This is the order I work in.
| Order | Area | What tends to go wrong | First check |
|---|---|---|---|
| 1 | Secrets and data exposure | Secret keys in front-end files, Git history or prompts; tables open to the public key | Scan history and built files; query tables logged out |
| 2 | Authentication and authorization | A hidden button over an open API route; record IDs trusted from the request | Repeat requests as a second user and logged out |
| 3 | Payments | Orders marked paid by the browser; unverified webhooks; events processed twice | Send an unsigned and a repeated webhook on staging |
| 4 | Data model | No owner or tenant on records, duplicated tables, no constraints or migrations | Read the schema next to the screens |
| 5 | Error handling | Errors swallowed or shown raw, no logs, outside calls without timeouts | Force a failure and read the log |
| 6 | Tests | None, or tests that only prove a page loads | List critical flows with no test |
| 7 | Deployment | One database for development and production; manual deploys; untested backups | Restore the latest backup to staging |
The first three rows can leak data or lose money this week; the last four decide whether fixes survive the next change. The OWASP Top 10:2025 ranks Broken Access Control first, at A01, and lists "Mishandling of Exceptional Conditions" as A10. Add no features until rows one to three are closed.
How do you stop secrets and data from leaking?
Rotate first and clean up second. GitHub's guide to removing sensitive data from a repository says "as a first step you need to revoke and/or rotate that secret", because a commit rewritten out of history can survive "in any clones or forks of your repository". Treat any key that has sat in the browser bundle, a repository or an AI chat as exposed.
Next, know which keys may be public. Many of these apps run on Supabase, whose API keys documentation says the publishable key, successor to the legacy anon key, is safe in a web page because "it only reaches what Row Level Security allows". The secret or service_role key "bypasses Row Level Security" and must never go in "a browser, a shipped application, or source control." The Row Level Security guide says "Enable RLS on every table in an exposed schema" and warns that once it is on, the publishable key returns no data "until you create policies." So write and test each table's policy on staging, or the switch will blank the app.
This happens on real platforms. The NVD record for CVE-2025-48757, published May 30, 2025, describes "an insufficient database Row-Level Security policy in Lovable through 2025-04-15" that let unauthenticated attackers read or write tables of generated sites; Lovable disputes it, saying each customer is responsible for its app's data. Lovable's statement of April 22, 2026 says that between February 3 and April 20, 2026 the chat history and source code of public projects "could potentially be accessed" by other users, and that "Private projects and Lovable Cloud were never impacted." If your public project's chat ever held a key, rotate it.
How do you check login, permissions and payments?
Test them the way an attacker would, because a hidden button is not a permission check:
- Sign in as user B and request user A's records by changing the ID in the URL or API call.
- Call every API route while logged out, including admin, export and download routes.
- Run password reset and email change against an address you do not control.
- Confirm roles are enforced on the server or in database policies, not only in the menu.
Payments deserve the same suspicion. Stripe's webhook documentation warns that without signature verification "an attacker could send fake webhook events to your endpoint to trigger actions like fulfilling orders, granting account access or modifying records." It adds that endpoints "might occasionally receive the same event more than once" and that events can arrive out of order. The handler should verify the signature against the raw body, record processed event IDs, never trust a browser success page as proof of payment, and take prices from the server.
How do you assess a vibe-coded codebase in one day?
Spend one working day reading and running the code before anyone promises a fix; a day is enough to decide, not to repair. The plan fits a typical builder app with one front end, one database and a few integrations; larger systems need longer.
- Hour 1, access and inventory. Get the code into a Git repository you own and list the hosting, database, domain, email, payment and AI accounts, with who holds each login.
- Hours 2 and 3, run it. Install it from scratch on a staging copy with test data. Note whether it builds and which main flows fail.
- Hours 4 and 5, security pass. Scan history and built files for secrets, test every table and route as a second user and logged out, and send an unsigned webhook.
- Hours 6 and 7, structure pass. Read the schema beside the screens, look for logic duplicated across files, and run the dependency audit (
npm auditorcomposer audit) and any existing tests. - Hour 8, the verdict. One page: what is exposed, what is broken, what is sound, the recommendation and a priced plan.
Get that page in writing; any developer can work from it.
Should you repair, refactor or rebuild a vibe-coded app?
Repair when the structure is sound and the problems are few, refactor when the app works but every change breaks something else, and rebuild when the data model or security boundary is wrong at the core. Even a rebuild keeps the data, the tested screens and the prompt history as its spec.
| Signal | Repair | Refactor | Rebuild |
|---|---|---|---|
| Data model | Fits the business | Mostly fits; needs constraints or columns | Wrong at the core, such as records with no owner |
| Bugs | Few, in known places | Fixing one breaks another | Core flows do not work |
| Access control | Checks missing but easy to add | Scattered; needs one policy layer | Secret keys in the browser; boundary needs redesign |
| Roadmap | Few new features | Steady feature work ahead | Product has moved away from the build |
| Ownership | Code and data in your accounts | Code and data in your accounts | No full export from the platform |
| What you keep | Code and data | Restructured code and data | Data, screens and product knowledge |
Refactoring in steps is safer than it sounds. Martin Fowler's Strangler Fig article of August 22, 2024 describes new code "built on top of, yet separate to the legacy code base", and says of big-bang replacements of serious IT systems: "we've seen this simple-sounding plan go down in flames most of the time." A prompt-built MVP is far smaller, so rebuilding is more often reasonable, but only when you can name what is wrong at the foundation.
Which questions decide between repair, refactor and rebuild?
Four questions, asked in order once any live leak is contained, settle it; the first answer that points to an outcome decides.
- Can you export the code and data to accounts you own? If not, rebuild; fixes would stay locked in the platform.
- Does the data model fit how the business really works? If not, rebuild and migrate the data, because every screen sits on that model.
- Are the problems limited to a few known areas? If yes, repair in place and add a test around each fix.
- Is the code clear enough to wrap in tests? If yes, refactor in steps behind those tests; if not, rebuild and keep the data.
How long does it take to fix a vibe-coded app?
It depends on the triage list, not the number of screens, so I give a time and a price only after the one-day review. These factors move it most.
| Factor | Shortens the rescue | Lengthens it |
|---|---|---|
| Access | Every account handed over on day one | Waiting on exports, a former freelancer or platform support |
| Data | Small and consistent | Duplicated or in need of migration |
| Scope | The triage list comes first | New features added mid-rescue |
| Tests | Some exist and pass | None, and behavior is undocumented |
| Integrations | One payment provider | Several outside APIs and webhooks |
When a rebuild is the answer and the product is a standard CRM, my fixed-scope custom CRM offer starts from tested base code, not a blank page. For a SaaS rebuild, see SaaS development and the guide to a SaaS MVP tech stack.
How do you keep using AI tools safely after the fix?
Keep the agent and add the gates it skipped:
- Tests as the gate. Every rescued flow gets a test, and a task is finished when the suite passes on a fresh run, not when the agent says so.
- Review every change. Read each diff before it merges, hardest on authentication, payments and migrations.
- Permissions. Claude Code evaluates permission rules "deny, then ask, then allow"; a deny rule such as
Read(./.env)keeps its file tools out of that file, though not a script that opens files itself, which needs its sandbox. KeepbypassPermissionsto "isolated environments like containers or VMs". - Separate environments. The agent uses a development database with test data; production credentials stay in the host's secret store.
- History outside the tool. Lovable's GitHub sync "always creates a new repository" and syncs one branch at a time; Bolt's GitHub integration keeps "a full history of changes that lives outside Bolt." Protect the main branch and merge through pull requests.
My full routine, with rules files, plan mode and hooks, is in my Claude Code workflow for client projects.
What should you hand a developer before the rescue starts?
Hand over access and context, never passwords pasted into a chat:
- Admin access to the Git repository, or the builder's Git sync connected to your own account
- Invitations to hosting, DNS, the database and email service, under the developer's own login
- Every outside service (payments, email, AI APIs, analytics) and who owns each account
- Environment variable names; values go through the host's secret store or a password manager
- Known bugs, each with steps to reproduce and a screenshot
- The flows that must never break, such as signup, login and checkout
- User roles and who may see which records
- Test-mode access to the payment provider
- An export of the prompt history, the closest thing these apps have to a spec
- Your budget, deadline and the decisions you want to keep
What else do people ask about fixing vibe-coded apps?
Can a vibe-coded app be fixed, or does it need a rewrite?
Most can be fixed. A rewrite is justified when the data model or security boundary is wrong at the core, or when you cannot export the code; otherwise repair or refactor keeps what works. The one-day assessment answers this with evidence.
Can vibe-coded apps scale?
They grow as far as their data model allows. The usual limits are missing indexes, logic in the browser, slow work inside web requests and no tests; a refactor fixes those when the model fits.
Is the Supabase key in my front-end code a security hole?
Not by itself. The publishable or legacy anon key is meant to be public and only reaches what Row Level Security allows. The hole is a table with RLS off, a policy that lets anyone read everything, or a service_role key in the browser.
Can I move my app off Lovable or Bolt?
The code can leave through Git: Lovable syncs a project to a new GitHub repository, and Bolt can back a project up to GitHub. The database, secrets, hosting and domain live outside the code, so plan each move.
Do I need a developer to fix my vibe-coded app?
Not for a prototype or internal tool without real data. Once real users, payments or personal data are involved, yes. Some gigs sold as a vibe code fixer cover only the bugs you name, so ask whether they also cover the triage list.
How much does it cost to rescue an AI-generated app?
It depends on what the assessment finds, so any price quoted before someone reads the code is a guess. After the assessment I quote a fixed price for the plan, or bill $55-$65 an hour.
For the assessment, the fix and the handover from one accountable developer, see Hire Claude Code Developer. I build SaaS products and CRMs with Claude Code, with 13+ years and 900+ projects behind me, and review every change before it merges.
Last reviewed 21 October 2026. Disclosure: I am a freelance developer and I sell the rescue work this guide describes, so I am not neutral. I am CTO at ElySpace and founder of WHMCSPilot and MagizAI. I am not affiliated with Anthropic or any tool vendor named here, including Lovable, Bolt, Supabase and Stripe. Vendor statements and documentation were read on their own pages on that date.
