What happens to your software if your agency disappears

If your agency disappeared tomorrow, the code is not what you would lose. You almost certainly own it, and it is the most copied artefact in the whole arrangement. What you would lose is the path from that code to a running system: the deploy that only works from one laptop, the eleven environment variables nobody wrote down, and the person who knows which of the three cron jobs is load bearing.

So the question to put to a partner is not “do we own the source”. It is “if you all stopped answering email on Friday, what does Monday look like”. That has a testable answer, and you can get it in an afternoon without anybody’s permission.

The four ways an agency actually goes away

They fail differently, and only one is dramatic enough that anybody writes a clause about it.

Insolvency. Clean, in that there is a date and a letter. Also the rarest of the four, and the one nearly every continuity clause is drafted against.

Acquisition.Far more common. Nobody vanishes, the entity survives, and the engineers who know your system are reassigned to the acquirer’s larger accounts inside two quarters. The contract holds. The knowledge does not.

One person leaves.The agency’s own bus factor, which is not its headcount. In a shop of twenty, your account may still have been one senior who wrote the pipeline and configured the cloud project by hand. When they go, the firm keeps invoicing and the memory of your system walks out with them.

Drift.The most common, and the one with no legal trigger at all. Replies slow, the retainer keeps clearing, and “can you ship this by Thursday” is a scheduling problem for three months running. No letter, no date, nothing to enforce.

Drift and acquisition account for most of what people mean when they say their agency disappeared. Neither trips an escrow release condition, and neither is a breach you would want to litigate. That is the first hint that the legal instrument sold for this problem is aimed at the wrong failure.

What you actually lose, in order

Five layers sit between your source code and a system that runs. Rank your exposure on each.

1. The repository

The layer everyone checks, and the one least likely to hurt you. Git is distributed by design, so every engineer who ever cloned it holds the full history on a laptop. If this is all your contract secures, it secures the easy part.

2. The build and deploy path

Where the real risk lives. A repository tells you what the code is, not which Node version it needs, which of four deploy targets is production, whether migrations run before or after the containers swap, or that the image build fails unless a private registry token is present. That knowledge is a shell script in somebody’s home directory, or it is nowhere.

3. Configuration and secrets

API keys, webhook signing secrets, service account files, the OAuth client somebody registered under a personal developer account. Most CI systems store secrets write-only on purpose, so nobody can read them back out later, and that applies to you as well. The authoritative copy of every value is whichever password manager the agency uses.

4. Accounts and identities

The cloud organisation, the registrar, the store listings, the payment provider, and the mailbox that receives password resets for all of the above. The full inventory, one row per account with the owner of record named, is in our piece on switching development agencies and applies here unchanged. The difference is timing: a disappearance gives you no week to prepare, so the list has to be true in advance.

5. Undocumented decisions

No artefact at all. Why the queue exists. Which table is safe to truncate. What the flag called legacy_import_v2 still switches on in production, and for which customer. Escrow cannot touch this layer, documentation rarely covers it, and it is the most expensive to reconstruct because the only method is reading code and guessing.

The drill that settles it in an afternoon

Stop reading contracts and run the test. One engineer for a day, and it returns a number rather than an assurance.

Take a machine that has never touched the project. Clone the repository. Give the person the README and nothing else, and specifically no access to the agency’s chat. Ask them to get the application running locally, then deployed to a staging environment created fresh that morning. Time both, and write down every occasion they had to ask a human a question.

The list of questions is the real deliverable. Each item on it is a piece of your system that lives in a person instead of in your repository, and each one is something you can ask to have written down while the request still reads as routine. Our own working threshold, offered as ours rather than as an industry standard: a clean checkout to a running local environment should take under an hour, and a first staging deploy under a day. Past that, the pipeline has quietly become the product.

Two extensions worth the hours. Restore a production database backup into that environment and log in as a real user, because an untested backup is a claim rather than a capability. Then ask the rollback question out loud: if a deploy breaks checkout at 2am on a Saturday, name the people who can revert it and count how many are on your payroll. A distributed team sharpens the question, which is part of why working with an offshore team turns on access and handover far more than it turns on time zones.

Source code escrow, said honestly

Escrow is a three-party agreement between you, the vendor, and an agent such as Iron Mountain or Escode. The vendor deposits source with the agent, who releases it to you if a defined condition occurs. It is a real product with a legitimate use, and for most custom builds it is theatre. Four reasons, and they compound.

The release conditions do not match the failure. They are typically insolvency, formal cessation of trading, or a material breach that survives a cure period. Reread the four modes above. Acquisition does not trigger a release, because the entity is healthy. Drift does not, because slow is not a breach unless your contract went to the trouble of making it one. The clause fires on the rarest case in the list.

The deposit goes stale. Deposits refresh on a schedule, or on release, or whenever somebody remembers. What sits with the agent is a snapshot, and the gap between it and production is exactly the code written while things were going wrong.

A deposit is not a build.Source that compiles on the author’s machine and nowhere else is a legal artefact, not a working system. The established agents do sell verification as a separate and more expensive tier, from an inventory check of what was actually deposited up to a full compile and functional test in a clean environment. That tier addresses the real problem, and it is the one procurement usually declines on cost.

