Three versions of this: the agency stops trading, the agency stops caring, or the one person who understood the system leaves. The first is rare. The second and third are common.
The outcome depends almost entirely on decisions made at the start of the project, when nobody is thinking about it.
The honest test
Answer these now. Each is a yes or a no.
- Do you have the source code, in a repository you control, right now?
- Does your contract assign the IP to you, and has the trigger been met?
- Is the hosting in your accounts, on your billing?
- Do you hold the domain and DNS?
- Do you have deployment instructions another developer could follow?
- Do you have a list of third-party services and the credentials?
- Could a competent developer who has never seen it understand the architecture from documentation?
- Has anyone other than the original developer ever deployed it?
Six or more yes: you are in reasonable shape. A new supplier takes weeks.
Three to five: recoverable but expensive. Expect months and significant cost.
Two or fewer: you do not have a software asset. You have a dependency on a specific company continuing to exist and continuing to want your business.
The three scenarios
The supplier stops trading
Rarer than people fear, and the cleanest of the three if you prepared.
If you hold everything: inconvenient. New supplier, ramp-up period, done.
If they hold the code: it becomes an asset in an insolvency process. Administrators have a duty to creditors, not to you. Getting a copy may be possible, may cost money, and may take months you do not have. Nobody is obliged to help you.
If they host it: the clock is the hosting bill. When it goes unpaid, the service stops. Businesses have lost systems this way with no warning.
The supplier stops caring
The most common scenario by a distance. Nobody disappears. Response times stretch from hours to days to weeks. Your work is deprioritised for larger clients. Quotes for small changes become strangely expensive.
This is not malice. It is a small firm with finite capacity allocating it rationally. Your project is no longer the one that matters.
You cannot fix this with a contract. You fix it by being able to leave — which means holding everything in the list above. A supplier who knows you can leave behaves differently from one who knows you cannot.
The one person who knew it leaves
The quietest and most dangerous version. The firm continues. The individual who held the whole system in their head goes to another job.
What follows: the remaining team is cautious with code they do not understand. Estimates rise. Small changes take surprisingly long. Nobody says the word “rewrite” for about eighteen months.
Prevention is documentation and more than one person having deployed it. Ask your supplier directly: “How many of your people have deployed this system?” If the answer is one, that is your risk, inside their business.
The repository question, specifically
Of everything on this page, one action removes most of the risk, and it costs nothing.
Create the repository under your own organisation account, and add your supplier to it.
GitHub, GitLab and Azure DevOps all offer free organisation accounts. Create one in your company’s name, with your email, and invite your developer as a collaborator.
What this changes:
- You hold the code continuously, from the first commit, rather than hoping for it at handover
- You can revoke access; they cannot lock you out
- You can see activity — commits, frequency, who is actually working on it
- If the relationship ends abruptly, nothing needs to be requested
- A new supplier can start reading on day one
The cost: nothing, and about twenty minutes of setup.
What to do if a supplier objects. Listen to the reason — some are legitimate, such as needing a particular toolchain or CI configuration. Those are solvable. What is not legitimate is an objection in principle to the client holding their own code. Nothing about normal development requires the supplier to own the repository, and a firm that insists is telling you how the relationship ends.
If you are mid-project and this was not done: ask now. Most suppliers will transfer or mirror the repository without resistance, because for most of them it was never a deliberate strategy — it was just how they set it up.
What to have in place
During the project, not at the end
Source code in your repository from week one. Create the GitHub, GitLab or Azure DevOps organisation under your account and add your supplier to it. This costs nothing, is completely normal, and means you hold the code continuously rather than hoping for it at handover.
A supplier who objects to this is telling you something important.
Infrastructure in your accounts. AWS, Azure, Google Cloud, or whatever hosting — opened in your company’s name, on your billing, with your supplier granted access. Access can be revoked. A supplier’s account cannot be taken over.
Domain and DNS under your control. Registered to your company, in your registrar account. Domains held by agencies are a recurring and entirely avoidable source of trouble.
Third-party services in your name. Payment processor, email service, SMS, maps, storage. Your accounts, your billing, your ownership of the data.
In the contract
- Present assignment of IP, triggered on final payment — “are hereby assigned”, not “shall assign”
- Handover contents specified in full — source, documentation, deployment instructions, credentials, dependency list
- A notice period, so disengagement is orderly
- A defined handover obligation on termination, including a reasonable support window
As a deliverable
Documentation a stranger could use. Specifically:
- What the system does and how the main pieces fit together
- How to set up a development environment from nothing
- How to deploy, step by step
- Every environment variable and configuration setting, and what it does
- Every third-party service and what it is for
- Known limitations and anything deliberately left undone
The real test: could a developer who has never seen this project get it running locally using only the documentation? Ask your supplier to prove it with someone from their own team who has not worked on it.
Source code escrow
A third party holds a copy of the source, released to you on defined events — usually insolvency or sustained failure to support.
Worth it when your supplier hosts the system, or will not assign IP, or the software is genuinely business-critical and you have accepted a dependency commercially.
Largely unnecessary when you already hold the source in your own repository and run your own infrastructure. Escrow solves a problem that proper arrangements prevent.
If you use it: verify the deposit is current. An escrow holding a version from two years ago is close to worthless, and stale deposits are common.
Cost: typically a few hundred to a couple of thousand pounds a year.
If it has already happened
1. Secure what you can access, today. Download the source if you can reach it. Export your data. Note every service you can still log into. Access can be withdrawn without warning.
2. Check who holds the domain. Look up the WHOIS record. If it is your agency, move it to your own registrar immediately if you still can.
3. Check the hosting billing. If the card on file is theirs, the system stops when it stops being paid. Move billing to you as a priority.
4. Read the contract. Look for “intellectual property”, “assignment”, “deliverables”, “termination”, “handover”. You may have rights you have not used.
5. Ask directly and in writing. Many handovers are refused informally and granted when requested formally. Put the request in an email.
6. Get a technical assessment. A second developer can tell you within a day or two whether the system is maintainable, whether documentation exists in the code, and what rebuilding would cost. Pay for this before deciding anything.
7. Take legal advice if the sums are significant. Especially where there is no assignment clause.
The quiet version: when a supplier stays but stops caring
The common scenario, and the one nobody plans for because it has no single moment of failure.
How it progresses: replies move from hours to days. Quotes for small changes become oddly expensive. Your work is scheduled behind larger clients. Nothing is said, and nothing is wrong enough to complain about.
Why it happens: a small firm with finite capacity allocating it rationally. A client spending £2,000 a year sits behind one spending £60,000. That is not malice; it is arithmetic, and most suppliers would say so if asked directly.
What does not fix it: a stronger contract. Response times in an agreement are enforceable in theory and nobody wants to litigate over a three-day delay.
What does fix it — leverage, in two forms:
The ability to leave. Hold the source, the infrastructure and the documentation, and the relationship stays voluntary. A supplier who knows you can leave behaves differently from one who knows you cannot. This is the real argument for everything else on this page.
A commercial relationship worth maintaining. A retainer, even a modest one, makes you a recurring client rather than an occasional interruption. Ad-hoc clients are always scheduled last, everywhere.
What to do when you notice it: raise it directly and early, as a conversation rather than a complaint. “We’ve noticed responses taking longer — is our arrangement still working for you?” Suppliers frequently say yes and fix it, or say no honestly, and both answers are more useful than waiting.
Ask every supplier this
Before you sign, ask all of these. The answers vary far more than you would expect.
- “Can the repository be under our account from day one?”
- “Will the hosting be in our accounts, on our billing?”
- “Does the contract assign IP to us, and when?”
- “What exactly is in the handover documentation?”
- “How many of your team can deploy this?”
- “If we moved to another firm next year, what would that look like?”
That last one is the most revealing question in the list. A supplier who answers it comfortably has designed for it. A supplier who becomes uncomfortable has designed against it.
Getting a technical assessment
Before deciding whether to continue, rebuild or move, pay someone independent to tell you what you actually have. One to two days, typically £800–£2,000, and it is the best money in the whole situation.
What it should cover:
Can it be built and run from scratch? The single most important question. If a competent developer can clone the repository and get it running locally using the documentation, you are in good shape. If it only runs on one machine or one server nobody can reproduce, that is the finding.
Is there any documentation? Including in the code itself. Comments, README files, architecture notes.
What is it built on, and is any of it unsupported? Frameworks and libraries that have reached end of life are a cost you will meet soon regardless.
Are there tests? Not whether coverage is high — whether changing something would be detectably safe or a leap of faith. This dominates the cost of every future change.
How bad is the code, honestly? Not stylistically. Structurally: is it comprehensible, or is it going to take someone three weeks to understand before they can make a one-day change?
Any obvious security problems? Credentials in source control, unpatched dependencies, missing authorisation checks.
What would continuing cost versus rebuilding? The number you actually need.
Who to ask: a development firm with no stake in the answer, ideally one you are not planning to hire for the work. Be explicit that you want an assessment, not a pitch.
The one-page continuity record
Keep this current. It takes twenty minutes and it is what someone needs if you are unavailable.
- Repository — where it is, who owns the account, who has access
- Hosting — provider, account owner, billing card, who can log in
- Domain — registrar, account owner, renewal date
- Third-party services — each one, what it does, whose account it is on
- Supplier — company name, company number, named contact, contract location
- Deployment — where the instructions live
- Last backup — what, where, when it was last tested by restoring
Store it somewhere that is not inside the system it describes, and tell more than one person where it is.
Frequently asked questions
What happens to my software if my development agency goes bust?
If you hold the source, the IP and the infrastructure, you hire someone else and continue. If the agency holds them, the code becomes an asset in an insolvency process and you may have no practical route to it.
How do I protect myself before it happens?
Source in your own repository from week one, infrastructure and domain in your accounts, present IP assignment in the contract, and documentation a stranger could follow. All four are free or near-free if arranged at the start.
Is source code escrow necessary?
Only when your supplier hosts the system or will not assign IP. If you already hold the source and run your own infrastructure, escrow is solving a problem you do not have.
What if only one developer understands my system?
That is a real risk and it sits inside your supplier’s business. Ask how many of their people have deployed it, and make documentation an explicit deliverable rather than an assumption.
My agency has stopped responding. What now?
Secure access to everything you can reach today, check who holds the domain and the hosting billing, read your contract, and make a written handover request. Then get a second developer to assess what you actually have.
Can I force an agency to hand over source code?
It depends entirely on your contract. With a present assignment clause and a met trigger, your position is strong. Without one, you likely hold an implied licence and the position is far less clear. Take legal advice.
How much does it cost to take over someone else’s software?
A ramp-up of two to six weeks is typical for a documented system. Undocumented systems can cost a substantial fraction of a rebuild. A technical assessment of a day or two will tell you which you have, and is worth paying for before you decide anything.
Written by Jas Singh. Last updated 8 October 2026. General information, not legal advice.
