How much does it cost to fix an app built with AI?

The cost to fix an app built with Lovable, Bolt, v0, Replit or Cursor depends far more on what is wrong than on which tool made it. A missing setting can take an hour to fix, while an app with no real permission model can take weeks. The only way to get an honest number is a short diagnosis first, and a fixed quote after it.

This guide explains what drives the price, the three sizes of fix we see most often, how the common pricing models compare, and what you can do before you ask anyone so you pay for less of their time.

What actually decides the price?

Five things move the number more than anything else.

1. What kind of problem it is. A wrong redirect URL and a missing database permission model are both "login is broken", but one is a setting and the other is a redesign.
2. How much of the app the problem touches. A bug in one screen is cheaper than a bug in the data model that every screen depends on.
3. Whether the developer can see everything. If the code is on GitHub and they can be invited to the backend, they start working right away. If the code lives only inside a builder they can't access, time goes into getting access first.
4. Whether real users or real money are involved. Fixes that touch payments, personal data or permissions need more testing, because a mistake there costs you customers.
5. How tangled the code has become. Long loops of "fix it" prompts tend to leave duplicate functions, dead code and half-finished features. Untangling that is part of the job.

Notice what is not on the list: the tool itself. Lovable, Bolt, v0, Replit and Cursor all produce ordinary code in the end (mostly React or Next.js on the front, often Supabase or a similar backend behind it). A developer who knows those stacks can work on any of them.

What are the three sizes of fix?

Most requests fall into one of three groups. These are the shapes of work, not price lists, because the same symptom can belong to different groups.

Small: a setting or a single missing piece

Typical examples:

• Login works in the preview but fails on your domain because the auth redirect URLs still point to the old address.
• A table returns an empty list because Row Level Security is on and no policy allows reading it.
• An environment variable was changed in the dashboard but the app was never redeployed.
• A webhook from Stripe fails because the signing secret belongs to test mode.

These are usually quick once someone finds them. Most of the time goes into the finding.

Medium: a feature that keeps breaking

Typical examples:

• Payments go through but customers don't get access, and nobody knows which step fails.
• Sign-up, password reset and email confirmation work for some users and not others.
• One part of the app breaks every time you ask the AI for a change in another part.
• The app got slow once you had real data.

These take longer because the fix has to hold up after the next prompt, which usually means cleaning up the code around the bug as well.

Large: the foundation needs work

Typical examples:

• Any signed-in user can read or edit other users' data, and the permissions have to be redesigned table by table.
• There is no separation between test and production, and real customer data lives in the same place as experiments.
• You want to move off a builder's hosting or database to your own accounts.
• The code is so tangled that adding anything breaks something else.

This is where people ask whether they should start over. Rebuilding from scratch is rarely the first answer. It throws away working parts along with broken ones, and a rebuilt app can end up with the same problems if the same process produced it. A good diagnosis tells you which parts are worth keeping.

How do pricing models compare?

You'll usually see one of four ways to pay for this work.

Hourly work without a cap is the riskiest option when the problem is unclear, because the investigation can run for a long time. If you go hourly, agree on a maximum before anyone starts and ask for a check-in when half of it is used.

Why do quotes for the same app vary so much?

Two people can look at the same app and give very different numbers, for a few common reasons:

• One of them looked at the code and the other only at the screenshots.
• One quoted a patch for the symptom and the other quoted a fix for the cause.
• One included testing, deployment and an explanation of what changed, and the other didn't.
• One plans to rewrite the app in a stack they prefer.

When you compare quotes, ask each person what exactly they will deliver, how they will test it, and whether you'll get a written summary of what changed. A lower number that leaves the cause in place usually costs more later.

How can you keep the cost down?

Most of the time a developer bills goes into understanding the problem. You can do a lot of that part yourself.

1. Write the problem down in four lines: what you do, what you expect, what happens instead, and where it happens (preview, live site, phone, desktop).
2. Collect the evidence: the first red error in the browser console, the status code in the Network tab, and the time it happened. Our guide on finding what broke in your Lovable or Bolt app walks through this step by step.
3. Connect the project to GitHub so the code can be reviewed without screen sharing.
4. Create a test account with fake data for the developer, so they never need your personal login.
5. Stop prompting during the repair. Two people (or a person and an AI) changing the same code at the same time creates conflicts that you end up paying to untangle.
6. Fix the order of priorities. Say what is urgent, what can wait and what must not change.

One more thing: never send passwords or secret keys to save time. Invite the person to GitHub, your backend and your hosting with their own account, and remove access when the work is done. Our post on how to hire a developer to fix your vibe-coded app covers this in detail.

What does Devonauts charge?

We publish our prices so you can compare them with anything else you're offered:

• Free App Health Check. Paste your app's URL and get an automatic report on the things that are visible from outside.
• App Rescue Audit, $299 one-off. A senior engineer reviews the code and you get a written report in 2 business days. If it finds no issue of medium or high severity, you get a full refund. If you start a plan within 30 days, the $299 is credited to your first month.
• Care, $249 a month, and Care Plus, $749 a month, for apps that need ongoing fixes and someone keeping an eye on them.
• Dev Subscription, $2,900 a month, when you need a developer building with you continuously.

Fixes found in the audit get a fixed price you approve before anything is touched. A person replies within one business day. The full details are on our pricing page.

Quick answers

Is it cheaper to rebuild from scratch? Usually not. Most AI-built apps have plenty of parts that work. Fixing the foundation and keeping the rest is normally faster and cheaper.

Can I keep using Lovable, Bolt or Cursor after the fix? Yes. The goal is that you keep building with your tool, on a base that doesn't fall over with the next prompt.

Does the tool I used change the price? Very little. What matters is the problem, the size of the app and how much access the developer gets.

What if the audit finds nothing serious? With our App Rescue Audit, if there is no medium or high severity issue, you get your $299 back.

Not sure what your app needs?

Start with the free health check to see what is visible from outside, then read about how our AI app rescue works. If you built with a specific tool, we have pages for Lovable, Bolt, Cursor, Replit and v0. Or tell us what's going wrong and we'll come back with a first read and a price before any work begins.