It holds the wrong layer. Escrow holds layer one, which was already the safe one. It does not hold your cloud organisation, it cannot practically hold live production credentials, and it does not hold the reason the queue exists.

Escrow earns its place in one shape of deal: licensed software where you do not own the source, a vendor product running on your own infrastructure, or a procurement process that requires it to sign. If the repository for your custom build already sits in your own organisation, escrow is paying a third party to hold a copy of something you can clone this afternoon.

What to demand at contract time

Five clauses. Cheap before work starts, close to impossible once the code exists and the leverage has moved.

Repository and cloud accounts in your name on day one

Not on final payment, not on project completion. The source control organisation is owned and billed by your company, with the agency added as members you can remove. The cloud project is in your account, on your card, with your root multi-factor device. This is the item worth refusing to negotiate: if the only copy of your system lives in the vendor’s infrastructure until an invoice clears, the software is collateral in a dispute you have not had yet. The same argument from the contract side, including what triggers IP assignment, is in fixed price versus time and materials.

Deploys reproducible from a clean checkout

Write it as an acceptance criterion rather than an aspiration: an engineer holding repository access and the documented secrets can build, test and deploy to staging without contacting the vendor. That turns the drill above into a contractual test somebody can fail, and it forces the work that makes it pass: a containerised build, a committed lockfile, migrations that run from a script, and infrastructure defined as files rather than as clicks in a console.

A secrets inventory that is a named deliverable

Not the values in a shared document, which is its own incident waiting to happen. A list: every secret the system needs, what it is for, which service issues it, who can rotate it, and where the authoritative copy lives. Add a rule that no production credential may be registered to a personal account, because that is how OAuth clients, push certificates and API keys end up belonging to a developer who left two years ago. Reviewed quarterly it stays true. Written once at handover it is fiction within a year.

No framework you cannot hire for

The trap is a vendor’s in-house framework, a private component library whose licence does not clearly transfer, or a code generator producing output nobody maintains by hand. Each is a hiring pool of exactly one company. The test takes ten minutes: search the job boards for the stack, in your city and remote, and count. If one half of your system is a common search and the other half returns nothing, you know which half is portable.

A written handover produced before anybody needs it

Name it as a dated deliverable, not a courtesy at the end. Architecture on one page. The runbook for a deploy and a rollback. The secrets inventory. Every scheduled job with a note on what breaks if it stops. And a decision log, the only artefact that touches layer five. Written during the work these are cheap. Assembled during an exit they are written by people who have already mentally left.

Where our own answer is uncomfortable

This is the section that costs us work, so it should be specific.

We are a small studio. Measured purely on bus factor we are a worse risk than a two hundred person firm, and no amount of documentation discipline changes that arithmetic. If the software is the business, if it carries a regulatory obligation, or if an hour of Saturday downtime costs real money, the right structure is probably one internal engineer who owns production with a studio like ours building alongside them, rather than a studio alone. Better said here than discovered with you in month seven. The three-way version of that decision is in in-house versus agency versus freelancer.

Our stack choices cut both ways too. TypeScript, Next.js and Postgres have a deep hiring pool, and picking them is a continuity decision as much as a technical one. But a workflow platform built on n8n, a content model in Payload, or a custom MCP server each narrow the set of people who can pick it up cold. Those are frequently still the right tools, and the honest statement is that they are not free on this axis.

One more concession, and it is the largest. Everything above assumes you would want to continue the system. Sometimes an agency going away is the cheapest exit you will ever be offered from software not worth maintaining, and the right response is to stop rather than rescue. How to judge a codebase you inherited is the piece for that decision, and our technical due diligence scorer asks the same questions in a form you can fill in yourself.

What any of this costs

The drill costs an afternoon, which makes it the highest return item here. The five clauses cost nothing if you ask before work starts, and they are why repository and cloud ownership sit at the top of every engagement we take.

Money enters when you want the continuity work done retroactively, on a system somebody else built. Our published bands: a scoping sprint is $3,500 for one week, credited in full against a build that starts within thirty days, which is the right size for reconstructing a deploy path and a secrets inventory on an inherited codebase. A support retainer starts at $2,500 a month, for when what you need is a second set of hands who can already deploy your system at 2am. Our minimum for a build is $7,500. Those figures are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff.

Worth saying plainly, because it argues against the paragraph above: none of that has to be bought from anyone. A contractor can run the drill, and your current agency can produce the handover inside work you already pay for. Asked while the relationship is healthy it is routine. Asked during a dispute it is a negotiation from the weaker side.

The compressed answer

The code is safe. The deploy path, the secrets and the reasons leave with the people. Run the clean checkout drill this month and count the questions. Get the repository and the cloud accounts into your own name on day one, make a reproducible deploy an acceptance criterion, keep a secrets inventory with named owners, refuse a framework with a hiring pool of one, and put the handover in the schedule as a dated deliverable. Treat escrow as a procurement requirement rather than a continuity plan, and if you buy it, buy the verification tier.

If you are already inside this and the answers came back badly, tell us what you can and cannot deploy. Taking over systems built by somebody else is part of what we do, and the first thing we run is the drill above, with the questions written where you can read them.