A rescue triage week is not a deep audit. It is a fast read on whether shipping the next milestone is realistic, what shipping it actually requires, and where the previous team’s foundation is solid versus rotten. Five working days, one written deliverable. Here’s the day-by-day playbook we use on every engagement.

Day 1: the demo and the deploy

Day 1 is two questions. Question 1: can the existing team or owner give us a working demo of what’s been built? Not a pitch, an actual click-through. We watch what works, what’s hand-waved, and what produces a frozen ‘let me try that again on a different machine’ moment. Each of those moments is a clue.

Question 2: can we deploy what’s been built ourselves, from the source repo, on a clean machine, following the team’s documentation? About half the time the answer is ‘no, the deploy procedure depends on a single person’s laptop or a config file that isn’t checked in.’ That’s information about the codebase’s maturity, separate from any code review.

Day 2: the codebase walk

Day 2 is a structured codebase tour with the most senior remaining engineer. Not a code review — a tour. We’re trying to understand the architecture, the conventions, the parts that are clean vs. legacy, and the parts the team is afraid to touch. The ‘parts the team is afraid to touch’ question is the most diagnostic question in the entire week. The answer often points at the bug source.

We also run a few automated reads: test coverage, dependency freshness, any obvious security flags, the build/CI status. None of these are decisions yet. They’re inputs to the ship-plan we’ll write on Friday.

Day 3: the data and the integrations

Day 3 looks at what’s outside the codebase. The database (does the schema match the codebase’s expectations? Are there orphaned tables and dead columns?), the third-party integrations (which APIs is this thing actually calling, with which credentials, against which environments?), and the cloud account (is this £200/month or £20,000/month of infra? Who has access?).

Half of all rescue surprises live in this layer. A codebase can look okay and still be load-bearing on an unowned third-party API key from a former contractor. Surfacing this in week 1 means it’s a known risk on the ship-plan rather than a 3am production incident in week 7.

Day 4: the team and the agreements

Day 4 is conversations. We talk to the people on the project — internal team, remaining contractors, sometimes customers — about what they think happened, what they think shipping requires, and what blockers are political vs. technical. This is the day where the actual situation usually becomes clear, and where the previous team’s good-faith mistakes show up.

We also pull and read every contractual document we can: SOWs with the previous agency, IP assignment language, hosting and license agreements. UK rescue engagements often hit a snag here — IP assignment language in a ‘we’ll sign the standard contract’ SOW is rarely sufficient. We’ve come to do this read-through early so the legal questions can run in parallel rather than blocking later.

Day 5: the ship-plan deliverable

Friday is writing day. The deliverable is a single document, 6–12 pages, with five sections: state of the build (what works, what doesn’t, what’s load-bearing on what), the realistic ship list (what gets to production in the next milestone, what’s deferred), the resourcing required (who, in what role, for how long, at what cost), the risks (with mitigations), and the recommended next two weeks.

Lorenzo and the client read this together on Friday afternoon. Sometimes the ship-plan says ‘this is recoverable in 6 weeks, here’s how.’ Sometimes it says ‘the most honest thing is to scope down to a third of what was promised and ship that, calling it Phase 1.’ Sometimes — rarely — it says ‘rebuild from scratch is cheaper than rescuing.’ Whatever it says, it’s written, it’s argued through, and the client owns the decision from there. Book a triage and we’ll get a date in the diary.