CodeKabir
On this page
You built an application with Lovable, Bolt, Replit, Cursor or Claude Code. It works, or mostly works, and now it needs a developer: something is broken, something was never finished, you are not sure who can see your data, or you need to get it off the platform that generated it. Search for help and you will find Fiverr gigs starting at the price of a lunch and agencies quoting the price of a car. Both can be right. This article explains what actually drives the cost of fixing a vibe-coded app, how to scope the work so the quote means something, what to send a developer, and how to tell a serious one from the rest. It contains no prices, because any number given before reading your code would be a guess.
Quick answer
Fixing a vibe-coded app is almost never one job. It is an audit, which has a knowable fixed cost, followed by one of four scopes: clear the blockers, stabilise, finish, or in rare cases rebuild. The audit tells you which. What makes two similar-looking apps cost ten times as much to fix is not the developer's rates; it is the size and state of the code, whether real users and data are already in it, how much security work the AI skipped, how many external systems are half-connected, and whether the code can even leave the platform it was built on.
Why the published prices disagree so much
Search results for this topic quote everything from a few dollars for a marketplace bug fix to six figures for an enterprise rebuild. Those figures come from the companies that sell the work and describe different things: a single bug, a stabilisation sprint, a security remediation, a complete rewrite. None of them is wrong; none of them is about your application. The useful way to think about cost is not a range but a set of drivers, and most of them you can assess yourself before contacting anyone.
The seven cost drivers
| Driver | Lower cost when | Higher cost when |
|---|---|---|
| Size and structure of the code | A few screens, reasonably organised | Dozens of pages, duplicated components, logic scattered across files |
| Live data and users | Not launched, or test data only | Real customers, orders or records that must survive the fix without downtime |
| Security debt | No payments, no personal data | Payments, personal data, authorisation that has to be designed from scratch |
| Integrations | None, or standard well-documented services | Several external APIs, some only mocked, some with keys exposed |
| Where the code lives | A Git repository with a standard database | Inside an app builder, with a managed database and storage that must be migrated out |
| Documentation and tests | A minimal readme and a few tests | Nothing: the developer has to infer intent from the code |
| What "done" means | Launch safely | Finish features that were never actually built |
The most underestimated driver is live data. Fixing a missing authorisation check on an empty application is an hour's work. Fixing it on an application where customers already have accounts, while keeping the service up and losing nothing, is a different discipline with a different price. If your app is live, say so in the first message: it is the single fact that changes a quote most.
What a developer actually checks
A serious review follows the same order every time, because the order protects your money: understand first, price second, change last.
Can the code leave the platform?
With a coding agent such as Cursor or Claude Code the code is already in an ordinary repository. With an app builder you have to check. Lovable keeps project code inside its platform but documents two-way sync with GitHub on all plans and a direct download of the code on paid plans. What does not leave with the code is the managed database, file storage and platform secrets, which have to be replaced with your own. That is ordinary migration work, but it belongs in the estimate.
Who can do what
Authentication is almost always present in AI-generated code. Authorisation almost never is, completely. Can a logged-in user read another user's records by changing a number in the URL? Can a customer account call the admin functions? This is the first security check, before any scanner runs, and it is the one most often failed.
Secrets
API keys and database credentials in front-end code, in the repository history or in logs. A leaked key is revoked in minutes; discovering it was used by someone else costs far more. Rotating exposed credentials is often the first thing a developer does, before any other fix.
What the server really validates
App builders generate excellent forms. Validation that exists only in the form does not exist: anyone who bypasses the interface sends whatever they like. Amounts, quantities, dates, file uploads and their sizes all have to be checked where the request arrives, not where it is typed.
The general state of the code
Duplicated components, dead code from abandoned prompts, outdated dependencies, no tests. None of these is an emergency. Together they decide whether every future change is an hour or a week, which is to say they decide the cost of everything that follows. A 2026 study of AI-authored commits, Debt Behind the AI Boom, found code smells to be by far the most common issue introduced (89.3% of all issues) and found that 22.7% of the tracked issues were still present in the latest version of the repository rather than fixed, which is exactly the pattern the checks above are designed to catch.
Audit, fix, stabilise or finish: the four scopes
- Audit only. The whole codebase read and a written report: findings by severity, the effort each would take, and what blocks launch. Worth having even if you then hire someone else, because it gives you a second opinion to compare quotes against.
- Clear the blockers. Fix what stops you launching or puts data at risk; document the rest for later. The shortest path to a defensible release.
- Stabilise. After the blockers, restructure the parts that make every change risky, add tests around the critical paths and set up repeatable deployment. For an application that will keep evolving.
- Finish. Build what was never built, from a written specification. This is a development project in its own right and should be priced as one, not as a "fix".
Marketplace, agency or independent developer
| Option | Good for | Watch out for |
|---|---|---|
| Marketplace gig (Fiverr, Upwork) | One reproducible bug with a clear definition of done | No methodology; nobody reads the whole codebase; little accountability after delivery |
| Agency | Large applications, teams, compliance requirements, a product manager on your side | Minimum engagement sizes; the person who sells is not the person who reads your code |
| Independent senior developer | Reading the whole codebase, honest scoping, a single accountable person from audit to hand-over | Limited capacity; check they actually work in your stack |
The pattern that works for most small and medium businesses is the audit-first approach with someone who will read everything, then a scoped engagement based on what was found. The pattern that fails is paying for fixes before anyone has read the code.
What to send
A developer who receives "my app is broken, how much to fix it?" cannot answer honestly. One who receives the following can usually quote the audit the same day.
- Which tool or platform built it, and whether the code is in a Git repository or still inside the builder
- What the app does, who uses it today, and whether it is live with real data
- One or two concrete, reproducible problems rather than a list of everything that worries you
- The stack if you know it: language, framework, database, hosting, third-party services
- Your deadline, and what you want at the end: a launch, a security sign-off, finished features, or just to know where you stand
Red flags, and what a good answer sounds like
- "It all needs rebuilding" before they have seen the repository. A rebuild is sometimes right, but it is a conclusion of an audit, not an opening line.
- "It will be fully secure." Nobody can promise that. A good answer lists what will be checked, what was found, what was fixed and what risk remains.
- Working directly on the live application. Changes belong on a branch, with tests, and are released at an agreed time with a way back.
- No written audit, no written scope. If the plan is in a chat window, so is your money.
- A stack mismatch. An excellent Python developer is not the right person for a Next.js and Supabase app, and vice versa. Ask what they actually work in.
- A refusal is not a red flag. A developer who says no to a native mobile app, a locked platform or an unfamiliar stack is saving you a wasted month.
How long it takes
Timelines follow the same drivers as cost. An audit of a modest codebase is measured in days. Clearing launch blockers on an application without live data is typically measured in days to a couple of weeks; the same work on a live application with real users, where every change has to be migrated and verified without downtime, takes longer and should. Finishing unbuilt features is a project with its own timeline. Anyone who gives you a date before the audit is guessing, and you will pay for the guess either in money or in the quality of the work.
If you are still choosing a tool
Much of what drives the cost above is decided before the first line of code: whether the output lands in a repository you control, and whether anyone reads it. If you are earlier in the process, the comparison of Claude Code, Cursor and Codex explains how the main tools are designed to be used and what none of them does for you. For a store rather than an application, the platform question comes first; see what an e-commerce website really costs.
Conclusion
A vibe-coded application with problems is not a failure. It is an application nobody has read yet. Fixing it properly means doing the work in the right order: understand, price, change, hand over. Insist on a written audit, distrust absolute promises in either direction, and give the developer the facts that let them answer you honestly. The cost will follow from your application, not from a price list.
Want the audit?
I read the whole codebase, send a report ranked by severity and quote the next step, which you are free to take elsewhere. The service is described at fixing and stabilising AI-generated applications.
Request a Quote
