Vibe coding cleanup for apps with real users
Vibe coding cleanup is for founders who built a working product with Lovable, Bolt, Cursor or Replit and now have paying users, a nagging security worry, or developers who say they can’t extend it. I audit the app, fix the security holes first, add tests and CI, and decide module by module what to keep and what to rewrite.
No lectures. Vibe coding got you to revenue faster than hiring would have. The job now is to make it safe to keep growing.
Signs it’s time
- You have real customers and personal or payment data in the database.
- Every new feature breaks an old one, and the AI tool now spends more time fixing its own regressions than building.
- A developer you hired looked at the code and quoted you a rewrite.
- You’re not sure who can read which rows in your database, or where your API keys are.
- An enterprise customer, investor or insurer has sent you a security questionnaire.
Security first: the usual problems
Vibe coding security issues are predictable, because the tools optimize for “it works when I click it”, not for an attacker poking at it. The most common ones:
- Missing or wrong row-level security. Many of these apps use Supabase, where the publishable key (the anon key on older projects) is meant to be public and RLS policies are what protect the data. Tables with RLS switched off, or with policies that are too permissive or check the wrong column, can let any logged-in (or anonymous) user read or change other users’ rows.
- Secrets in the client. A service-role key, a Stripe secret key or an OpenAI key bundled into frontend JavaScript is readable by anyone who opens dev tools. These must be rotated and moved server-side.
- Authorization checked only in the UI. Hiding the admin button is not access control. Every server endpoint and database function needs its own check.
- Trusting client input. Prices, user IDs and roles sent from the browser and used as-is. Server-side validation on every write.
- Webhooks without signature verification, so anyone can fake a “payment succeeded” event. See Stripe webhooks.
- No rate limiting on login, signup, password reset or AI endpoints that cost you money per call.
How a cleanup runs
- Audit (first week of the sprint). I read the code, the database schema and policies, the deployment setup and the third-party keys. You get a prioritized list: what’s exploitable now, what will hurt soon, what’s fine.
- Harden. Rotate exposed secrets, write and test RLS policies, move privileged logic server-side, add input validation, verify webhooks, add rate limits. These ship first, often within days.
- Safety net. Tests around the flows that make you money – signup, login, checkout, the core feature – and CI that runs them on every change, plus error monitoring and backups you’ve actually restored from.
- Keep or rewrite, per module. Not a big-bang rewrite. Modules that work and are readable stay. Tangled ones get refactored or replaced one at a time behind the tests. See rewrite vs refactor.
- Hand back a workflow. Conventions and rules files so you (and the AI tools) can keep building without reintroducing the same problems.
Taking a Lovable app to production
A Lovable or Bolt app to production usually means: exporting to your own GitHub repository, putting the backend (often Supabase) under migration files rather than dashboard edits, separating staging from production, setting up proper environment variables, and adding a deploy pipeline you control. You can keep using the AI builder for UI work afterwards – it just stops being the only source of truth.
If payments are involved, they deserve extra care: idempotency, webhook handling and reconciliation are where generated code is weakest. I’ve built payment platforms for products with millions of users and wrote Payments Playbook on exactly this. The payment integration page has more.
Should you keep vibe coding?
Probably, with guardrails. AI tools are excellent for UI iteration, prototypes and internal tools. They are weakest on auth, data integrity, multi-tenancy and payments – exactly the parts that hurt when they break. My longer take is in is vibe coding bad?.
If the app is beyond cleanup – no working core, or the business has changed shape – that’s a software project rescue or a rebuild, and I’ll say so after the audit rather than bill you for patching.
Why me
I’ve spent 20+ years taking software into production, across 200+ projects including platforms with millions of users. I use AI coding tools on my own products, so I know where they shine and where they cut corners. I work with founders directly, explain the trade-offs in plain language, and start with a two-week sprint: by the end the worst risks are closed and you have a written plan for the rest.
Questions
Can a vibe coded app be made production-ready?
Usually, yes. Most vibe-coded apps have a sound enough core with predictable gaps: database access rules, secrets, server-side validation, tests and deployment. Fixing those incrementally is far cheaper than a rewrite, and you keep shipping while it happens.
Is my Lovable or Supabase app secure?
Check that every table has row-level security enabled with policies tied to the authenticated user, that no service-role or secret keys are in frontend code, and that sensitive actions are enforced server-side. If you’re unsure on any of these, get it audited before your next customer signs up.
Do I need to rewrite my vibe coded app?
Rarely all of it. I assess each module on correctness, readability and risk. Most get hardened and kept; a few get replaced one at a time behind tests. A full rewrite only makes sense when the core data model is wrong.
How long does vibe coding cleanup take?
The audit and the most urgent security fixes fit in a two-week sprint. Tests, CI and module-by-module refactoring follow at a pace that lets you keep shipping features, typically a few days a week.
Built it fast, now worried about it?
Send me the repo. In a two-week sprint I audit it, close the urgent security gaps and give you a keep-or-rewrite plan for each part.
GMT+2 · Full EU overlap · US East mornings