The implementation stalled. The deadline did not.
A time-boxed intervention on a build that has gone wrong. We diagnose it, fix what is blocking you, document what we did, and leave.
The problem
Something was delivered. It does not work.
The project went live, sort of. Half the team is back on the old process. The integration fails most nights. The last three change requests came back with estimates that made no sense.
The first question isn't who's at fault. It's whether what exists can be made to work, and what that costs against starting again. You can't answer that from inside the argument.
What you get
A straight diagnosis, then the fix.
- A written diagnosis. What was built, what works, what does not, and what it will take to get to usable. Specific enough to act on and blunt enough to be useful.
- The blocking fixes. The things stopping your team using the system, done inside the agreed scope rather than added to a backlog.
- Data checked. Whether the migration did what it claimed, and reconciliation where it did not.
- Documentation of what exists. Usually the first time anyone has written down how the build actually behaves, which is why the changes kept breaking things.
- A recommendation on the rest. Fix, rebuild or live with it, with the cost of each and our reasoning on the page.
- Ammunition for the vendor conversation. An independent read of what was delivered against what was contracted, if that conversation is still open.
How it runs
Two to six weeks, then we are gone.
- Week 1
Diagnose
Org, metadata, repository, integrations and interviews with the people trying to use it. Ends with a written report and a scoped fix list you approve before anything else happens.
- Weeks 2–5
Fix
The approved list, in priority order, deployed in stages. Progress visible weekly, because you have already had enough of finding out at the end.
- Final week
Hand back
Documentation, deployment history, a walkthrough with your team, and a written note on what we deliberately did not do and why.
Fit
Who this is not for.
- Anyone looking for an expert witness. We will give you an honest technical read; we are not building a legal case.
- Situations where the decision to rebuild has already been made. Skip this and talk to us about the build itself.
- Organisations that want the report to reach a conclusion agreed in advance. If we take the work, the findings are the findings.
- Ongoing support. Rescue ends deliberately. If you want somebody permanently in the seat, that is the fractional CTO engagement.
FAQ
Questions we get asked
How quickly can you start?
Usually within a week or two. Rescue work is scheduled to start quickly because the whole premise is that waiting is the expensive part.
Do you need our current vendor to cooperate?
It helps and we will work with them where the relationship is intact. Where it is not, we work from the org, the metadata and the repository. Most of what we need is in the system rather than in somebody's head.
What if the diagnosis says the build should be scrapped?
Then we tell you, in writing, with the reasoning and what starting again would take. That answer is uncomfortable and occasionally it is correct, and you are better off hearing it in week two than in month eight.
Is this just an audit?
No. An audit hands you a report. Rescue diagnoses and then fixes the things blocking you, inside the same fixed scope. The report is a by-product.
What does it cost?
Priced per engagement after the diagnosis, because quoting a fix before seeing the org is guesswork. The diagnosis itself is fixed price and small enough that it is not a difficult decision.
Can you stay on afterwards?
Only if you ask. The service is designed to end. If you decide you want ongoing technical leadership after that, our fractional CTO engagement is a separate conversation with separate pricing.
Next step
Tell us what went wrong.
Thirty minutes. Bring the org or the problem. You leave with a straight answer on whether it is worth fixing.