Rescue Engineering: Fixing Vibe-Coded Apps Before the 90-Day Reckoning

Fixing a vibe-coded app comes down to one decision: refactor the code you have, or stage a rebuild behind it. I make that call with a one-day audit that measures test coverage, security exposure, and duplication, then traces the handful of flows that actually make the business money. If the data model and core paths are sound and only the code is messy, I refactor. If the architecture itself is the source of every bug, I stage a rebuild while the current app keeps running. In 2026, which Salesforce Ben fairly called the year of technical debt, most rescues I take are the second kind.

The pattern is consistent. A founder ships an MVP with an AI coding tool in a weekend, gets early traction, and then around the 90-day mark everything that was deferred arrives at once: real users, real data volume, and the first payments or security edge case. That is the reckoning. Here is how I work through it.

Why do AI-built apps break around the 90-day mark?

They break because the things a prompt-driven build skips are the same things that only matter once real usage shows up. AI-generated code is very good at producing something that runs on the happy path and demos well. It is much weaker at the boring scaffolding that keeps an app alive under load: tests, input validation, auth boundaries, and a coherent data model that does not need rework on every new feature.

For the first 60 to 90 days none of that is visible. There are five users, the data fits in memory, and nobody has tried the edge cases. Then the app gets a little traction. A user uploads a file ten times larger than anything tested. Two requests hit the same record at once. A payment webhook fires twice. The original build had no tests to catch the regression and no structure to localize the fix, so one bug fix breaks two other things, and the founder realizes they cannot safely change their own product.

The analyses from Beam and Pixelmojo on the 2026-27 wave describe the same arc: a flood of AI-built startups reaching the point where shipping fast turns into not being able to ship at all. That is the moment they call someone like me.

How do I audit AI-generated code in one day?

A rescue audit is a one-day, fixed-fee diagnostic that answers a single question: is this debt cosmetic or structural? I do not read every file. I measure a few things that reliably predict how hard the codebase will be to change.

Here is the shape of what I typically find in a vibe-coded app versus what a healthy codebase looks like.

## Coverage and a quick map of what's tested vs shipped
npx vitest run --coverage

## Dependency and known-vuln scan
npm audit --production
npx depcheck            # unused / phantom deps

## Duplication
npx jscpd ./src --min-lines 5 --threshold 1

## Secrets that should never be in the repo
npx secretlint "**/*"

If most rows point left, I refactor: add a test harness around the money flows first so I have a safety net, then collapse the duplication, then patch the security holes. If most rows point right, I do a staged rebuild. What I almost never do is a big-bang rewrite, where you freeze the product for three months and pray the replacement reaches parity. That is how rescues turn into second failures.

A staged rebuild keeps the existing app running and live in production while I build the new core behind it, then move traffic one slice at a time. Concretely, that often means standing up a clean service and routing a single flow to it first, with the old path as a fallback:

// Route one flow to the rebuilt service, keep the old one as fallback.
// Expand the percentage as confidence (and test coverage) grows.
app.post("/checkout", async (req, res) => {
  if (rolloutBucket(req.user.id) < REBUILD_ROLLOUT_PCT) {
    try {
      return await newCheckoutService.handle(req, res);
    } catch (err) {
      logger.warn("rebuild path failed, falling back", { err });
    }
  }
  return legacyCheckout(req, res); // still earning revenue
});

The business never goes dark. Revenue keeps flowing through the old code while the new code earns trust on a small slice of traffic. By the time the percentage hits 100, the old path has already been validated against real usage rather than against my hopes.

How do I price a vibe-coded app rescue?

I split it: a fixed fee for the audit, then milestone-based pricing for the rescue itself. I do not bill an unknown codebase hourly, because hourly billing on a rescue punishes everyone for the wrong things.

The audit is fixed because the founder is buying a decision, not my time. They get a written verdict (refactor or rebuild), the evidence behind it, and a scoped plan with milestones. If they take the plan elsewhere, that is fine. The diagnostic stands on its own.

The rescue is milestone-based for a reason I have written about before. On an unfamiliar codebase, hourly billing means the client pays for my discovery time and I get penalized for being efficient. The faster I find the real problem, the less I earn, which is exactly backwards. I went deep on this in why hourly pricing now charges you less for being better ↗, and rescue work is the clearest case for it. A rescue priced by outcome (the money flows work, coverage crosses a threshold, the security holes are closed) aligns my incentives with the founder's.

Typical milestone shape for a staged rebuild:

• Milestone 0: audit and decision, fixed fee, delivered in days.


• Milestone 1: test harness and monitoring around the revenue flows, so nothing else can silently break.


• Milestone 2: security remediation. Secrets out of the repo, auth moved server-side, vulnerable dependencies patched.


• Milestone 3: rebuild the first core flow behind the running app and roll it out by percentage.


• Milestone 4: migrate remaining flows, retire the legacy path.

Can the AI tools that built the app just fix it?

Sometimes, for an isolated bug. Not for the structural ones, because an AI tool cannot reason about an architecture it never designed. Ask it to fix a failing flow and it will patch the symptom in the file you showed it, while three duplicated copies of the same logic keep failing elsewhere. That is the four-times duplication problem feeding on itself.

I use AI heavily inside a rescue, but on my terms. It is excellent at writing the missing tests once I have decided what the contract of a flow should be, at translating a tangled function into a clear one when I give it the surrounding structure, and at drafting the migration scripts. The judgment about what the architecture should be, which flow to rebuild first, and where the real risk sits stays with me. The tool accelerates a plan. It does not make the plan. A vibe-coded app is precisely what you get when the tool is asked to do both.

What does a founder actually get out of a rescue?

A product they can change again without fear. That is the real deliverable, more than any single bug fix. Before the rescue, the founder is frozen: every feature request is terrifying because nobody knows what it will break. After it, there are tests around the money flows, the security holes are closed, and there is a clear path to retire whatever is left of the old code.

The honest version of this work is that I am not promising perfection. I am moving the app from "unchangeable and quietly bleeding" to "changeable and safe," in a sequence that keeps it earning the whole way through. For most of the 2026 cohort of AI-built startups, that is the difference between surviving the year of technical debt and becoming a cautionary line in someone else's analysis.

Rescuing a codebase before it collapses under its own debt is exactly what my app rescue and optimization ↗ work is for.

If you are staring at an app you no longer trust to touch, that is the normal 90-day reckoning, not a personal failure. Send me what you are dealing with through my contact page ↗ and I will tell you honestly whether it is a refactor or a rebuild before you spend another dollar on it.