How much does it cost to fix a vibe-coded app?

Cost to fix a vibe-coded app, by size of the job

My fixed prices in US dollars. Every job past a single bug starts with the review, because the review is what turns "it depends" into a price. The review fee comes off the next step if you continue.

The second row is for the common case: the screens and flows a builder like Lovable produces are often fine, and what's missing is the layer underneath: who can read which rows in the database, where the secret keys live, and what happens when a payment fails. Fixing that layer is a sprint, not a rebuild. The takeover rows are for apps that already have users or revenue and break in ways a sprint can't contain.

Where the review lands inside $900–1,500 depends on the size of the app: how many database tables, user roles, and connected services it has. A single-role app with five tables and Stripe Checkout sits at the bottom. A multi-tenant app, where each customer company must only see its own data, with several roles and subscriptions, sits at the top.

What other developers charge to fix AI-built apps

Published prices, as each seller lists them in 2026. All of these are sellers describing their own services, so read them as price lists, not market research.

The spread is mostly about what each price buys. Aibrify's $100 fix is one bug, fixed. Fora Soft's $15,000–45,000 is an agency team hardening a whole app over three to six weeks. Neither is wrong. They're answers to different questions, which is why comparing quotes only works once you know which unit each one is in.

How to tell which kind of quote you have

• Per fix. A price for one named problem. Cheap and fast, and right when the problem really is one bug.
• Package or sprint. A fixed price for a list of fixes. Only fair if the list is written down and someone has read the code to make it.
• Hourly or monthly team. Open-ended. Fine for ongoing work, risky as a rescue unless it has a cap and a written goal.

What a fix list for a Lovable app contains

A typical Lovable app is a React front end on Supabase, with Stripe for payments. These are the items a review of that kind of app checks, and which step each one usually falls into. The review puts a fixed price on each item it actually finds.

The first two rows are the most common and the most serious. How to check them yourself is in this Supabase RLS checklist for Lovable apps, and the most common payment failures are in Stripe webhook not working in a Lovable app. The last row is the one that moves a job from a sprint to a takeover: when the problem is the structure rather than a missing rule, fixing it means rewriting parts of the app.

What makes fixing an AI-built app cost more

Live users and real data

An app nobody uses yet can be changed freely. An app with paying users needs every change tested and released without breaking what they rely on, and database changes written as migrations that keep existing rows intact. That care takes time.

User roles and customer separation

One kind of user is simple. Admins, members, and customers who each see different things multiply the rules that have to be written and tested. Separating customer companies from each other is the biggest single step up.

Payments and subscriptions

A one-off Stripe Checkout is quick to make safe. Subscriptions with trials, upgrades, failed renewals, and refunds have many more paths, and each one decides whether someone keeps access they haven't paid for.

Lovable Cloud or your own Supabase

If the app runs on Lovable Cloud, the built-in backend, and you want the backend in your own Supabase account, Lovable's docs say there is no one-click migration in either direction. The schema has to be recreated and the data moved by hand, which adds days to the job. If you already connected your own Supabase project, that cost doesn't exist.

AI edits made during the fix

Lovable syncs two ways with GitHub, on one branch. If you keep prompting while a developer pushes fixes and the two histories diverge, Lovable's docs say the next sync from GitHub replaces Lovable's version of the branch. Agree a simple rule before the work starts: either you pause prompting during the sprint, or the developer works on a separate branch and merges at agreed times.

Pay per bug, or pay for a review?

Pay per bug when the problem is one thing you can name: the deploy fails, the password reset link points at localhost, one page throws an error. A per-fix service or an hourly freelancer will sort it out for a few hundred dollars, and a review would be overkill.

Pay for a review when any of these is true:

• The same area has broken again after two or three fixes
• You're about to take payments, or already do
• The app holds personal data you'd have to report if leaked
• A launch date, an investor, or a customer's security questions are coming
• You don't know what you don't know

The review isn't the expensive part. Fixing the wrong things is. A $100 fix to a symptom, repeated ten times, costs more than a review that finds the cause. If you're still deciding whether the app needs a developer at all, read when an AI-built app needs a developer first.

Costs after the fix: care, credits, and keys

The fix is a one-off price. These costs come after it, and a good quote names them:

• Looking after the app. Supabase, Stripe, your hosting, and dozens of code packages change under you. My care plan covers updates, security checks, monitoring, and small fixes for $400, $900, or $1,800 a month. Or you take the app back with written notes on what changed.
• Running bills in your name. Supabase, hosting, email, and AI providers bill you directly, and usage-based bills grow with users. A review should list them and set spending limits where the provider allows.
• Builder credits.If you keep making changes in Lovable or Bolt, you keep paying for credits. That's fine for copy and layout. Changes to payments or data rules should go through someone who reads the code.
• Rotating keys.Any key that was ever in the browser, or shared with a developer, should be replaced when the work ends. It costs nothing but an hour, and it's often skipped.

Is rebuilding cheaper than fixing?

Rarely, if the app works for its users. A rebuild means paying again for every screen that already works, and moving users and data across. It's cheaper only when the review shows the structure itself is the problem: the same logic copied everywhere, a database shaped wrong for what the product does, and every fix breaking something nearby.

Even then, a rebuild is usually partial. On The Chat Company, an AI-generated demo, I kept about 20% and rewrote the rest, and the founder didn't start from a blank page because the demo had already worked out what the product should do. The full decision, for any codebase, is in take it over or rewrite it.

Red flags in a quote to fix your app

A quote that passes these tests names each problem, says what could happen if it's left, and prices the fix. If a seller can't tell you what they'd check first, they haven't done this before.

Two real rescues and what they cost

An AI-generated chatbot demo: $20,000, nine weeks

The Chat Company lets a business add an AI chatbot that answers from its own website. When I took it over it was a demo the founder and another developer had generated with AI tools: good enough to pitch, too buggy to serve real businesses. I read all of it, kept about 20%, rewrote the rest, and built the product on that base, including search filtered by business so one customer's content never appears in another's chatbot. It took nine weeks and cost $20,000. It now serves 30+ businesses and handles 100K+ messages a day.

An agency-built app handling real money: $16,000, eight weeks

This one wasn't AI-built, but the job was the same kind: code someone else left half-finished, with real money moving through it. An agency left the social challenge app half-built. I kept what worked, rewrote the rest, and launched it in eight weeks for $16,000. It now has 10,000 users.

Both are takeover prices, the upper rows of the table. Most apps built with Lovable or Bolt that haven't launched yet need far less than this.

What to send to get an accurate quote

The more of this a developer gets up front, the narrower the price range they can give you. If you're not sure what state the app is in, run the free AI-built app launch checklist first; your score and its list of gaps are worth sending too.

Don't send passwords or keys in that first message. Access comes later, through invites. When you're ready, send me the link and what's at stake, and I'll tell you which row your app is in.