Guide
How to rescue a stalled software project.
Updated
A project that is late, over budget or abandoned by the team that started it is hard to judge from the inside. The questions are the same each time: is what exists worth keeping, what would it cost to finish, and what do you need in hand before anyone can tell you.
Signs a build has stalled
- The previous agency or freelancer left, and nobody fully understands what they built.
- The project keeps slipping, and every estimate you get is bigger than the last.
- The software runs, but every change breaks something else.
- You need an honest second opinion before putting more money in.
Questions to answer before you spend more
Before more money goes in, put these to yourself and to whoever is still working on the project. If the answers are vague, that tells you something too.
- What would it take to reach a working release, and has anyone put that in writing?
- Which parts of the code does anyone still understand?
- What has been paid for so far, and what do you have to show for it?
- If the same team carries on, what will be different this time?
What to gather before anyone looks at it
An honest assessment needs the code, the running system and the people who remember it. Before you ask anyone to look, pull together:
- Access to the code, wherever it lives.
- A way to run the system, and access to the accounts it runs on.
- The names of anyone still around who knows how it works.
- Whatever records exist of what was planned, what was delivered and where it went wrong.
If something is missing, for example because the previous team will not hand over access, finding out what you have and how to get the rest back is the first job.
Repair or rebuild
This is the decision that matters most, and it should be made from a written assessment of the code, not from instinct.
- Repair. Keep the existing code where it is sound. Fix what is broken, add the tests and tooling that were missing, and get to a stable, working release.
- Rebuild. Start again, but only when that gets you to a working product sooner than untangling what exists.
A rebuild costs more and takes longer, so it makes sense only when repair would cost more still. Most rescues keep most of the code.
What a good assessment tells you
A triage should read the code, run the system, talk to whoever is left who knows it and review the history of what went wrong. It should end in a written report that covers:
- An honest assessment of the codebase: what is sound, what is fragile, what is dangerous.
- A recommendation: repair or rebuild, with the reasons.
- A fixed price and timeline for the recommended path.
Ours is the Rescue triage. $4,500 fixed. 1 week. The report is yours whether or not you continue with us, and if you do, the $4,500 comes off the price.
What to expect once work starts
The first weeks of a rescue often reveal problems nobody knew about. The right response is to hear about them straight away, with a price for dealing with them, and to decide for yourself.
Each week should bring a working release in staging, each one more stable than the last, a written update on what was fixed, what was found and what is next, and a 30-minute call to review it and set priorities together.