You built something real with Lovable, Cursor, Bolt or v0. Now it is breaking in ways you cannot prompt your way out of, and you are trying to figure out what it will cost to get someone in to fix it properly. Here are honest numbers, what drives them, and the questions to ask before you hire anyone.
There is no single price. A rescue could be $3,000 or $30,000 depending almost entirely on what the audit finds when someone competent actually reads your code. What I can give you is a clear map of the variables so you know what you are looking at.
What a rescue costs: the three tiers
These are AUD ranges based on senior Melbourne rates for this kind of work. The scope of each tier is described honestly below them.
These ranges are market observations, not quotes. Your app might land below the floor or above the ceiling. Anyone who quotes you a fixed price before reading your code is guessing.
What actually moves the price
Every item in this table is something a competent developer finds in the first hour of reading your codebase. The audit is not optional: it is the only honest basis for a scope.
| Factor | Why it costs more | Rough impact |
|---|---|---|
| Leaked secrets (service role key, API keys in client code) | Every exposed key has to be rotated across every service that uses it, and the blast radius has to be checked: what data could have been accessed, what was logged, what needs to be disclosed. | High. Adds days of work and urgency to the start of the project. |
| No version control | Without a Git history, there is no record of what changed or when. Every fix starts from archaeology. Rollback is impossible until a baseline is established from scratch. | High. Adds significant setup time before real work can start. |
| Row Level Security off | Writing correct RLS policies requires understanding your schema and your auth model. If the schema is also unclear, this is compounded. Policies have to be verified against every query path. | Medium to high, depending on schema complexity. |
| Client-only authentication | Authentication that lives entirely on the client has to be moved server-side. This touches every protected route and API endpoint. It cannot be done partially. | Medium. A week of careful work on a mid-sized app. |
| Schema chaos | Duplicate tables, missing foreign keys, data that exists in the wrong shape. Fixing the schema means migrating data without losing it, which is slow and careful work. | Medium. Adds days to the timeline. |
| Compliance requirements | Health data, payments, or children's data raise the bar on what "fixed" has to mean. Audit logging, stricter access controls, and documentation are not optional at this point. | High. Can double the scope of the security work. |
| Multiple integrations with broken auth | If your app talks to Stripe, Twilio, OpenAI and a CRM, and the credentials for all of them are in client code, every integration has to be moved and re-tested. | Medium. One to two days per major integration. |
What the audit phase costs
A proper rescue starts with a fixed-scope audit. A developer reads your entire codebase, maps every security gap, and delivers a written findings report: what is broken, what is serious, and what a full rescue would involve. You know exactly what you are committing to before you commit to anything.
The audit is not the fix. It is the basis for scoping the fix.
Any developer who skips the audit and quotes you a fixed price sight unseen is pricing from hope, not knowledge. That price will shift the moment they start reading your code. An audit-first process is not just ethical; it is the only way a fixed-price engagement can be honest.
Audit-only engagements typically cost $1,500 to $3,000 AUD depending on codebase size. If you hire the same team to do the full rescue, the audit cost is usually folded into the project.
Why the cheapest quote is sometimes the most expensive outcome
Vibe-coded apps break in security-sensitive ways. The most common failure pattern in a cheap rescue goes like this: a developer patches the bug you pointed at, declares the job done, and moves on. Two weeks later a different symptom appears, because the structural problems (leaked keys, client auth, no RLS) were never touched.
You pay for the first fix. Then you pay for the second fix. Then you discover that while both fixes were happening, your Row Level Security was off and your service role key was in the client bundle the whole time. The cheap quote was not cheap.
The questions that separate competent rescue work from symptom patching:
- Do you start with a security audit before touching any code?
- Can you show me what your RLS policy review process looks like?
- How do you handle a leaked key discovery mid-project?
- What does your CI setup look like after the rescue is done?
If the answer to the first question is no, keep looking.
Rescue vs rebuild: the honest comparison
A rebuild sounds appealing. Start clean, no legacy mess. The reality is that your vibe-coded app encodes months of product decisions, user research, and hard-won validation of what actually works. A rebuild throws that away and takes just as long as a rescue, often longer, because you are also rebuilding the product thinking, not just the code.
A rebuild is the right call when there is genuinely no version control to recover, the schema cannot be migrated without losing data, or the app is so small that a week of rebuilding is faster than a month of archaeology. In every other case, a rescue preserves what you validated and replaces what is broken underneath it.
Need to diagnose your specific situation before deciding? Start with the guide for whichever tool you built with: Lovable, Cursor, Bolt, v0, or Replit. Each one has a 20-minute triage checklist you can run yourself before spending anything.
What is included in a proper rescue
A rescue at this level is not "fix the bug." It runs in a specific order because fixing features on top of a broken foundation just breaks them again:
- Security audit. Read the entire codebase, map every exposed key, open endpoint, and unprotected table before touching anything. The findings report is a deliverable.
- Secrets rotation. Every leaked or suspect key replaced and moved server-side where it belongs.
- Row Level Security and server-side auth. RLS policies written for your actual schema, authentication enforced where it counts.
- Tests and CI. So the next change cannot silently break login the way the last twenty prompts did.
- Staged deploys. A preview environment actually configured like production.
- Your feature list. Deliberately last, on ground that can hold it.
For more on what the process looks like from our side, see how a rescue works.
Frequently asked questions
Is a fixed price or hourly rate better for a rescue?
Fixed scope for the audit phase, because you should know what you are committing to before anyone touches your code. The rescue work itself can go either way. Fixed price gives you certainty but only works when the scope is genuinely stable. Time and materials protects you when the scope is unclear, which it often is before the audit. Beware of anyone who skips the audit and quotes you a fixed price sight unseen: they are pricing from hope, not knowledge, and that price will shift.
How long does a rescue take?
For a typical vibe-coded app on a Supabase backend, one to four weeks. Security and auth work comes first and cannot be skipped. Tests, CI, and clean deployment follow. Feature work starts only once the foundation is solid. Messy schemas, leaked secrets that need rotating across multiple services, and compliance requirements all extend the timeline. The audit tells you where your project sits before any clock starts.
Should I rebuild instead of rescuing?
Fix what you have in most cases. Your app encodes months of product decisions, user research, and hard-won validation. A rebuild throws that away. The only cases where a rebuild clearly wins: no version control at all, schema so broken it cannot be migrated without losing data, or the app is small enough to rebuild in under a week. If the code runs and users are using it, a rescue is almost always faster and cheaper than a ground-up rebuild.
Why is the cheapest quote sometimes dangerous?
Because vibe-coded apps break in security-sensitive ways, and cheap rescues often skip the security layer. A developer who patches the bug you pointed at without checking Row Level Security, rotating leaked keys, or adding server-side auth has not rescued your app. They have changed the symptom while leaving the structural problems in place. The next bug appears in two weeks, and the data you collected while they were working may already have been exposed.
Do I need to take the app offline during a rescue?
Not in most cases. A good rescue works on a separate branch and environment, so your app stays live while the work happens. The security audit does not change any code at all. The one exception is a serious active leak: if your service role key is exposed in client code and real customer data is accessible to anyone who looks, taking the app offline temporarily is the safer move while the key is rotated and RLS is locked down. We flag these immediately when we find them.