The Salvage Process
Understand it before you change it
Five phases, run in order. The order is not a formality — it is the entire argument. Most software disasters are made worse by someone confident, working fast, in a system they had not yet read.
- 01
Triage
What happened?
Before anything else: how bad is it, how fast is it getting worse, and what is the actual deadline. Some of what arrives as an emergency is a nuisance, and some of what arrives as a nuisance is about to take down a payment flow. Triage tells the two apart.
- Establish the symptom, the timeline, and who is affected
- Get access — repository, infrastructure, logs, environments
- Separate what is urgent from what is merely loud
- Agree what "back to normal" means, in writing
- 02
Inspect
What do we actually have?
A read of the real system rather than the one in the documentation. Architecture, dependencies, data, deployment, the parts still running that nobody can account for. This is where the unknowns get written down and stop being surprises.
- Map the architecture from the code, not from a diagram
- Trace the data — where it lives, who writes it, what backs it up
- Inventory dependencies, versions, and what is out of support
- Reproduce the failure on demand where there is one
- Write down every unknown rather than papering over it
- 03
Stabilise
How do we stop making it worse?
The unglamorous phase, and the one that decides whether any of the rest works. A system you cannot build, deploy, restore or observe cannot be safely changed by anyone — so that comes first, before a single feature is touched.
- A build that runs on a machine other than one person’s laptop
- Deploys that are repeatable and do not require a ritual
- Backups that have actually been restored at least once
- Enough logging and alerting to know when something breaks
- The immediate bleeding stopped — the fix that buys time
- 04
Recover
How do we get it working again?
With the ground no longer moving, the real defects get fixed: the broken integrations, the critical bugs, the functionality that was promised and never arrived. In priority order, with the trade-offs named out loud.
- Fix the critical defects, worst blast radius first
- Repair the integrations that other people depend on
- Finish or formally cut the unfinished work
- Verify against something better than "it looks fine"
- 05
Modernise
What should this become?
Only now. Framework upgrades, infrastructure moves, refactors, the parts genuinely worth rewriting — decided from evidence rather than from distaste. Plenty of engagements never reach this phase, because by the end of phase four the system is doing its job and the money is better spent elsewhere. That is a good outcome, not a lost upsell.
- Upgrade what is out of support and is actually costing you
- Replace the components the evidence says to replace
- Move infrastructure only where there is a reason beyond fashion
- Hand back documentation your team can maintain without us
How we work inside your system
We propose. You merge.
Nothing ships without someone on your team understanding it well enough to approve it.
The reason is not caution. It is the thing you hired us for. Half of what Salvage gets called about begins with some version of the last person who understood this system left — and a consultant who fixes things nobody on your team understands has rebuilt that exact problem with a fresher commit date.
Requiring your engineer to read and approve every change makes knowledge transfer a precondition of the work rather than something promised for the end of the engagement and skipped when it runs long. You end up with a system your own people can still maintain, which is the only outcome worth paying for.
- Default
Read-only
Assessments, autopsies, code reviewNo write access is requested, because none is needed to tell you what is wrong. A surprising number of engagements never go past this tier — you get the diagnosis and your own team does the work.
- Standard
Propose, never merge
All repair and recovery workEvery change arrives as a branch, a pull request, and a written rationale for why it is the right change. Someone on your team reviews it and merges it. That review is not a formality — it is the mechanism that stops any part of your system ending up understood only by us.
- Break-glass
Time-boxed write
Outages, by prior arrangementRequires written authorisation from a named person on your side, runs for a fixed window, logs everything touched, and closes with a written handover of every change made. The log is part of what you receive, not a courtesy.
Infrastructure follows the same shape by a different mechanism: we propose the change, pair on it while you make it, and you keep the credentials. Salvage does not end an engagement holding keys to your systems.
The practical consequence: on repair work, the schedule depends partly on your review cadence. You will be told when something is sitting in a queue waiting on a merge rather than waiting on us — and if reviews are the bottleneck, that will be in the weekly status in plain language.
Why the order matters
Every phase is cheap to skip and expensive to have skipped
The pattern is always the same. Someone skips inspection because the problem seems obvious, fixes the obvious thing, and discovers in week three that the obvious thing was a symptom. Or someone skips stabilisation because the client wants features, and every fix after that lands in an environment nobody can reproduce.
Then there is the big one: modernising before recovering. Rewriting a system you do not yet understand means reimplementing its bugs without its accidental protections, and finding out which ones mattered in production.
Running the phases in order is slower for about a week and faster for everything after it.
Before any of that
What the first week actually looks like
- 01
You describe it
An email in whatever shape it comes out. Symptoms, history, deadlines, the part you are embarrassed about. No form, no discovery deck.
- 02
A call, if it helps
Thirty minutes to establish whether this is something Salvage can help with. Free, and sometimes it ends with a suggestion you can act on yourself.
- 03
A scope and a number
In writing, with what is included and what is not. If the honest answer is that you do not need to hire anyone, that is what the email says.
- 04
Access, then work
Repository, infrastructure, logs, whoever knows the most. Triage starts the day access lands.
Start at phase one
Triage is a conversation, not an invoice. Describe what is happening and you'll get an honest read on how bad it is and what it would take.
First reply usually within a few business days, from a person