How to Take Over a Failed Software Project: A Step-by-Step Rescue Plan

Software projects rarely fail with a bang. They fail with a developer who replies a little slower each week, a vendor whose "next release" keeps moving, an app that works until the day it doesn't and nobody can say why.

If you're reading this, you're probably somewhere on that road. The good news is that most failed projects can be saved, and the first steps don't need a developer at all. They need you, this week, before anything else goes missing.

I'll walk through what we do when a project lands on our desk, using three that did: a trust hospital whose vendor stopped fixing its system, a property marketplace several teams had left broken, and a tailoring business whose app had become impossible to maintain.

The first 48 hours: secure what you own

Before anyone looks at the code, make sure you control everything the software depends on. When a relationship sours, access is what disappears first.

Make a list and check each item is in your company's name, with your email as the owner:

• The domain, at the registrar. Lose this and you lose your website and your email.
• DNS and email, wherever they're managed.
• Hosting: the cloud account or server, with an admin login you control.
• The database, and a fresh backup of it downloaded somewhere you control.
• The source code, in a repository (GitHub, GitLab, Bitbucket) where you're an owner, not a guest.
• App store accounts: Apple App Store Connect and Google Play Console. Without these, no update to your app can ever ship.
• Payment accounts: Stripe or your local gateway, so payouts go to you.
• Third-party services: email sending, SMS, maps, AI APIs. Note who pays and who can log in.

Anything that isn't in your name, ask for it now, politely and in writing. Most developers hand things over when asked clearly. If some won't, your contract and payment records are what you'll need, so find them too.

Then change the passwords and API keys that former team members know, once you're sure the new ones are in place. Not before; locking yourself out of your own system on day two is a common mistake.

The first two weeks: find out what you actually have

You can't decide what to do with something you haven't looked at. This is the step people want to skip, and it's the one that saves the most money.

Read before writing

When Rashid Kadura asked us to add a payment gateway to Beyut Libya, his property marketplace, we didn't start with the payment gateway. We read the code first. Several teams had worked on it, and the website and app weren't properly connected to the API, the server was a single machine updated by hand, and the code was too tangled to grow. Adding payments on top would have meant decorating a building with a cracked foundation. We showed him the problems in his own code on a call before we wrote anything.

That call is the point of an audit. You should come out of it understanding your own system, in plain language.

What a useful audit covers

• Does it run? Can it be built and deployed from the repository, by someone new, from the instructions?
• Is the data safe? Are there backups, and has anyone restored one?
• Is it secure? Are permissions checked on the server, are secrets kept out of the code, are passwords stored properly?
• Is money handled correctly? Can a payment be recorded twice? Do the books match the payment provider?
• How is the code? Is the structure sound and messy, or is the structure itself the problem?
• What do users actually depend on? The features people use every day matter more than the ones on the roadmap.

You should get the audit in writing, and keep it whether or not you hire whoever wrote it.

Stabilise before you build anything new

Once you know what you have, resist the urge to add the feature that was due last month. First, stop the bleeding:

1. Backups, automatic, and tested by restoring one.
2. Monitoring, so you hear about errors before customers do.
3. The fixes that stop data or money leaking: security holes, double payments, broken records.
4. A repeatable deployment, so a fix can go live in minutes, not after a day of manual steps.

On Beyut Libya, the hand-updated server became Docker containers shipped through a CI/CD pipeline, with Redis, background job queues and Grafana monitoring, and only then did we connect Tadawul, the Libyan payment gateway the client had originally asked for.

Fix it or replace it?

This is the big decision, and it shouldn't be made on instinct. These signs usually decide it:

What the audit finds	Usually means
The data model is sound; the code around it is messy	Fix and refactor in place
Every fix breaks something unrelated	Rebuild the worst parts first, keep the rest
The framework or language is no longer supported	A planned rewrite, moved over module by module
The vendor owns the code and won't hand it over	Replace the system, carrying the data across
Nobody can deploy it safely	Fix deployment first, then decide on the code

The Gman tailoring platform came to us as a PHP and Vue application with severe performance problems that had become impossible to maintain; every business change needed a developer. We mapped every business process into a written specification, then rebuilt it. It now responds about 70% faster, and the client changes business settings without calling a developer.

Sometimes there's no code to fix at all. The trust eye hospital behind EHMS had software from a well-known vendor who would neither update it nor fix its issues. The owner lives in the UK and had a month before flying back. We built a replacement in six weeks, moved the running data and the staff across on site, and the hospital didn't close for a single day.

Switching over without stopping the business

Replacing a system that people use every day is mostly a people problem.

• Plan around the work, not the code. Learn which days are busy and which reports someone needs on the first of the month.
• Move the data yourself, and check it. Compare totals with the old system: balances, open invoices, stock, patients on the ward. A script copies rows; only a person can confirm the cheque book still adds up.
• Be there on go-live day. At the hospital, we put the staff onto the new system in person.
• Keep the old system readable for a while, so nobody panics when they need last year's record.

How to avoid doing this again

• Own your accounts from day one: domain, hosting, repository, stores, payments.
• Put IP ownership in the contract, with the code assigned to your company as it's written.
• Ask for a working demo every week. A team that shows you running software every week can't drift for months without you noticing.
• Insist on basic documentation: how to deploy, where the data lives, which services it depends on.
• Watch for the warning signs: missed demos, vague answers about where things run, reluctance to give you repository access.

If the project that stalled was built with an AI tool such as Lovable, Bolt or Replit, read our guide to vibe-coded app rescue. For a full worked example, see how we took over a real estate app that several vendors left broken. If you decide to replace the system, custom ERP development cost and our cost estimator show what that usually costs.

Common questions

My developer disappeared. What do I do first? Secure access to everything the software depends on: domain, hosting, database (with a fresh backup), code repository, app stores and payment accounts. Then get a written audit before deciding anything else.

Can a new team take over code someone else wrote? Yes, as long as you can give them the code and access to the servers and accounts. A good team reads it first and tells you honestly what they find.

Should I rewrite my failing software from scratch? Not automatically. If the data model is sound, fixing in place is usually faster and cheaper. Rewrite when the foundation itself is the problem, and then move over part by part.

What if the old vendor won't give me the code? Check your contract for IP ownership. If you can't get it, the data is what matters most: get a full export, and plan a replacement that carries it across.

How long does a software rescue take? The audit takes days. Stabilising usually takes a few weeks. A replacement depends on scope; our hospital replacement went live in six weeks.

If you're in the middle of this, tell us what's happening. We'll start by reading what you have and telling you plainly where it stands. More on how we work: software rescue and modernization.