This guide explains the work that affects a rescue quote and the questions to ask before hiring. It does not provide a verified market-price dataset or a promised delivery time.
A reliable quote depends on inspecting the project, identifying the failure and agreeing acceptance checks. Separate urgent exposure work, repairs, testing, deployment and ongoing support.
Three situations that change a rescue scope
These categories describe scope differences, not market-price or turnaround bands. Get a quote for the actual project.
Request a written scope with assumptions, exclusions and release checks. Further findings can change the work; agree changes before proceeding.
What actually moves the price
These are scope inputs to investigate, not a ranked dataset or a promise that every issue can be found in an hour.
| 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. | Confirm the work from the exposure and recovery requirements. |
| No version control | Without useful Git history, tracing changes can take more work. Provider history, snapshots or backups may still support recovery. Check what can actually be restored and protect current data before attempting it. | 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 | Protected operations need trusted access checks at the relevant API or data boundary. A client login flow can be appropriate with a supported provider, but UI route guards alone do not authorise access to protected records. | Impact depends on the access paths, provider and affected integrations. |
| 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. | Confirm the work from the exposure and recovery requirements. |
| 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. | Additional review and documentation depend on the data and applicable requirements. |
| 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. | Quote each integration after reviewing its access and behaviour. |
What the audit phase costs
An agreed investigation examines the code, permissions, deployment and reported failure. A written findings report records what was reviewed, what was found and what remains uncertain. It supports the repair quote; it does not certify the absence of every vulnerability.
The audit is not the fix. It is the basis for scoping the fix.
An estimate made before inspection should state its assumptions. Agree an investigation scope and change process so findings can be priced clearly.
Quote the audit scope separately and confirm whether its fee is credited toward further work. This guide has no verified dataset for a typical audit price.
Why the cheapest quote is sometimes the most expensive outcome
A repair that only addresses the visible symptom can leave an underlying issue unresolved. Compare proposals for access checks, exposed secrets, recovery, regression testing and handover rather than assuming price predicts quality.
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 may reuse product requirements and visual work, while a rescue may preserve functioning code. Compare both scopes, data migration, testing and operating costs rather than assuming one is always faster or cheaper.
Compare rescue and rebuild after inspecting the code, data and requirements. Existing product decisions may be reusable, but missing Git history alone does not require a rebuild. Compare migration risk, retained functionality, testing and ongoing costs before choosing.
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. Check critical paths on proposed changes so covered regressions can be caught before release. Tests reduce risk within their coverage; they do not guarantee that every bug or production issue will be detected.
- 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?
A reliable timeline needs an agreed scope after inspection. Access, the failure to reproduce, affected data, integrations, security issues and required release checks all influence it. Ask for an investigation milestone, a repair estimate and a staged release plan; these are not guaranteed turnaround times.
Should I rebuild instead of rescuing?
Compare rescue and rebuild after inspecting the code, data and requirements. Existing product decisions may be reusable, but missing Git history alone does not require a rebuild. Compare migration risk, retained functionality, testing and ongoing costs before choosing.
Why is the cheapest quote sometimes dangerous?
A symptom-only fix may leave access-control or credential problems unresolved. Ask what was tested and what was excluded; this is a scope question rather than a measured failure forecast for cheap suppliers.
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.