Failed engagements have a smell: velocity slides without merges, “almost done” demos that never harden, rotating faces in Slack, and a codebase nobody on the vendor side can explain end-to-end. Founders usually wait too long — hoping the next sprint fixes culture — until the calendar and the burn rate force a harder question: stabilize what exists, or rebuild?
We have lived this pattern on rescue work (including LMS rebuilds after prior teams burned months without a shippable system). This playbook is facts-only: decision criteria, week-1 triage, and how to buy senior continuity so you do not pay for the same failure twice. No invented client metrics.
When you are in a rescue — not a rough patch
Treat it as a rescue when several of these are true: • The people who sold the work are not the people writing code (or they left). • Critical paths (auth, payments, data model, deploy) are undocumented or only live in one contractor’s head. • Demo environments work; production-like environments do not — or do not exist. • Deadlines slipped repeatedly with the same root causes (scope thrash, missing seniors, no CI reality). • You cannot get a coherent architecture walkthrough in one sitting. • Legal/IP ownership of repos and cloud is fuzzy.
A rough patch has named owners and a narrowing residual risk list. A rescue has narrative without evidence.
Rebuild vs stabilize: a decision frame
Stabilize (and surgically rewrite) when: the domain model is mostly right; production has real users you cannot freeze; the worst problems are delivery process, tests, observability, and a few hot modules; and a senior team can map the system in week one without discovering that every layer is a lie.
Rebuild (greenfield or strangler with a hard cut) when: the data model cannot support the product you actually need; security/tenancy is fundamentally wrong; the prior team left a prototype sold as production; or the cost of understanding and patching exceeds the cost of a clean vertical rewrite with migrated data.
Many rescues are hybrids: keep the database truths that are real, replace the application shell, and strangler the worst modules. The Brandsonify / Cyber Guardians pattern — months lost with a prior team, then a time-boxed rebuild with seniors who stay — is the extreme rebuild case. Your situation may be milder. The frame still applies: pick the strategy explicitly; do not “polish” a foundation you have already decided is unsafe.
Week-1 triage (what seniors should do first)
1. Access & ownership audit — GitHub/org, CI, cloud, domains, secrets, analytics. Everything critical into accounts you control. 2. Run it — local, staging, production-like. If it cannot boot reproducibly, that is finding #1. 3. Map the critical path — auth, tenancy, billing, primary user journey, deploy pipeline. Draw it. Name the gaps. 4. Risk register — security, data loss, compliance, single points of failure. Severity × likelihood, not vibes. 5. Artifact honesty — which docs/tests/CI jobs are real vs decorative. 6. Decision memo — stabilize vs rebuild vs hybrid, with a time box and a kill criterion. 7. Continuity terms — named engineers for the rescue duration; no silent bench swaps.
If a prospective rescue team cannot produce that memo after a short paid discovery, they are not rescuing you — they are auditioning for the same movie.
Senior continuity is the product
Rescues fail the second time when the new vendor repeats the old operating model: juniors after kickoff, PM translation layers, and “flex capacity.” Write into the engagement: who is on the repo, who reviews architecture-sensitive diffs, how swaps work, and that runbooks land in your documentation.
Agents and AI coding tools can accelerate a rescue — they do not replace verification. The same bar we wrote about for agentic coding applies: humans own merges, CI must be allowed to fail bad agent output, and someone must still explain the system after the chat tab closes.
Founder questions before you sign a rescue SOW
“Show me the week-1 triage plan for our repo — not a generic slide.” “Stabilize, rebuild, or hybrid — and what evidence would change your mind?” “Who is named on the engagement through the cutover date?” “What does ‘done’ mean in production terms (not demo terms)?” “If we stop in 30 days, what artifacts remain in our orgs?”
Teams that have done real rescues answer without theatre. Teams selling hope change the subject to hours and logos.
