/ Insights
By Daniel
12 May 2026
Vibe coding gets a product moving. You describe the app, push through blockers, generate screens, connect services, and have a working version before a traditional team would have finished planning. We build with the same tools, so none of this is a lecture against them.
The trap is that the prototype can feel complete while the structure underneath is still fragile. The app works for a demo, but each new change creates a regression. A user asks for something reasonable, and nobody knows which files to touch. A form saves data, but nobody can say who is allowed to read it. The launch date gets closer, and the team quietly realizes the codebase has no safe path to real users.
That is the moment cleaning up a vibe coded app stops being an engineering preference and becomes a business problem.
The first failures are boring, which is why they get missed.
Login exists, authorization does not. AI tools wire up sign-in early because every template has it. What they routinely skip is ownership checks. The classic version: an API route takes an id from the request and returns the row without asking whether this user should see it. Quick test: change the id in a URL or request and see if you get someone else's record. If you do, so will your users.
Data boundaries are implied, not enforced. Test records sit next to customer records, admin access hangs on a field the client can set, and integration state lives wherever the generator put it. Ask which rows in your database a new engineer could safely delete. If the answer is unclear, so are your boundaries.
The same business rule lives in four places. Pricing logic, plan limits, and permission checks get pasted into components, route handlers, and utility functions, because generation copies patterns instead of centralizing them. Small changes become risky because no single place owns the decision.
Errors are invisible. The only monitoring is a user emailing a screenshot. No logging, no alerting, no rollback path. You will not see the failure until a customer does, and by then you are debugging in production with an audience.
The AI features were never reviewed. Prompt injection, sensitive data flowing into prompts, tools the model can call with more access than any user has, and per-request model spend that nobody capped. The security half is what our AI app security review exists for. The cost half compounds quietly: we have watched frontier model bills pin gross margin near 50% until the pipeline was redesigned, and we published the numbers in cheap model finds, expensive model thinks.
Refactoring everything is not the goal. That burns weeks without moving the product closer to customers.
Good cleanup starts by asking which parts of the app create business risk:
That list is the difference between cleanup and polish. Cleanup protects your ability to keep shipping. Polish can wait until someone is paying you.
The most consequential decision is whether the app should be cleaned up or rebuilt, and it should come from evidence, not frustration.
Some vibe coded apps are good enough foundations. They need targeted hardening: real authorization, a cleaner data model, tests around the flows that touch money and data, deployment discipline, and a security pass.
Other apps are cheaper to rebuild, because the structure is too confused to harden. If the product direction is clearer now than it was during the prototype, rebuilding the right version can cost less than preserving the wrong foundation.
In practice the call is rarely all or nothing. The data model might be worth keeping while the API layer gets rebuilt, or the UI survives while everything behind it is replaced. Our AI-generated app cleanup work starts with exactly that call, made per part of the system: keep, refactor, replace, or rebuild.
A serious cleanup pass reviews the product and the code together, because a technically clean app that hardens the wrong flows is still a failed cleanup.
Start with the product:
Then review the system:
Done this way, cleanup produces a launch plan, not an abstract code-quality report.
The riskiest move is to keep adding features while the system is already hard to trust. Every feature built on a broken permission model inherits the broken permission model.
Before the next major feature, stabilize the parts every future feature depends on:
Once those hold, feature work gets fast again. The product still moves quickly, but it is no longer relying on luck.
We help founders and teams turn AI-built momentum into production reality. We build with the same AI tools you do. The difference is that senior product engineers know what production requires before the first prompt, so they converge in fewer rounds and do not generate the problems this post lists.
Where to start depends on where you are:
The first step: Book a readiness audit. Bring the repo, the app link, the known bugs, and the launch date. We will tell you what has to be fixed before users arrive, and what can safely wait.
Frontier LLMs are spectacular, and spectacularly expensive at scale. We cut per-session AI processing cost from $6.45 to $1.60 by training small task-specific models on our own data, and the deeper win was teaching cheap models to find exactly what the expensive models need.
Long context vs RAG is a false choice. Here's the three-tier memory architecture I expect to replace both within three years, and what to build (and skip) now.
A Lovable app can reach production, but clickable is not ready. What we check first: Supabase RLS policies, auth, secrets, the release path, and who owns the code.
