What the brief usually says, and what it usually means
A rescue brief usually arrives in one of two shapes. Either the site is down often enough that the board has noticed, or the previous agency relationship has ended badly and the codebase is now an orphan. The ask is the same in both cases. Make it stable, make it ours, and do not embarrass anyone in the process.
The first week of discovery confirms the immediate problems and the second week finds the structural ones. The structural ones are always the same: an upgrade that was never finished, an integration that was never owned, a checkout that was customised by three teams in sequence and a deployment process that one person understood.
The diagnosis that actually helps
A useful rescue diagnosis answers three questions and resists the temptation to answer any others.
Can the platform be made stable on its current version, with the team and budget the business is willing to commit, for a defined period? Often yes for six months, rarely yes for two years.
What is the smallest set of changes that buys that period without making the eventual replatform harder? This is the genuinely useful work and the part most rescue plans skip. It is also the work that earns the trust required to have the harder conversation.
What does the replatform look like if it has to start in nine months, not three years? That is almost always the real timeline, and modelling it now gives the business something to plan against rather than react to.
"The most expensive project is the one you have to do twice. A patched-up rescue that fails again next year is worse than a properly scoped replatform now."
The conversation nobody wants to have first
The conversation that turns a rescue into a credible project is the one where the agency tells the client that the brief is wrong. Not the symptoms, the shape of the work. That conversation goes badly when it happens in week one and well when it happens in week four with evidence.
In rescue work we have learned to spend the first month doing the small, useful, visible things, and to hold the structural conversation until the team has earned the right to have it. That is not delay. It is the only way the business hears it.
When a rescue is actually a rescue
There is a minority of cases where the brief is correct and the work really is a rescue. The pattern is usually a recent platform, a competent team that lost a key person, and a backlog that grew faster than it could be cleared. In those cases the work is genuinely surgical and the replatform conversation is wrong.
The skill is telling those cases apart from the ones that look like them on the first call. The cheapest way to get that wrong is to take the brief at face value and start fixing tickets in week one.
