Your vibe-coded app is broken. Here is how to hire someone to fix it.

You described an app to Lovable, Bolt, Replit, Cursor, or v0, and something real came out. Screens. A login. A database, maybe a Stripe button. Then it stalled, and now you are searching for someone to finish it. This article is the honest version of what you will find.

I run a web and app studio in Edina, and since early 2025 a growing share of the apps that come through the door were started by an AI tool rather than a person. The pattern is consistent enough that I can tell you what is probably wrong with yours before I have seen it.

What is a vibe-coded app?

It is an app built mostly by describing what you want and accepting what the AI generates, rather than writing the code yourself. The term came out of 2025 and stuck. Vercel reported that 63 percent of the people using its v0 builder were not developers; Lovable has said about 60 percent of its users are not either. These are self-reported platform figures, but they match what we see: the person who built the app usually cannot read it.

That is not a criticism. The tools are genuinely remarkable at the first 80 percent of an app. The problem is that the last 20 percent is where the risk lives, and the AI does not know what it does not know.

Why does my vibe-coded app break in production?

Almost every rescue we see has the same handful of problems, and they are worth knowing by name so you can ask about them.

Open databases. Most of these apps run on Supabase or Firebase. Supabase relies on row-level security — rules that decide which rows each user may read or write. The AI tools frequently leave those rules off or wrong, and the public key that lets the browser talk to the database is visible in the page’s JavaScript. The result is a database any visitor can read. A scan of 30,998 AI-built apps published in August 2026 found that 57 percent of the reachable Supabase-backed apps allowed unauthenticated table reads. An earlier scan of 1,072 apps found some kind of security flaw in 98 percent of them. A Lovable-specific version of the missing-rules bug was serious enough to get its own CVE in 2025.

Secrets in the browser. There are two kinds of keys. The anonymous key is designed to be public. The service-role key bypasses every database rule and must never leave the server. AI tools regularly put the second one where the first one belongs.

Auth that is theater. A login screen exists, and the routes behind it never check who is asking.

Works in preview, breaks in production. The preview environment runs same-origin and forgiving. Deployment surfaces CORS errors, missing environment variables, payment keys that only ever existed in test mode, and — on some platforms — the discovery that development and production data were never the same database.

No tests, no error handling. Every new prompt risks quietly breaking something that used to work. One practitioner guide puts the warning sign at more than half your hours going to regressions and re-prompting the AI to fix its own mistakes. If that is you, you are already past the point of solo development.

Database performance. Queries that were fine with ten rows of seed data create N+1 patterns and full table scans with a thousand real users.

None of this means the app is worthless. It means it was built by something very fast that has no judgment, and it needs a person with judgment to finish it.

Should I fix it or rebuild it?

Fix, usually. If the AI picked a reasonable stack — and React with Supabase or Next.js with a managed backend is a reasonable stack — a developer can repair the implementation and keep what is structurally sound. A rewrite is warranted only when the architecture genuinely cannot carry real users: no separation between tenants, a data model that will not survive the next feature, that sort of thing.

Here is the rule that protects you: a quote to rewrite everything from someone who has not read your code is a warning sign. The right first purchase is an audit, not a rebuild.

What does an audit look like?

A short, paid review — typically a few hours — of the code, the database rules, the authentication, and the deployed app rather than the preview. You should get a written list of findings ranked by risk: what is a security hole, what is broken, what is unfinished, and what is fine. You keep that document whether or not you hire the person who wrote it, which means it is also the best tool you have for comparing quotes.

Three questions to ask before paying for the audit:

1. Will you look at the code before you quote the fix? (If no, walk away.)
2. Do you work in the stack the AI chose, or will you move me to yours?
3. What will I own at the end, and will you put that in writing?

What does it cost to fix a vibe-coded app?

The market is wide, and the spread tells you something.

At the bottom, Fiverr now has a vibe-coding category and Upwork has profiles that advertise “shipping the last 20 percent” of Lovable, Bolt, Replit, and Base44 apps. Listings start around $15 and run to a few hundred dollars. Some of these people are good. The listing cannot tell you which, and the failure mode is not a bad button — it is a database full of your users’ data that anyone can read.

At the top, a category of specialist “vibe coding cleanup” and “rescue” firms has appeared, most of them describing the same process: audit, fix, harden, hand off. One publishes tiers from about $5,000 to $28,000; most quote only after an audit.

Where your app sits in that spread depends on three things: whether the security problems are configuration (cheap to fix) or architecture (not), how much of the app works versus merely looks like it works, and how much is still unbuilt. The audit is what tells you. For broader context on what software costs, our breakdown of what it costs to build an app covers the market ranges for building from scratch, and the pricing page collects the published benchmarks with sources.

How do I find someone to finish my AI-built app?

Search for the phrases the market actually uses — “vibe coding cleanup,” “vibe coding rescue,” “fix my Lovable app,” “take over AI-generated codebase” — and you will find three kinds of providers: marketplace freelancers, offshore agencies with a new landing page, and local studios that have always built production apps and now take rescue work too.

Whichever you choose, vet them on the audit, not the pitch. Ask to see a sample audit report. Ask how they handle Supabase rules and secret keys specifically; if the answer is vague, so is their security review. Ask to be invited into your hosting, database, and payment accounts as a collaborator rather than handing over passwords — a good developer asks for that themselves. And get code ownership in writing: the repository, the database, and every account in your name.

Will I still own my app?

You should, and you should be able to keep building on it. A developer who does this well leaves you with a normal Git repository you own, the AI tool’s export connected to it, a real deployment with monitoring, and a short guide to what is safe to change with prompts and what to send to a person. The goal is to make you more independent, not to make you a client forever.

When to stop vibe coding and hire someone

If you recognize more than two of these, you are there:

• More than half your time goes to fixing regressions or re-prompting the AI to repair its own work.
• You have real users, real payments, or anyone’s personal data in the app.
• The deployed version behaves differently from the preview and you do not know why.
• You cannot confidently answer “can a stranger read my database?”
• You have a feature that the AI has “finished” three times.

That last 20 percent is finishable. It just needs a person who has done it before. We do this work from Edina and remotely — here is how our rescue process works, or tell us about your app and we will start with the audit.