What happens to your software if the agency that built it disappears

Agencies close, get acquired, lose the one developer who understood your system, or simply stop replying. If the software running your business is on the other side of that, you find out how much of it existed only in someone else's head. The good news is that this is entirely preventable, and it is decided at commissioning rather than at the point of disaster.

The four things that decide whether you are stuck

Who owns the code. Ask, get the answer in the contract, and be clear this is not standard. Plenty of arrangements leave the agency owning what you paid for, licensing it back. That is a legitimate model if you know you are in it, and a nasty surprise if you do not.

Where it runs. If the hosting is on your agency's account, under their billing, with their credentials, then your system lives at their pleasure. Hosting should be in accounts your business owns, with your agency given access rather than ownership.

Where the code lives. It should be in a repository your business controls, with the agency as a collaborator. If the only copy is on the agency's machines, you are one dispute or one hard drive away from having nothing.

Whether anyone else could pick it up. This is the one that gets skipped, because it is invisible while things are fine. It means boring, common technology rather than something clever and obscure, sensible documentation, and automated tests that tell the next developer whether they have broken something.

The uncomfortable question to ask

Ask any agency you are considering: "If we fell out tomorrow, what exactly would I walk away with, and how long would it take another developer to get productive?"

The answer tells you almost everything. A good agency answers immediately and specifically, because they have thought about it and it is a normal part of doing this properly. An evasive answer is itself the answer.

Why "boring technology" is the important bit

There is a real temptation, particularly on smaller budgets, to use whatever framework is fashionable, or the tool that generates the most code fastest. It ships quicker and it is worse for you.

The question is not whether the technology is good. It is how many developers in your region will be comfortable with it in five years. Common, well-supported choices mean the pool of people who can maintain your system is thousands rather than five, and that pool is the thing that protects you.

We choose deliberately dull technology for exactly this reason. It is not the interesting answer, and it is the one that means a system built years ago is still straightforward to work on, which is what has let us keep growing one client's operating platform over several years as the business changed around it.

Continuity is not the same as never leaving

Nobody should promise you they will be around forever, and you should be wary of anyone who frames the relationship that way. The realistic goal is that your system does not depend on any single company remaining in business, including ours.

In practice that means the four things above are true from day one rather than negotiated at the end, and it means ongoing support is an arrangement you choose to renew because it is working, not a hostage situation you cannot exit.

The five-minute audit of software you already own

If you have a system somebody else built, check these today. It takes an afternoon and it is worth doing before you need to know.

1. Can you log into the hosting account yourself, without asking anyone?
2. Do you know where the code is, and can you get to it?
3. Is the domain registered to your business rather than your agency?
4. Do you have a copy of the database from the last week, somewhere that is not the live server?
5. Could you describe, roughly, what the system does, without the agency in the room?

Two or more noes is worth fixing regardless of how happy you currently are with whoever built it, because everything on that list is easy to fix while the relationship is good and painful once it is not.

What we do about it

Code in a repository the client's business owns. Hosting in accounts they control. Documentation written for the developer who is not us. Technology chosen because it is well understood rather than because it is interesting.

None of it stops us being useful, and all of it means the client stays because the work is good. If you are commissioning something and want it set up that way, tell us what you are trying to build, or read how we work first.