What it actually costs to fix a vibe-coded app

“How much to fix my app” is really three different questions wearing one sentence, and the answer depends entirely on which one you’re asking.

The three tiers

Tier 1: it’s broken. The app worked in preview and something specific stopped working: a blank page after deploy, a login loop, a payment that doesn’t confirm. This is diagnosis and a targeted fix. Usually the smallest tier, because the app’s shape is right and one thing is wrong.

Tier 2: it’s not safe. The app runs fine and would fail an audit: no row level security, a secret key in the browser, access checked only in the frontend. Nothing looks broken to a user. It’s broken to anyone who opens developer tools. This tier is priced by how many of these exist, not by how visible the symptoms are, which is why it often costs more than tier 1 despite looking fine.

Tier 3: it can’t hold real usage. The architecture itself doesn’t support what you’re asking of it now: no real multi-tenant boundaries, a database designed for one user’s data doing double duty for thousands, business logic that only exists as prompts. This is the expensive tier, and it’s the one people are least prepared to hear about, because the app “works” right up until it’s asked to do the thing it was never built for.

What actually drives the price

Not the number of screens. These, roughly in order of cost impact:

• How much is tier 2 versus tier 3. A dozen missing security policies is a week. A data model that can’t separate one customer’s data from another’s is a rebuild of the backend.
• Whether the fix touches the data model. Changing a column is cheap. Changing what a row means is not, because every query and every screen that reads it has to be checked.
• How much of the app exists only in the deployed environment. We’ve hit projects where server functions were live on the platform and absent from the exported code entirely. Every diagnosis has to test the deployed thing, not just read the code, and that takes real time.
• Whether you need it live continuously during the fix, or can accept a maintenance window. Zero-downtime work costs more because every step needs a rollback plan.

Why “how much per hour” is the wrong question

Because it invites you to buy less diagnosis, and diagnosis is the part that determines everything else. An hourly quote with no diagnosis is a guess wearing a number. Two apps that look identical in a demo can be a two-day fix and a two-week fix, and the only way to tell them apart is to actually look.

The honest answer is: fixed price, but only after a free diagnosis. The diagnosis costs nothing because it’s also how we protect you from an inflated quote based on guesswork, ours or anyone else’s.

What actually gets asked for

The pattern we see most: tier 1 symptoms that turn out to be tier 2 problems. Someone thinks they need a small bug fixed, and the bug is actually the second row level security policy they’ve hit, which means the same gap exists in six other tables nobody’s noticed yet. The quote changes because the diagnosis found the real shape of the work, not because the work grew.

What to do before asking anyone for a number

Run the five-minute check for whether your data is public, and check your app against the ten production-readiness checks. Both are free, take minutes, and turn “how much to fix it” into a much more answerable question, because you’ll already know which tier you’re in.