- Published on
How Much Does It Cost to Fix a Vibe-Coded App?
- Beka Makharoblishvili
- Founder and Product Engineer
The honest answer is that it depends on three things, and you can work out roughly where you sit in about ten minutes. This post is that estimate, plus what moves the number.
Nobody enjoys a pricing page that says "it depends," so the ranges here are real ones. They are what this work costs in 2026 for a single-purpose application built with Lovable, v0, Bolt, or Replit.
The three things that set the price
How much data isolation work there is. This is the biggest single driver. An app where users only ever see their own records, with five or six tables, is a contained job. An app with teams, shared workspaces, roles, and permissions that vary by resource is a different exercise, because every table needs policies that express a relationship rather than a simple ownership check.
Whether money moves through it. Payments add a fixed amount of work that does not scale down. Webhook verification, server-side pricing, and idempotent fulfilment have to be right regardless of how small the app is.
How much of it survives. Sometimes the generated code is a reasonable foundation that needs securing. Sometimes the data model is wrong in a way that makes everything built on it wrong, and the honest recommendation is to keep the interface and rebuild what sits underneath. The second case costs more, and you want to find out which one you are in before you commit to a budget rather than after.
The ranges
Small: roughly 6,000. One user type, no teams, under about eight tables, no payments or a simple one-off checkout. Work is mostly writing and testing row level security policies, moving keys off the client, adding real authorization checks on server routes, indexing the queries that need it, and getting deployment and error tracking in place. Typically one to two weeks.
Medium: roughly 15,000. Multiple user types or teams, subscription billing, an AI feature or two that needs rate limiting and failure handling, more surface area to review. The permissions work grows faster than the table count suggests, because shared resources multiply the cases. Typically two to four weeks.
Large: $15,000 and up. Something structural is wrong. The data model does not support what the product needs, or there is enough of it that the review alone is a project. At this point you are not fixing an app, you are rebuilding parts of it with the prototype as the specification, which is a legitimate and often sensible thing to do, but it should be named honestly rather than sold as a cleanup.
Most apps we see are small or medium. Large is usually a symptom of the prototype having been pushed much further than it was meant to go.
Why an audit before a quote
You will notice everyone in this space wants to look at the app before quoting, and it is worth explaining why rather than treating it as a sales step.
The difference between the small and large case is not visible from the outside. Two apps can look identical in the browser and be a week apart in work, because the difference is in the data model and the permissions, neither of which you can see by clicking around. Anyone who quotes a fixed price without looking is either padding heavily to cover the risk, or is going to come back with a change order.
Our version is a $750 Production-Readiness Audit that returns a written verdict in 48 hours: what is fatal, what can wait, a fixed quote to fix it, and a 90 day plan. It is credited in full against the sprint if you book within a week, which means if you go ahead it costs nothing, and if you do not, you keep a document you can hand to any developer.
Before that, there is a free teardown. Send the app, get back what is genuinely wrong with it. That one costs nothing in either direction.
Doing it yourself
For a technical founder this is a real option and worth costing properly.
The work is two to four weeks for a small to medium app if you know what you are doing. The catch is not the fixing, it is the knowing. Finding that row level security is off takes an hour. Knowing to look, knowing that a using (true) policy is not protection, knowing that your service role key in the client bundle is a rotate-immediately problem rather than a tidy-up-later one: that is the part that is hard to acquire while you are also running a company.
So the calculation is not "my time versus their fee." It is your time, times the risk that you do not know what you missed, against the fee. If you are technical and not in a hurry, doing it yourself is genuinely reasonable, and the guide and the security checklist are written so you can.
If you have a launch date, a demo, or a customer waiting, the arithmetic changes, because the expensive outcome is not the fee. It is missing the date.
What comes after
The part people forget to budget for is what happens on day 31.
An app in production is not a finished object. Dependencies get security patches, the AI provider changes a model, something breaks at 2am, and features still need shipping. If your plan ends at launch, you have bought a launch rather than a product.
Our answer is a [150 an hour with a four hour minimum, or Standby at $400 a month if you want the phone answered without ongoing feature work.
You do not have to buy that from us. But you should decide what your version of it is before you launch, because the alternative is discovering the answer during an incident.
The short version
Small app, no payments, one user type: 6,000, one to two weeks. Teams, billing, AI features: 15,000, two to four weeks. Something structural is wrong: $15,000 and up, and you want that diagnosed before you budget.
Doing it yourself: two to four weeks of your time, plus the risk of not knowing what you missed.
The one thing worth doing today, whichever way you go, is finding out which bracket you are in. That is what the free teardown is for, and it takes you one message.