What happens if your software developer goes bust, and how to protect your project

What happens, by type of failure

"Gone bust" covers several different legal events, and each plays out differently for a client. In all of them the key question is the same: is the code, and everything needed to run it, already yours?

This is a practical guide, not legal advice. If your supplier has entered an insolvency process, speak to the insolvency practitioner handling it and, for anything important, a solicitor.

Administration: the business may change hands with your project in it

In administration, an administrator takes control of the company with the aim of rescuing it or selling its business as a going concern. A moratorium stops creditors taking legal action against the company without the administrator's consent or the court's permission.

For a client, three things can happen. The administrator keeps the team working while looking for a buyer, and your project carries on, often slowly. The business is sold, sometimes in a pre-pack agreed before the administration starts, and your contract moves to the new owner, possibly on new terms. Or the administrator decides your contract is not worth continuing, and the team stops.

In practice, developers start leaving as soon as the future looks uncertain. Even when the contract continues on paper, the people who knew your code may be gone within weeks. That is why the knowledge needs to live in documents and a repository you control, not only in people's heads.

Liquidation and dissolution: the code becomes a company asset

In liquidation, a liquidator winds the company up and disposes of its assets for the benefit of creditors. Staff are usually let go at once, and the liquidator can disclaim onerous contracts under section 178 of the Insolvency Act 1986. Do not expect the project to be finished.

Here ownership becomes decisive. If copyright in your code was never assigned to you, it belongs to the company, and the liquidator's job is to deal with company assets. You may have to negotiate for your own code, and someone else may acquire it first.

If a company is dissolved while it still owns property, that property becomes bona vacantia and passes to the Crown under section 1012 of the Companies Act 2006. Unassigned copyright in your system would then sit with the Crown, and getting it back means dealing with the Bona Vacantia Division or applying to restore the company. Neither is quick.

A freelancer who simply disappears leaves you in a similar place: they still own the code, and you cannot get their permission to change it. If a sole trader is made bankrupt, their property, including copyright, passes to a trustee in bankruptcy.

Who owns the code: the four questions that decide what you lose

When a project has to be taken over from a failed supplier, the outcome depends almost entirely on four questions.

Four yeses and a supplier failure is an inconvenience. Four nos and it can mean starting again. All four take an afternoon to arrange at the start of a project, and our guide to software development contracts in the UK covers the clauses that make them binding, including assignment on creation so the code is yours at every stage.

Repository, hosting, domain and cloud accounts in your name

A contract tells you what you are entitled to. The accounts decide what you actually have on the morning the supplier stops answering. Even with a perfect IP assignment, recovering code held by a company in liquidation takes time. Code already in your account takes none.

This is why our rule is that the repository, hosting and third-party accounts are in the client's name from day one, hosted in UK or EU regions, with code pushed to the client's repository every day. It is set out on our how we work page. It protects clients from us, which is exactly the point.

Credentials and handover documentation

Owning the code is necessary but not sufficient. A new team also needs to know how to build it, run it and change it without breaking anything. That knowledge should be written down as the project goes, not promised for the end. A complete handover pack contains:

• Setup instructions that take a new developer from a clean laptop to a running copy of the system.
• Architecture notes: the main components, how they talk to each other and why key decisions were made.
• Environments: development, test and live, where each one runs and how they differ.
• Deployment: an automated pipeline anyone with access can run, not a script on one person's laptop.
• Backup and restore: where backups go, how often, and a restore that has actually been tested.
• Third-party services: every API and service the system depends on, and which account it sits in.
• Credentials: every admin login and API key in a shared password vault that you control.
• Known issues and work in progress, so nobody rediscovers the same bug.

Rotate credentials whenever someone leaves the project. A vault you own means rotation takes minutes, and nobody outside your company holds the only copy of a password.

Source code escrow: what it is and when it helps

Source code escrow is a three-party agreement between you, the supplier and an independent escrow agent. The supplier lodges the source code, and usually build instructions and documentation, with the agent and updates it at agreed intervals. If a release event happens, typically insolvency or a failure to support the software as agreed, the agent releases the material to you.

