If you built your app with Cursor, Bolt, Lovable or Replit Agent and now need a human to sort out what the AI left behind, you probably want one thing: a number. Not a philosophy lecture about technical debt. A number.
We get it. So here is the honest version of how the cost to fix an AI-generated app actually gets calculated, why we can’t hand you a price on a five-minute call, and what separates a fair quote from one that’s padded.
What actually determines the price
Three things move the number more than anything else: scope, severity, and how tangled the code is. People usually only think about the first one.
Scope is the easy part. A contact form that silently fails is a small job. An entire authentication system that lets any logged-in user read any other user’s data is not. Most vibe-coded apps land somewhere in between, with a handful of features that need real attention and a lot of surface area that’s actually fine.
Severity matters just as much. A cosmetic bug costs nothing to fix. A bug that’s been leaking customer emails into your server logs for three months costs time to fix and time to figure out what needs disclosing. We wrote a longer piece on what makes a vibe-coded app insecure if you want the specifics, but the short version is that security issues are almost always more expensive than functional bugs because you can’t just patch the symptom. You have to work out what was exposed and for how long.
Then there’s tangle, which is the one non-technical founders underestimate the most. AI tools are extremely good at producing code that works in isolation and terrible at producing code that fits together as a system. We regularly see the same logic copy-pasted into six different files with six slightly different bugs, or a database query duplicated everywhere instead of living in one place. None of that shows up when you’re clicking through the app. It shows up the moment someone tries to change anything, because a fix in one spot doesn’t propagate to the other five. Untangling that costs more than fixing the bug itself.
Typical cost bands: review vs fix vs rebuild
We can give you ranges, not quotes, because every codebase is different. But ranges are more useful than nothing.
A code review, where we go through your app, flag what’s broken, what’s risky, and what’s fine, without changing anything, is the cheapest option and usually the right first step. It gives you a prioritised list and a real estimate for the next stage, instead of guessing.
A targeted fix, where we go in and repair specific known issues (a broken payment flow, a security hole, a feature that crashes on mobile) sits in the middle. Cost here scales almost linearly with how many separate problems you’re fixing and how deep each one goes.
A rebuild, where large chunks of the app get rewritten because patching them would take longer than starting over, is the most expensive path and, in our experience, the rarest genuine need. We’ve walked people back from “just rebuild it” more often than we’ve recommended it ourselves. If you want to understand when a rebuild is actually warranted versus when it’s overkill, our guide on taking vibe code to production covers that decision in detail.
The gap between these three is large on purpose. A review might take a couple of days. A full rebuild of a complex app can take weeks. That’s not us being cagey, it’s genuinely how different the work is.
Why “just quote me” is hard before a look
We understand the instinct. You want a fixed price so you can decide whether this is worth doing. But quoting AI-generated code sight unseen is a bit like a mechanic quoting your car repair over the phone based on “it’s making a noise.” Technically possible, reliably wrong.
Here’s the specific reason it’s harder with vibe-coded apps than with normal codebases: the code that looks fine and the code that’s quietly broken read almost identically. A human developer under pressure tends to leave obvious markers, a TODO comment, a shortcut with a note explaining why. AI-generated code doesn’t leave those markers. It writes broken logic with the same confident, tidy formatting as working logic. You genuinely cannot tell from skimming it, and neither can we, without actually running it and reading it properly.
That’s why every serious engagement starts with a look at the actual codebase before any number gets attached to it. Anyone willing to quote you a fixed price without opening your repository is either guessing or padding the number to cover their own risk. Neither is good for you.
Red flags that make a job expensive
A few patterns reliably push the cost up, and it’s worth knowing them so you’re not blindsided.
No version control history, or a single giant commit called “initial commit”, means we can’t see how the app evolved or what changed recently when something broke. We’re starting from zero instead of being able to trace a regression.
Environment variables and API keys hardcoded directly into the source, sometimes committed to a public repository, mean the security work isn’t optional anymore, it’s the first thing that has to happen, often before anything else is touched. We’ve covered exactly how often this shows up in the real cost of free AI-generated code, and it’s more common than founders expect.
A database with no defined schema, where the AI let the shape of the data drift depending on whichever feature was being built that week, is expensive because every fix has to account for records that don’t match each other. And an app that’s already live with real users and real data raises the stakes on every change, since now we’re fixing a moving target instead of a static one.
If any of that sounds like your app, take a look at our checklist on signs your vibe-coded app needs professional help. It won’t tell you the price, but it’ll tell you roughly what category you’re in before you talk to anyone.
What a fair engagement looks like
A fair engagement starts with a review, not a sales pitch. You get a written list of what’s actually wrong, ranked by how much it matters, before you commit to paying for fixes. You get a range, not a single magic number, because anyone with real experience knows that undiscovered issues are the norm in AI-generated code, not the exception. And you get to choose the scope. Not every bug needs fixing before launch. Some can wait.
What you shouldn’t accept is a quote with no inspection behind it, a rebuild recommendation with no explanation of why patching won’t work, or a contract that doesn’t distinguish between “we found this problem” and “we’re now fixing this problem” as separate, priced steps.
Want a real number for your app? Start with a free assessment and we’ll tell you what’s actually going on before you spend a penny fixing it.