Rescue engineering

Fix your vibe-coded app before your users find the holes.

You prompted your way to a working product with Cursor, Lovable, Bolt, v0 or Replit. It got users. Now it falls over under load, a customer can see another customer's data, or every change breaks two other things. We take over AI-generated codebases, fix what matters in order of risk, and hand back a system that runs unattended.

Fixed-price audit first · No obligation to continue · Reply within one business day

Why vibe-coded apps break

The demo was never the hard part

AI coding tools are very good at producing something that works when one person clicks through it. They are consistently bad at the properties that only matter later: what happens with a thousand rows instead of ten, what happens when two users act at once, what happens when someone sends input the prompt never imagined, and what happens at three in the morning when nobody is watching.

None of that is a reason to regret the approach. You validated an idea for a fraction of what an agency would have charged. It just means the second half of the work still has to be done, and the tool that did the first half cannot do it.

The eight problems we find in almost every AI-generated codebase
01
Secrets in the client bundle. API keys, service-role tokens and admin endpoints shipped to the browser because that is where the prompt put them.
02
Authentication without authorisation. Users are logged in, but nothing checks that this user may see this row. Supabase apps with missing or permissive row-level security are the most common case.
03
No input validation at the boundary. Whatever the frontend sends is trusted, including prices, quantities, roles and IDs belonging to other tenants.
04
Database that works until it doesn't. No indexes, N+1 queries, no migrations, schema changed by hand in a dashboard. Fine at 100 rows, timeouts at 100,000.
05
Error handling that hides errors. Empty catch blocks, swallowed promise rejections, success toasts shown before the request returns. Failures happen silently and data drifts.
06
Tests that were generated and never run. Or no tests. Either way, every change is a gamble and the team stops making changes.
07
Deployment is a button in a dashboard. No pipeline, no staging, no rollback, no idea which version is running. The first bad deploy is an outage.
08
Nobody is watching. No monitoring, no alerts, no logs worth reading. You learn about downtime from a customer email.
By tool

Each tool has its own failure pattern

We have taken over enough of these to know where to look first.

Lovable, Bolt, v0

Next.js or React frontends wired straight to Supabase or Firebase. Typical findings: row-level security disabled or written as true, service-role key in the client, server actions without auth checks, storage buckets public by default, no rate limiting on auth endpoints.

Replit

Python or Node backends that grew inside one file. Typical findings: secrets in the repository history, SQLite in production, no process supervision, an admin panel reachable without login, and a deployment that stops when the tab closes.

Cursor, Claude Code, Copilot

Real backends in Go, Node, Python or Java, often architecturally reasonable. Typical findings: the same logic implemented three slightly different ways, authorisation checks present on some handlers and forgotten on others, shell commands built from user input, and 90% test coverage of things that don't matter.

How a rescue runs

Audit first, then fixes in order of risk

We never start by rewriting. We start by reading. The audit is fixed-price, takes days not weeks, and produces a document you can act on with or without us. Then we fix in the order that protects your users and your revenue, not the order that is most interesting to engineers.

What you get at handover
  • Secrets out of the code and rotated; authorisation enforced on every data path
  • Input validation, error handling and rate limiting at the API boundary
  • Database migrations, indexes for the real query patterns, backups that have been restored once
  • Tests around the money paths: signup, payment, permissions, the core workflow
  • A deployment pipeline with staging and rollback, and monitoring that pages someone
  • Architecture document, runbook, and a recorded walkthrough for the next engineer
01
Scoping call · 30 to 45 min, free
What the app does, who uses it, what is breaking, what tool built it. You get a fixed price for the audit the same day.
02
Audit · 3 to 7 days, fixed price
Read-only access to the repository and infrastructure. We read the code, not just run a scanner. Output: a written report with every finding ranked critical to low, file-level references, and an effort estimate per fix. Details of the audit format.
03
Stop the bleeding · usually week one
Exposed secrets rotated, authorisation holes closed, backups and basic monitoring in place, crash loops fixed. Anything a stranger could exploit today is closed first.
04
Stabilise and harden · 2 to 8 weeks
Working through the report in priority order. Weekly demo in your environment. We keep what works and replace only what has to go.
05
Hand back, or stay on
Docs, runbook, walkthrough. Optional monthly retainer if you want us to keep operating it or to build the next features properly.
We run the same audit process on our own product, WebGuardian, before every major release.
Straight talk

What a rescue is not

It is not a rewrite by default. Rewrites are how a two-month problem becomes a nine-month problem. We recommend one only when the foundation genuinely cannot carry the product, and we will show you why in the audit.

It is not a lecture about how you should have done it. You shipped something and found customers. That is more than most teams manage. Our job is the second half.

It is not a black box. Every finding has a file and line number. Every fix is a reviewed pull request in your repository. You can stop after the audit and take the report to anyone else.

It is not a scanner report. Automated tools find some things. Reading the code finds the authorisation bug that lets user A export user B's invoices. That one is never in the scanner output.

FAQ

Questions about fixing vibe-coded apps

What is a vibe-coded app?

A vibe-coded app is software produced mostly by prompting an AI coding tool such as Cursor, Claude Code, Lovable, Bolt, v0 or Replit, accepting what it generates, and iterating until the demo works. It is a fast way to get a working prototype. The problems appear when real users, real data and real attackers arrive, because the generated code was optimised for looking right in a demo, not for running unattended in production.

What is a rescue engineer?

A rescue engineer is a senior developer who takes over a codebase that is failing, unfinished or unmaintainable, usually after the original team or tool that produced it is gone, and brings it to a state where it runs reliably in production and can be maintained by a normal team. The work covers stabilisation, security fixes, architecture corrections, tests, deployment and documentation.

Can you fix my vibe-coded app without a rewrite?

In most cases, yes. A full rewrite is the most expensive and riskiest option. Most AI-generated apps have a workable core surrounded by security holes, missing error handling, no tests and fragile deployment. We fix those in place and replace only the parts that genuinely cannot be salvaged.

How much does it cost to fix an AI-generated app?

The audit is fixed-price and takes three to seven days depending on codebase size. It produces a ranked list of problems with an effort estimate for each, so you know the cost of the fix before committing. Most rescues then run from two weeks to two months on time and materials or a fixed scope.

Which AI tools and stacks do you take over?

Apps built with Cursor, Claude Code, GitHub Copilot, Lovable, Bolt, v0, Replit and similar. The stacks these produce are usually Next.js or React with Node, Python or Supabase backends, sometimes Go. We also work in Java, Spring Boot, Vue, PostgreSQL, MongoDB, Kafka, and Kubernetes on GCP, AWS or Azure.

Do I keep ownership of the code?

Yes. All work happens in your repositories and your cloud accounts. Everything we produce is yours. At handover you receive documentation, runbooks and a walkthrough so your next engineer, or we on a retainer, can operate it.

Contact

Tell us what's breaking

What the app does, which tool built it, what goes wrong and when you need it fixed. An engineer replies within one business day with next steps and a price for the audit.

NDA on request · Read-only access is enough for the audit

We use what you send only to reply to you. No newsletters, no sharing. See the privacy policy.