How to rescue a failed software project
Key takeaways
Most failed software projects are recoverable. Secure the domain, DNS, hosting and code repository in your own name before anything else. Take your own backup of the code and the database. Then get a written assessment of the code from someone who does not stand to gain from the answer being “rebuild it”. The money already spent is gone either way, and is not a reason to keep going. PhysioPro came to us half working and insecure, and was live again in a week.
We regularly hear the same question, usually phrased almost exactly like this: "How do I rescue a failed software project?" Sometimes the developer has gone quiet. Sometimes the money ran out with the thing half built. Sometimes it was delivered, and it simply does not do what was asked for.
Whatever the route in, the position feels the same. You have spent real money, you have software your business is supposed to depend on, and you do not know whether what you have is worth anything at all.
Here is the honest answer, in the order we would actually do it.
Is the project really failed, or has it just stalled?
Worth separating, because the two need different things.
A stalled project has a working relationship that has gone cold. The developer is slow, distracted or overcommitted, but the code is intact and the knowledge still exists in someone's head. These are usually recoverable without changing supplier at all, and often the cheapest fix is a direct conversation about scope and money.
A failed project is one where the route forward is blocked: the developer has gone, the relationship has broken down, or what was delivered does not work and cannot be made to work by the people who built it. That is the situation this guide is about.
The test we use is simple. If the current developer came back tomorrow, fully available and motivated, would you want them to carry on? If the answer is yes, you have a stalled project and a scheduling problem. If it is no, you have a takeover to plan.
What should you do first, before anyone writes any code?
Get your access and ownership in order. This matters more than anything technical, and it is the single biggest predictor of how painful the rescue turns out to be.
Work through this list and check each one is in your name, on your account, with you as the administrator:
- The domain name. Check the registrar and who the registrant is. A domain registered in a developer's name is the most common single point of failure we see.
- DNS. Whoever controls DNS controls where your website and email point.
- Hosting. Not "they manage it for us". An account you can log into and pay for yourself.
- The code repository. Ask for ownership transfer of the repository, not a zip file of the code. The history is worth having: it tells the next developer what changed, when and why.
- The database, and a copy of it you hold.
- App store accounts, if there is a mobile app. Apple and Google accounts registered to the developer are painful and slow to move.
- Payment gateway, email service, SMS, mapping, any paid API. These usually sit on someone's card.
Most people have never thought to ask for any of this, because why would you? It is not a failure on your part. But get it done before relationships get any more strained, because every one of these is easier to request while people are still talking.
Take your own backup, today
Whatever else happens, get a copy of the code and a copy of the database, and put them somewhere you control. Not on the developer's hosting. Not in a shared drive that someone else administers.
If you cannot do this yourself, it is a reasonable and very small thing to pay someone to do. It costs almost nothing and it removes the worst case entirely.
Gather the paperwork while you still can
Boring, and it saves a lot of money later. Collect the contract or the statement of work, the original specification or brief, invoices and what they were for, any ticket or issue history, design files, and the list of credentials from the section above.
The reason is simple. Anyone assessing the project will otherwise spend billable hours working out what was supposed to happen. Handing that over as a bundle is the cheapest hour you will ever buy.
How do you find out what state the code is actually in?
This is where the do-it-yourself route runs out, and it is worth being straight about that.
What you want is a review of the codebase that answers four questions in plain English:
- Does it do what it claims? Not what the demo showed. What it does now.
- Is it secure? Specifically: how are passwords stored, is customer data exposed, are the dependencies wildly out of date, and are any credentials sitting in the code itself.
- Can it be worked on? Is it structured well enough that a new developer can make changes without breaking things elsewhere.
- What would finishing it involve? A list of what is missing, roughly sized.
A review like that is normally a short, fixed piece of paid work, and it should produce a written answer you can understand without a technical background. If someone will not quote for the review itself, or will only tell you the answer after you commit to a rebuild, that is worth noticing.
Be wary of one particular answer. If the first thing you are told is "start again", ask what specifically cannot be salvaged and why. Sometimes that is the honest verdict. Often it is the easier sale: reading someone else's code is slow, awkward work, and building from scratch is simpler to price and more enjoyable to do. It is also considerably more expensive for you. We have written separately about why so many developers refuse to take over existing code.
Should you finish it, or start again?
After a proper review, the decision usually makes itself. Our rough rule:
Finish it when the structure is sound and the gaps are features. Most projects that feel like disasters are in this category. What looks like a mess is very often a system built by someone competent who ran out of time or money.
Repair, then finish when it works but carries real problems, most often security. Fix the dangerous parts first, then carry on.
Start again when the foundations genuinely cannot carry what you need. The clearest version of this is something built on the wrong platform for the job, where every future change fights the tool. That is a real category, but it is much rarer than the industry's enthusiasm for it suggests.
One thing to put out of your mind while deciding: the money already spent. It is gone either way, and it is not a reason to keep going down a road that does not lead anywhere. The only question that matters is which route is cheaper and quicker from where you stand today.
What a rescue looks like in practice
PhysioPro is a continuing professional development app for physiotherapists. The owner had paid a previous developer to build it, and what came back did not do what had been asked for. A closer look showed the code carried significant security flaws that put user data at risk.
The route through was ordinary. We took ownership of the existing code and read it properly, so we knew how it was put together and where the problems were. Each piece of work after that was priced and approved before it was started. We closed the security holes, rebuilt the app to accepted standards, and handed it back working, with the client owning the code outright. It was live in a week.
There was nothing clever about the sequence. Read it, price it, agree it, fix it. What made the difference was starting with an honest assessment rather than a rebuild quote.
The part that genuinely needs a developer
You can do most of the list above on your own. Securing the domain, collecting the credentials, taking a backup, gathering the paperwork: all of that is admin, and doing it yourself puts you in a much stronger position no matter who you hire next.
What you cannot reasonably do yourself is open the codebase and tell yourself the truth about what is in it.
Taking over half-finished software is the work we do most weeks, and most takeovers start with a short paid review, so you know what you have before you spend anything serious. If you would rather hand that part over, tell us what you are dealing with.
What to do this week
Three things, in this order:
- Secure ownership. Domain, DNS, hosting, repository, app store accounts. In your name.
- Take a backup of the code and the database, somewhere you control.
- Get a written assessment of the code from someone who does not stand to gain from the answer being "rebuild it".
The fear underneath this question is almost always the same one: that you will spend more money and end up in exactly the same place. The protection against that is not trust, it is structure. Work priced job by job, agreed before it starts, with the code and every account in your own name. Then if you ever want to walk away, you can, and you take everything with you.
If pricing is the part you are unsure about, how to get a fixed price for software work covers how a job gets sized and agreed, and what custom software actually costs gives real numbers. There is more on takeovers across the rescue pillar, and the rescue page sets out how we handle them.
If you want a number rather than a conversation, tell us what you are dealing with and you will have a fixed price without a phone call. And if it turns out you do not need a developer at all, we will tell you that too.