A software project rescue starts by securing your code, hosting and accounts, followed by a one to two week code audit that grades the system area by area. Stabilisation then takes 4 to 8 weeks: monitoring, tests on the critical paths, a proper release pipeline, urgent bugs fixed and hosting moved into your name. Only then do we recommend fixing, finishing or rebuilding, with the evidence in writing.
Signs a software project is failing
Projects rarely fail in one dramatic moment. They drift, and the signs are visible months before anyone says the word. If three or more of these sound familiar, it is time for an independent look at the code rather than another status meeting.
- Every release breaks something that used to work. This usually means there are no automated tests, so nobody can change one part safely without checking everything by hand.
- You have not seen working software for over a month. Screenshots and progress percentages are not the same as a test link you can click through.
- Only one person can deploy. If the release process lives in one developer's head or laptop, you have a single point of failure, not a product.
- You do not have the code. The repository sits in the supplier's GitHub, Bitbucket or Azure DevOps account and you have never been given access.
- Tickets stay open for weeks. The team is always busy, yet the list of open issues never gets shorter, and simple questions about backups or which version is live get vague answers.
None of these prove the code is bad. But they do mean you are making decisions without evidence, which is the thing a rescue fixes first.
Getting your code, credentials and accounts back
Before anyone can audit or fix anything, you need control of what is yours. This is the most urgent part of taking over a software project, and it is easier while the old supplier is still talking to you. We help you ask for everything in one written request.
The handover list we send
- Source code: the full Git repository with history, not a zip of the latest files.
- Hosting: admin access to AWS, Azure, Google Cloud, DigitalOcean or whatever runs the live system, ideally transferred into an account in your company's name.
- Domain, DNS and data: the registrar login, wherever DNS is managed (such as Cloudflare), and a full database backup.
- Third-party services: Stripe, GoCardless, Twilio, SendGrid, Google Maps, Xero or Sage app credentials, and any API keys the system depends on.
- App store accounts: Apple Developer and Google Play Console access if there is a mobile app.
- Everything else: environment variables, build scripts, Figma files, documentation and the list of known bugs.
If the supplier will not cooperate
Check your contract for the intellectual property clause first. If it assigns the code to you, a solicitor's letter usually ends the argument. If the contract is silent, the supplier may own the copyright by default under UK law, which is why we explain this in our guide to who owns the code in a software development contract. If the supplier has stopped trading, the administrator or liquidator controls the assets, and our guide on what happens when your software developer goes bust covers the steps.
Security triage in the first fortnight
A supplier leaving on bad terms still holds the old passwords. So before the audit proper, we close the obvious doors.
- Rotate every secret. Database passwords, API keys, cloud access keys, SSH keys and admin logins are all replaced the moment you have control, and the old ones revoked.
- Review who has access. We list every user on the hosting account, repository, domain registrar and third-party services, and remove anyone who should no longer be there.
- Look for signs of misuse. Unusual logins, unexpected admin accounts and changed files on the server are checked against whatever logs exist.
- Check where personal data lives. Copies of the live database on laptops, test servers or shared drives are a common finding, and each one is a risk under UK GDPR.
- Monitoring goes in first. Error tracking with Sentry, uptime checks and structured logs, so we can see what breaks and how often before we change anything. Many teams have been fixing blind.
- Tests that pin down current behaviour. Before changing a tangled piece of code, we write tests that record what it does today, right or wrong. Then every change is checked against them.
- Small releases with a way back. Changes ship in small batches through an automated pipeline, with the previous version ready to restore in minutes if something goes wrong.
- Feature flags for risky changes. A rewritten checkout or calculation can be switched on for staff first, then a few customers, then everyone.
- Careful database changes. Schema changes are written as versioned migrations, tested against a copy of live data and designed so the old and new code can run side by side during a release.
- A freelancer who has gone quiet. Often the code is reasonable but undocumented, with everything in one person's head. The hard part is recovering accounts.
- An offshore team with high turnover. Each developer has added their own style, and there may be three ways of doing the same thing. We look for the shared core worth keeping and standardise around it.
- A no-code or low-code build that hit its limits. Bubble, Airtable, Power Apps or a heavily customised Zapier setup that worked for 10 users and creaks at 100. The job is a planned move to proper code, carrying the data and workflows across.
- The code lives in a repository in your account from day one, and the supplier works in it.
- Hosting, domains and app store accounts are in your company's name, with the supplier added as a user.
- You see working software on a test link every two weeks, not progress reports.
- The contract assigns intellectual property to you, and progress is measured in delivered, demonstrated features.
- There is a written runbook explaining how to build, deploy and restore the system.
If we find evidence that personal data has been exposed, we tell you the same day. Under UK GDPR a reportable breach must go to the ICO within 72 hours of you becoming aware of it, so speed matters. Our wider approach to protecting live systems is on the security page.
The code audit checklist we work through
A code audit is a written assessment of what you actually own. It takes one to two weeks for most business systems and answers one question: is this a sound base to keep building on? These are the checks behind that answer.
| Check | What we look for | Why it matters |
|---|---|---|
| Builds from scratch | Can a new developer run it locally from the README in under a day? | If not, every future change is slow and risky |
| Automated tests | Test coverage of the paths that handle payments, bookings or customer data | No tests means every fix needs full manual retesting |
| Dependencies | Framework and library versions against their end-of-life dates, plus known vulnerabilities | Old versions stop getting security fixes |
| Security basics | Secrets committed to the repo, password hashing, access checks on every request, the OWASP Top 10 | The most common route to a data breach |
| Data model | Database structure, missing constraints, duplicated or orphaned records | Bad data outlives bad code |
| Architecture | Is business logic in one place or copied across screens and scripts? | Duplication multiplies the effort of every change |
| Deployment | Repeatable releases, separate test and live environments, rollback | Manual deploys cause most of the outages we are called in for |
| Backups | Do they exist, where are they, and has anyone restored one? | An untested backup is a hope, not a plan |
The report grades each area red, amber or green, lists the specific problems with file references, sizes each fix and puts them in a sensible order. You can hand it to any developer. It is yours, whether or not you continue with us.
Fix, finish or rebuild: how the decision gets made
Most people arrive having already decided, either to bin everything or to save every line. The audit replaces both instincts with evidence, and there are only three realistic options.
Fix and continue
Right when the structure is sound but the delivery was poor. Typical findings: missing tests, a messy deployment, a backlog of bugs, but a sensible data model and code a competent developer can follow. This is the most common outcome.
Finish the original scope
Right when the work so far is usable and the remaining features are clear. We re-plan what is left as two-week sprints and keep what works. The key test is whether new features can be built on the existing code without rewriting the old ones first. If most of them cannot, finishing only postpones a rebuild.
Rebuild on a sound base
Right when the foundations are wrong: the data model cannot represent how your business works, the framework is out of support, or security problems run through every layer. A rebuild rarely means starting from nothing. The screens, the business rules and the hard lessons all carry over. Where the old system is still running the business, our legacy software modernisation approach replaces it module by module rather than in one big switch-over.
We put the three options side by side with timescale, risk and what each leaves you owning. Sometimes the answer is a mix: rebuild the customer-facing app, keep the back office for now.
Stabilising a live system without taking it offline
Most rescues happen on software the business is already using. Customers are logging in, orders are flowing, staff depend on it. Stopping everything for a month is not an option, so stabilisation is done in small, reversible steps.
Across 4 to 8 weeks the aim is a system that is calmer every week: fewer errors in the logs, fewer support calls and releases nobody dreads. You see the progress in a demo every two weeks, the rhythm every project at Fixology runs to.
Taking over code from freelancers, offshore teams and no-code tools
The rescues we take on tend to fall into a few patterns, and each needs a slightly different approach.
We do not criticise the previous supplier. If you are choosing who should carry the project forward, our guide on how to choose a software development company lists the questions worth asking any supplier, us included.
Making sure you never need a rescue again
Most failed projects share the same root causes, and a few rules written into how the work is run prevent nearly all of them. For a broader look at those causes, read why software projects fail.
Once a rescued system is stable, many businesses move it onto a software support and maintenance plan so somebody is watching the monitoring, applying security patches and keeping dependencies current.