Services — Project Rescue
Software project rescue
A project is months past its date, well past its budget, or the people who understood it are gone. The work starts with an independent assessment of what actually exists — not what the status reports say exists.
When this applies
The vendor relationship has broken down. Invoices kept arriving, the demo kept slipping, and the last three status calls covered the same blockers. You need to know what you actually own before you decide whether to continue, replace or finish it yourself.
The developer left. One person built the system and held everything that mattered about it in their head. The code is there. The reasoning behind it isn't, and neither is the list of things that quietly depend on it.
The build technically works but can't ship. It passes a demo and fails under real data, real load or a real security review. The gap between "running on a laptop" and "running in your environment" turned out to be most of the project.
It was built fast, and now it has to change. A contractor or an internal team under deadline produced a large amount of code quickly, often with heavy AI assistance. It went to production. Now a change is needed and nobody can say with confidence what depends on what.
What the rescue involves
The assessment comes first
A fixed-fee review of the code, the data model, the integrations and the deployment path. It answers the questions that determine every subsequent decision: how much of what exists is usable, where the genuine risk sits, whether the architecture can carry the remaining requirements, and what finishing it actually costs against what replacing it costs.
The assessment is a standalone deliverable. It's written for a stakeholder who has to defend a budget decision, and a good number of clients take it and hand it to their own team. There's no obligation to continue past it.
Then a plan you can actually act on
Most rescues do not end with a rewrite. Rewrites are the expensive answer, and they're usually chosen because nobody had a clear enough picture to choose anything else. The more common outcome is a fixed, reduced scope that gets a working system into production, with the deferred work identified explicitly rather than left implied.
Where a rewrite genuinely is the right call, you'll get the reasoning for it in terms that survive a conversation with leadership who signed off on the original spend.
Then execution, by the same person
The engineer who did the assessment is the engineer who does the build. On a rescue this matters more than on a greenfield project, because most of the value in the assessment is context that never fully makes it onto a page.
Describe what you're dealing with
Where the project is, what's been spent, and what's blocking it. The first conversation costs nothing and usually clarifies whether an assessment is worth doing.
Get in touch