• Verification is what makes escrow useful. Without it you may receive an out-of-date or incomplete copy. Levels range from a check of the files lodged to a full test that the code builds and runs.
• SaaS escrow is a newer form for software you use online but never host. It can include access to the hosting environment so the service keeps running while you make other arrangements.
• Release events need careful drafting: insolvency, ceasing to trade and failing to meet support obligations are the usual ones.

When escrow helps: when you rely on software you license but do not own, such as a specialist vendor's product or a business-critical SaaS platform, and switching would take months. When it adds little: for bespoke software where copyright is assigned to you and the code is pushed to your own repository every day. You already hold more than any escrow copy, and what you need instead is good documentation and a tested way to deploy it.

Checklist: protect yourself from day one

1. Contract assigns copyright and all IP in the deliverables to your company, in writing and signed, on creation.
2. Background IP licensed to you permanently and transferable with the software.
3. Repository created in your company's account before the first line of code; supplier invited as a collaborator.
4. Code pushed at least daily, not "at the end of each milestone".
5. Cloud hosting account in your company's name, with your own admin login.
6. Domain registered to your company, with your login at the registrar.
7. App store developer accounts in your company's name.
8. Third-party services (Stripe, Twilio and so on) in your accounts, keys shared with the supplier.
9. A shared password vault you control, with every admin credential in it.
10. Documentation delivered as you go: setup, deployment, backup and restore.
11. Automated deployment that another team could run.
12. A second developer who knows the code, or at least reviews every change.
13. A right to terminate on the supplier's insolvency, with handover obligations.
14. For licensed software you do not own, a verified escrow agreement.

Items 3 to 9 take an afternoon at the start of a project. They are the difference between a bad week and a lost system.

Warning signs a supplier is in trouble

One sign may be nothing. Several together mean you should quietly check that you hold everything on the checklist above, today, while the supplier is still cooperating.

The first 48 hours

When a supplier fails, speed matters more than anything else. Systems keep running for a while on momentum, and the window to secure access is usually short. In the first two days:

1. Confirm the facts on Companies House and The Gazette, and find the name of the insolvency practitioner.
2. Log in to every account you own: repository, hosting, domain registrar, app stores and third-party services. List anything you cannot reach.
3. Take a full copy of the repository and a fresh database backup into storage only you control.
4. Check the domain and SSL certificate expiry dates, and that backups and monitoring are still running.
5. Rotate passwords and API keys the supplier's staff held, once you are sure you can keep the system running without them.
6. Freeze deployments. Nobody should push changes to live until you know who is responsible for them.
7. Tell your own team and key customers what is happening, and who to contact if something breaks.

If the system is live and something is already failing, call us on 020 7096 2842. A senior developer can help you secure access and keep the system up while you work out the next step.

How a rescue team takes over

Once access is secure, write to the administrator or liquidator setting out your contract and what you need: code, documentation, credentials and data. If the IP was never assigned, ask whether it can be assigned to you, and take legal advice. Former developers can sometimes give a handover session, arranged through the practitioner.

Taking over someone else's code is normal work for an experienced team, but it should start with an audit, not a promise to finish. A software project rescue usually begins with one to two weeks of review that answers:

• Does the code in the repository build, and does it match what is live?
• How much of the specification is done, and to what standard?
• Are there automated tests, and do they pass?
• Are dependencies current, and are there known security issues or secrets stored in the code?
• Is the data model sound, and is production data safe and backed up?

If you have a running system but nobody to look after it, a support and maintenance plan keeps it patched, monitored and backed up while you decide what comes next.

Choosing a supplier with this in mind

No supplier can promise never to fail, and size is not the protection it looks like: large firms enter administration too. The protection is in how the project is set up. Ask where the repository will live, whose name the hosting will be in, how often code is pushed, who else knows the code and what the handover pack will contain. A supplier comfortable with all of that will be safe to work with whether or not it is around in ten years.

That is the standard we think the UK's leading software development companies should be held to, and it is how we run every project: the client owns all code and IP, the repository and hosting sit in the client's name from day one, and a senior UK team demos working software every two weeks. For the rest of the decision, read how to choose a software development company, or tell us about your project and we will reply within one working day.

Questions