A Framework by Justin McKelvey

The Crash Cart

Triage a broken codebase the way an ER triages a trauma patient — bleeding first, scars later.

Quick Answer

The Crash Cart is a 5-step triage framework for rescuing broken, inherited, or AI-generated codebases. The steps run in order: Stop the Bleed (hours), Stabilize (days), Survey (days), Strip (week), Ship (week and beyond). Each step assumes the previous one is done. As of mid-2026, most Vibe Code Rescue engagements I run follow this exact sequence — total time from "everything is on fire" to "shipping new features cleanly" is typically 2–3 weeks.

Coined by Justin McKelvey, fractional CTO · Vibe Code Rescue offer · Updated June 2026

What is the Crash Cart framework?

The Crash Cart borrows from emergency medicine. When a trauma patient comes in, an ER team doesn't start by discussing long-term recovery — they stop the bleeding. Same logic applies to broken codebases. Most engineering teams try to refactor while the patient is still hemorrhaging.

Use this framework when you inherit a codebase you didn't write, when an AI-built app starts failing in production, when a developer leaves and nobody understands their code, or when the next feature has felt impossible for more than two weeks.

Skipping steps is the most common failure mode. You can't Survey a codebase that's still on fire. You can't Strip what you haven't Surveyed. You can't Ship cleanly on an unstable foundation. The order matters. I've watched founders try to jump straight to Ship more than half a dozen times in 2026 alone. They all paid for the rescue twice.

The Structure

What are the 5 layers of the Crash Cart?

Layer 1 · Hours 1–4

Stop the Bleed

What it is: Take down dangerous behavior immediately. You're not refactoring — you're stopping ongoing damage.

What gets done: Rotate hardcoded API keys. Patch the obvious SQL injection. Disable endpoints with no auth. Kill webhooks that lack signature verification. Stop background jobs eating money. Anything that's actively losing money, leaking data, or running unauthorized code gets handled in the first four hours.

When it's done: Nothing visible to users is on fire. The dangerous behavior is paused or patched. The team can think. Nobody is great at thinking with the building burning down.

Layer 2 · Day 1–2

Stabilize

What it is: Get the system into a known, reproducible state. Freeze the patient so you can examine them.

What gets done: Pin every dependency to an exact version. Lock the schema. Create a staging environment that matches production. If there's no deploy process, document the current one. Capture the environment variables. Snapshot the database.

When it's done: Anyone on the team can reproduce production locally and feel confident the staging behavior matches reality.

Layer 3 · Day 3–5

Survey

What it is: Map what exists. The read-and-annotate phase.

What gets done: Inventory every file. Every route. Every dependency. Every external service. Document what each piece does (or seems to do) in plain language. Surface assumptions the code is making. Flag the parts nobody understands. Generate the map you should have had on day one.

When it's done: You can answer "what does this codebase do?" without opening a file.

Layer 4 · Week 2

Strip

What it is: Remove what isn't needed. Surface area is the enemy.

What gets done: Dead code, gone. Unused dependencies, gone. Speculative abstractions the AI built "just in case," gone. Half-finished features, gone (or finished). Most rescued codebases shrink 30–50% in this phase. The shrinkage isn't the goal; comprehension is. Smaller surface area is just how comprehension gets reachable.

When it's done: Every file in the project has a reason to exist that someone can articulate.

Layer 5 · Week 3+

Ship

What it is: Resume normal development. Make the next feature work.

What gets done: With the foundation triaged, stabilized, mapped, and stripped, real work is possible. Every change from here forward maintains comprehension instead of degrading it. This is no longer a rescue — it's a normal engineering team doing normal engineering.

When it's done: It's not. This is the new steady state.

When should you roll the Crash Cart?

If more than one of these is true, the answer is now:

  • The next "small" feature has felt impossible for more than two weeks.
  • You inherited a codebase from a contractor or AI tool and nobody on the team can explain it.
  • An AI-built app is failing in production in ways your team can't reproduce locally.
  • You're paying for SaaS or API usage and nobody is sure why or what's calling what.
  • The codebase has security holes you know about but haven't patched because you're afraid of breaking something else.

The Crash Cart is the alternative to "let's just rewrite it." Most codebases don't need a rewrite — they need triage. A rewrite is what founders want when they're scared. Triage is what works when they're tired of being scared.

Frequently Asked Questions

Crash Cart FAQ

What is the Crash Cart framework?
The Crash Cart is a 5-step triage framework for rescuing broken, inherited, or AI-generated codebases. The steps, in order: Stop the Bleed (hours), Stabilize (days), Survey (days), Strip (week), Ship (week and beyond). It treats a codebase rescue the way an ER treats a trauma patient — bleeding first, scars later. Coined by Justin McKelvey, fractional CTO, 2026.
When do I roll the Crash Cart?
When you inherit a codebase you didn't write, when an AI-built app starts failing in production, when a developer leaves and nobody understands their code, or when the next feature has felt impossible for more than two weeks. If you can't ship a small change confidently, the foundation needs triage before more features get layered on.
How long does the Crash Cart take?
Typical engagement: Stop the Bleed takes 4–8 hours. Stabilize takes 1–2 days. Survey takes 3–5 days. Strip takes about a week. Ship is open-ended — that's where normal development resumes. Total: 2–3 weeks before you're shipping new features at a healthy pace. Smaller codebases compress; very large ones can extend Survey.
Can I skip steps in the Crash Cart?
No. Each step assumes the previous one is done. You can't Survey a codebase that's still on fire (skipped Stop the Bleed). You can't Strip what you haven't Surveyed. You can't Ship cleanly on an unstable foundation. Skipping creates the second engagement that costs more than the first.
What's the difference between the Crash Cart and a rewrite?
A rewrite throws away the existing code and starts over. The Crash Cart keeps the existing code and triages it — stops the dangerous behavior, freezes the state, maps what's there, removes what's unneeded, then ships. Rewrites are usually 3–5x more expensive and ship months later. Use the Crash Cart unless the existing code is genuinely unrecoverable, which is rarer than founders think.
What happens during Stop the Bleed?
Hours 1–4 of the engagement. Take down dangerous behavior immediately: rotate hardcoded API keys, patch obvious injection vectors, disable endpoints with no auth, kill webhooks with no signature verification, stop background jobs eating money. You're not refactoring — you're stopping ongoing damage. Everything else can wait.
How much does a Crash Cart engagement cost?
Most engagements run $25K–$50K depending on codebase size and how deep the damage goes. That's the productized Vibe Code Rescue offer. The price includes Stop the Bleed through Strip (steps 1–4); Ship continues either as ongoing fractional CTO retainer or with your existing team.

If your codebase needs the Crash Cart, let's start with a call.

Thirty minutes. I'll tell you whether the Crash Cart is the right move, or whether your situation needs something different (sometimes it's just a refactor; sometimes a rewrite really is the right call).

Book a strategy call