How to Rescue a Failed Software Project

Signs a project has failed, or is failing

• Deadlines keep moving and nobody can say what "nearly done" means.
• The developer has stopped replying, gone out of business or wants much more money to finish.
• Every fix breaks something else.
• The system is live but slow, insecure or losing data.
• You do not have access to the code or the server.
• Nobody else can understand the code well enough to change it.

None of these mean the money is lost. Plenty of stalled projects contain useful work that can be finished or reused.

Step 1: secure what you have

1. Get access to the source code repository, ideally moved into an organisation account you own. If there is no repository, get a copy of the code from the server.
2. Get admin access to hosting, domains and DNS, databases, email sending services, payment gateways and any API registrations (Stripe, Xero, Shopify).
3. Take full backups of code, databases and uploaded files, and store them somewhere separate.
4. Change passwords and API keys if the previous supplier should no longer have access, after checking nothing will break.
5. Gather the contract, specification, emails and invoices. They show what was promised and whether you own the code, which our code ownership guide explains.

Step 2: get an independent assessment

A code audit should answer practical questions: Does it run? Can it be deployed repeatably? Which features work, which are half-built and which are missing? Are there security holes, such as SQL injection, exposed secrets or missing permission checks? Are the framework and language versions supported (an app stuck on PHP 7 or an old Laravel version needs an upgrade path)? Is there test coverage? Is the data model sound? The output should be a plain-English report with risks ranked and options costed, not a list of style complaints.

Step 3: fix, finish or rebuild?

• Fix and finish when the architecture is sound and the problems are bugs, gaps and missing features.
• Stabilise then replace in stages when the system is live and business-critical but poorly built. Wrap it, fix the dangerous parts, then replace modules one at a time.
• Rebuild when the foundations are wrong: an unworkable data model, an abandoned proprietary framework, or code nobody can safely change. Reuse the specification, designs, data and lessons.

Whatever the choice, reset the scope. Finish the features that deliver most value first and push the rest into later phases, rather than trying to deliver the original wish list in one go.

How to avoid the same problems next time

A rescue is a good moment to put in place the habits that stop projects failing in the first place:

• Code in your own repository from day one, with the developer given access, not the other way round.
• Hosting and service accounts in your name, with the developer as a user you can remove.
• A written scope and a change process, so additions are agreed and priced rather than drifting in.
• Working software early and often on a staging site, so progress is visible and measurable.
• Automated tests and repeatable deployment, so changes can be made without fear and another developer can pick up the work.
• Documentation: a README that explains how to set up, run and deploy the system, kept up to date.
• Regular, honest reporting: what was done, what is next, what is blocked and any risks.
• A maintenance plan after launch, covered in our maintenance budget guide.
• Clear ownership of the code and data in the contract, as explained in who owns the code.

These are not expensive extras. They are what any competent supplier should offer as standard, and asking for them is the simplest way to separate dependable developers from risky ones when you choose who finishes the job.

When to talk to dijitul

dijitul offers software rescue for projects in PHP, Laravel, WordPress, Node.js and common ecommerce platforms. We start with a free chat, help you secure access, assess the code and give you honest options, then a fixed-price quote for the route you choose. You own the code and data throughout. See also legacy software modernisation.

Related