Vibe code cleanup

From prototype to live users.

Vibe code cleanup and Lovable rescue: I audit, refactor, and harden AI-built apps (Lovable, Cursor, Bolt, Claude Code, Replit) and ship them to live users. The Agency Hub case study is the named example.

Vibe code cleanup (also called vibe code rescue) is the process of taking a vibe-coded application built with Lovable, Cursor, Bolt, Claude Code, Replit, or similar AI tools and hardening it for production: security audit, RLS and authorization fixes, schema validation, error handling, monitoring, and shipping to live users. Specialists charge $150 to $200 per hour. Engagements run from two-week audits to multi-month rebuilds. The Agency Hub case study is one example.

Most vibe-coded apps look great in the demo and break under load. The AI tools that generate them are good at producing something that runs. They are not good at producing something that survives the first ten real users, the first credential leak, the first race condition on a shared resource. The gap between “ships in a demo” and “ships to live users” is the gap I close.

How the cleanup works

The pattern is the same across Lovable, Cursor, Bolt, Claude Code, and Replit handovers. Four phases, run in order, with a human gate between each.

The first commit is a workspace, not a fix. CLAUDE.md at the project root listing every system the AI is allowed to touch, every rule it has to follow, every credential boundary. An ISSUES.md log of every bug found on first exploration. Most vibe-coded handovers arrive light on docs and lighter on commit reasoning. The audit makes the missing parts explicit before any code moves.

Vibe-coded builds frequently miss the boring parts: RLS policies that should have been on every Supabase table, authorization checks that should have gated every mutation, validation schemas that should have rejected malformed input. Most of the bugs in a cleanup project are not in the feature code. They are in the absence of the safety code. I write the safety code first.

AI-generated code tends to be locally correct and globally surprising. Functions duplicate. Schemas drift between layers. Type definitions exist or don’t depending on which session generated the file. The refactor pass consolidates the duplications, aligns the schemas, and adds the type definitions that should have been there from day one. The goal is a codebase that survives a second developer joining the project, not a codebase that only the AI understands.

Production deployment with the safety hooks added before the first AI session, not after the first incident. Monitoring connected so silent failures surface. A rotation playbook in writing so the next BOLA disclosure (or equivalent) takes hours instead of days. The Agency Hub rescue survived a Lovable-platform BOLA disclosure in hours because the documentation was already there.

Lovable rescue specifically

A note on the platform that drives most of the cleanup work I see. Lovable plus Supabase is the dominant vibe-coding stack in 2026, and the dominant source of cleanup engagements. The platform ships fast and the integrations are deep, but the production-ready bar is the developer’s responsibility to clear. Common patterns on a Lovable rescue: RLS policies missing on multi-tenant tables, publishable-key auth misconfigured, schemas that drift between the web app and any Chrome extension or mobile shell, no monitoring connected. The Agency Hub case study is a Lovable plus Claude Code plus Supabase rescue that hit each of these. The work is repeatable.

The proof: Agency Hub

A real cleanup, shipped, with the receipts.

Agency Operations · Lovable + Supabase

Agency Hub: Lovable handover → 73 bugs → live users

Lovable plus Claude Code plus Supabase handover. 73 bugs closed in the prep pass. Shipped to live users in six weeks. BOLA security disclosure survived in hours because the documentation was already in place.

  • 73 Bugs closed
  • 6 weeks Time to ship
  • Survived BOLA disclosure
Read the case study →
Agency Hub vibe code rescue on Lovable and Supabase

Engagement terms

Same as the rest of my practice. Hourly only. $60 per hour. Tracked via Upwork or similar; weekly invoices; no setup fee, no padding. Minimum is a few hours of scoping discovery; no commitment beyond that until you are confident. Most cleanup engagements run two to eight weeks for the audit and harden phases; refactor and ship can extend into ongoing work afterward.

If you give me access to your repo when you book the call. I will tell you whether the build is rescuable in its current shape, or whether a rewrite is the honest answer. The decision happens once, with you in the loop.

Before the call

Common questions.

What kinds of vibe-coded builds do you clean up?
Lovable, Cursor, Bolt, Claude Code, GitHub Copilot, and combinations of these. The platform matters less than the pattern: a working demo with auth gaps, missing authorization checks, validation schema drift, and no monitoring. If the brief is 'we're onboarding live users and we're nervous,' the cleanup applies. Both 'vibe code cleanup' and 'vibe code rescue' describe the same engagement; I use the terms interchangeably.
Do you specialize in Lovable rescue?
Yes. Lovable plus Supabase is the dominant vibe-coding stack in 2026, and the dominant source of cleanup engagements I see. The Agency Hub case study is a Lovable plus Claude Code plus Supabase rescue: web app plus Chrome extension, 73 bugs closed in prep, BOLA disclosure rotation in hours, shipped to live users. I am familiar with the Lovable plus Supabase auth and RLS gotchas, publishable-key migration patterns, and schema-drift issues between Lovable's frontend and any companion app.
How long does a cleanup audit take?
Two weeks is the typical first phase. That covers exploring the codebase, writing the workspace docs (CLAUDE.md + ISSUES.md), finding the bug inventory, and surfacing the missing RLS / auth / validation work. Two weeks gives me enough signal to tell you whether the rescue is two more weeks or two months.
What does the audit deliver?
A written audit document covering security boundaries (RLS, authorization), data validation gaps, schema drift between layers, missing monitoring, and a prioritized issue tracker. Plus the workspace files at the repo root so the next AI session inherits the rules. The audit stands on its own; you can take it to another developer if we are not a fit.
What if my build is too far gone?
Sometimes the honest answer is rewrite, not cleanup. I will tell you that on the call, with the reasoning. Common signals: the data model is fundamentally wrong for the product, the auth model assumed single-tenant when the product is multi-tenant, the integrations were hard-coded in ways that block scaling. A rewrite estimate is part of the audit when the rescue is not the right answer.
Can you continue building features after the cleanup?
Yes. Most cleanup engagements continue as ongoing work for new features, maintenance, and on-call support. Same $60/hr rate, no minimum. The audit and harden phases are the front-loaded work; once the foundation is right, feature work runs at normal pace.