The developer stopped responding three weeks ago. The code is in a repository nobody on your team understands. The staging site works on the developer's machine, apparently. The launch date has already passed twice.
This is the point where most business owners start asking the wrong question: "Can someone finish this?"
The better question is: what exactly do we have, who controls it, and is it worth continuing?
A failed software project can often be rescued, but only if the first few steps are practical and unemotional.
Step 1: Get Control of the Assets
Before a developer can rescue anything, you need access.
That means:
- domain registration
- DNS
- hosting
- Git repository
- database
- admin accounts
- payment gateway accounts
- email/SMS providers
- analytics
- third-party APIs
- deployment credentials
If any of those are still controlled by the previous developer or agency, the rescue starts there. Not in the code editor.
A project you cannot access is not a software problem yet. It is an ownership problem.
Step 2: Freeze the Situation
Do not keep paying for random fixes while nobody understands the system.
Freeze new feature work. Stop adding scope. Take backups. Export the database. Snapshot the current server. Record what is live, what is broken, and what users currently rely on.
The worst rescue projects are the ones where three different developers have already made emergency changes without documenting anything.
Step 3: Run a 72-Hour Technical Triage
A good rescue triage answers five questions:
- Can the application run locally?
- Can it be deployed safely?
- Is the database understandable?
- Are the dependencies current enough to maintain?
- Are the core workflows functional, partial, or missing?
This is not a full rebuild estimate. It is a technical reality check.
The output should be short and useful: what works, what is missing, what is dangerous, and what needs attention first.
Step 4: Build a Dependency Map
Most failed projects are not broken in one place. They are tangled.
The payment gateway depends on the user model. The reporting depends on the database structure. The mobile app depends on an API that was never finished. The admin panel updates data in a different format from the frontend.
A dependency map shows what touches what. Without it, every "small fix" can break something else.
Step 5: Create a Risk Register
The risk register is where the project becomes manageable.
Rank each risk by severity:
- access risk
- data risk
- security risk
- architecture risk
- dependency risk
- performance risk
- scope risk
- business continuity risk
A risk register is not there to scare you. It is there to stop surprises from arriving one invoice later.
Step 6: Decide: Continue, Fork, or Rebuild
There are three realistic rescue paths.
Continue when the code is messy but understandable, the core architecture is reasonable, and the missing work is definable.
Fork when parts of the system are usable but one section needs to be replaced, isolated, or rebuilt safely.
Rebuild when the code is unsafe, the architecture cannot support the product, or the cost of understanding the old system is higher than building the right foundation.
Rebuilds are not a moral failure. Sometimes the cheapest way forward is to stop defending the money already spent.
What Rescue Usually Costs
A rescue should not start with a giant open-ended quote.
Start with a fixed triage. After that, decide whether the next step is a small stabilisation sprint, a rebuild plan, or a continuation scope.
Typical paid phases look like this:
- triage and access review
- stabilisation sprint
- rebuild or continuation scope
- launch support
- maintenance retainer
The important thing is that each phase produces a decision, not just more hours.
When Not to Rescue
Do not rescue a project just because you already paid for it.
Do not rescue code that has no clear owner, no deploy path, hardcoded secrets, no database integrity, or a foundation that cannot support the actual business workflow.
Do not rescue a project where the commercial relationship is already so broken that nobody can make decisions.
In those cases, rescue the learning and rebuild the product.
Red Flags That the Project Was Never Going to Ship
The warning signs are usually visible in hindsight:
- no written scope
- no version control
- no milestone demos
- no staging environment
- no access owned by the client
- no test data
- no deployment process
- no definition of done
- constant "almost finished" updates
If several of these are present, you are not dealing with one bug. You are dealing with a delivery failure.
How to Fire a Developer You Already Paid
Keep it factual.
Ask for the repository, database export, hosting details, third-party account list, current status, and any outstanding invoices. Do not debate blame in the same email where you need handover.
If they cooperate, keep the tone clean and move on.
If they do not, document everything and get legal advice before attempting account recovery that could become disputed.
How to Find a Rescue Developer
Look for someone who asks boring questions before promising a fix.
They should ask about repository access, deployment, database backups, third-party services, scope, payment status, and current users.
If someone promises to "finish it quickly" before seeing the code, that is not rescue. That is sales.
For commercial takeover work, see software project rescue.
FAQ
Can any failed project be rescued?
No. Some projects should be rebuilt. The first job is to find out which situation you are in.
What if the old developer will not hand over?
Then the first issue is asset ownership. You may need domain, hosting, payment, or repository recovery before technical work can begin.
Should I ask for a fixed quote immediately?
Ask for a fixed triage first. A full quote before review is usually a guess.
Is messy code always a rebuild?
No. Messy but understandable code can often be stabilised. Unmaintainable or unsafe code is different.
How long does triage take?
For many small to mid-sized projects, a useful first triage can happen within 72 hours after access is available.
What should I send before asking for help?
Send the repo, staging/live URLs, hosting details, current scope, known problems, invoices or handover notes, and a plain-English summary of what happened.