If Your Developer Disappeared Tomorrow, What Would Be Portable?

Every so often a call comes in that starts the same way. The website is down, or the online store has stopped taking orders, and the business can’t reach the person who built it. Emails bounce, the phone rings out, and nobody in the office is sure where the site is hosted.

Then the questions get harder. The domain name turns out to be registered in the developer’s own name and renewed on their personal card. The code exists on the server and, presumably, on a laptop somewhere. The payment gateway, the email service and the Google account that holds the analytics were all set up under the developer’s email address because it was quicker at the time.

The business paid for every part of that work and has no way to hand any of it to someone else.

Is it a problem if only your developer has access?

Not in itself. For several of our clients, we’re the only organisation with access to their code repositories, and that suits them, depending on the nature of the engagement. Most businesses don’t want to manage a repository, and plenty would rather not have to.

There’s often a practical reason for it as well. Where a developer looks after an application under a warranty or support arrangement, they answer for the work they delivered, and most warranties, ours included, don’t cover changes made by anyone else. A fix applied straight to the server by another contractor, or a plugin added outside the agreed process, can break something in the developer’s work without them knowing it happened. Holding the access is how the developer can stand behind the system.

Neither arrangement is right for everyone, and each case is different. The business should know how its own arrangement works and why, including who holds access, what the warranty or support terms cover, and what would happen if the relationship changed. The thing to check is whether the setup is portable, meaning the business could, if it ever needed to, move the whole thing to another team without starting again.

A portable setup is one that another competent team could take over within days. The code sits in a repository with its history, the accounts the site depends on are registered to the business, the credentials are stored somewhere more than one person can reach, and there’s enough written down for someone new to deploy a change and know what each part does. The agreement matters too. Some arrangements transfer ownership of the code to the client, and others license it while the developer keeps ownership. Either can suit the engagement. A licence can also set limits on what another team may change without the original developer’s involvement.

What needs to be portable?

The list is longer than most people expect, because a modern website or system depends on more than its own code.

The code, in a repository. Kept in a version control service such as GitHub or Bitbucket, with its full history, and not only on the live server or one person’s computer. That includes the parts that aren’t strictly code: configuration settings, scheduled jobs, and the scripts that build and deploy it.

The domain name. Registered with the business as the registrant, in an account the business can log into. For a .com.au, the registrant should be the business itself, identified by its ABN or ACN, rather than the person who set it up. The domain controls both the website and email, so losing it does more damage than losing almost anything else on this list.

Hosting and cloud accounts. Either in the business’s name, or held by a provider that’s documented and willing to transfer them. Someone should know which company hosts the site and who pays the bill.

The services around the site. Payment gateways, email sending services, mapping and search keys, analytics, Search Console and any other service the site calls. For mobile apps, the Apple and Google developer accounts matter a great deal: an app published under a developer’s personal account is a fiddly and slow thing to move.

Credentials. Kept in a password manager rather than a text file, an email thread or someone’s memory, with an agreed way for the business to get them when it needs them.

Documentation. A few pages, kept current, covering where everything runs, how a change gets deployed, what each outside service does, and any quirks a new developer would trip over. It doesn’t need to be a manual.

Backups. Stored somewhere other than the server they back up, with a restore tested recently, because plenty of backups turn out to be incomplete the first time anyone needs one.

Licences. Paid plugins, fonts, components and themes, licensed to the business or transferable to it, so the next team doesn’t inherit software it isn’t entitled to update.

Why is a one-person setup riskier?

Plenty of excellent work is done by freelance developers and designers working on their own. The risk comes from the structure, whatever the quality of the work. When one person holds everything, the business’s access to its own systems depends on that person being available, and people get sick, take holidays, change careers and occasionally just stop replying.

Nobody sets out to create that risk. It accumulates when one person does everything quickly, which is usually what the client asked them to do. Setting up an account under your own email takes two minutes, and transferring it to the client is a job for later that never quite arrives. There’s no second person to notice, so the shortcuts stay where they were made. The same goes for small studios where one developer built the system and nobody else there has worked on it. Insurers and lenders call this key-person risk, and it applies to websites as much as to anything else a business depends on.

It’s closely related to the risk we described in Building on Someone Else’s Land, although a platform that changes the rules usually sends a deprecation notice first, which is more warning than a business gets when its developer moves on.

How does an established studio handle it?

Code Brewery has been building websites and software for more than twenty years, and over that time the structures that make work portable have become routine.

Access to a client’s systems sits with the studio rather than with any one developer, and more than one person on the team knows each system well enough to work on it. Credentials live in a managed vault. Deployments are scripted and documented, so a change goes live the same way whoever makes it. When someone leaves the team, their access ends that day. Where we set up domains and outside services, they’re registered to the client.

Handover is a defined piece of work as well. Clients build their own development teams, restructure, or become part of a group with its own technology people. When that happens, handover follows the terms of the engagement, including whether the code was licensed or transferred and the account being settled, and it covers the repository, the credentials and the notes the next team needs. A business that inherits a system without any of that faces a much bigger job, and moving a site and its data becomes a project in its own right.

What should a business know about its own arrangement?

These questions are worth being able to answer about any website or system the business depends on. Several can be answered from your own records and the agreement you signed.

Where is the code kept, and who has access to it?

What does the agreement say about ownership, warranty and handover?

Whose name is the domain registered in, and who receives the renewal notices?

Which outside accounts does the site depend on, and which of them are in the business’s name?

If the person who usually looks after it were unavailable for a month, who could deploy an urgent fix?

When was a backup last restored as a test?

A developer with good structures in place can help with any of these without needing to go and find out. If some of the answers are “we’d have to check”, that tells you where to start. None of it needs to be fixed in a hurry, and most of it is an afternoon’s work for whoever already has the access. It’s much easier to arrange while everyone is still answering the phone.

For a business weighing up a new system, portability belongs in the brief from the beginning, alongside the features. It’s part of what we cover when scoping custom software development, and it’s worth raising with any developer before the first line of code is written.

Simon Paul is a Business Solutions and Technology Specialist at Code Brewery who’s spent 25+ years turning business ideas into software that actually earns its keep. He has spent more afternoons than he’d like tracking down domain registrars for businesses whose developer had moved on. Reach out to Simon to check how portable your website or system is today.