What Happens When the Developer Who Built Your Software Leaves?
The developer who built your system has been great for years. They know every corner of it. Then they take a full-time job somewhere else, move away, or stop answering email.
That’s when many small businesses and public agencies find out what they actually own. Sometimes it’s everything. Sometimes the code is in the developer’s personal account, the domain is registered in their name, and the only copy of the passwords leaves with them. This article covers the risks, and what to put in place now, while your developer is still around.
Written for Owners, office managers and public-sector teams whose software was built by one developer or a small outside firm.
The short answer
- If one person is the only one who understands your software, your business depends on that person.
- Your business should own and control the code, the domain, the hosting account, the data and every password.
- Ask for documentation as part of the work, and pay for it.
- A second developer reviewing the work now costs less than a stranger working it out later.
- If the developer is already gone, secure the accounts first, then get an assessment.
The risk of one-person software
People move on. The risk comes from how the work was set up, and you can fix that while things are going well.
Engineers have a grim name for this: the bus factor. It’s the number of people who would have to be hit by a bus before a project stalls. For a lot of small-business software, that number is one.
It rarely happens dramatically. People change jobs, retire, get sick or get busy with bigger clients. None of that is anyone’s fault. But if their laptop is the only place the software can be released from, or their email is the only way into the hosting account, your business stops when they do.
One rule we hold firmly: remove single points of failure before they fail.
A software ownership checklist
Eleven things your business should control. Tick what’s true today.
0 of 11 in place
Tick each item that’s true for your business today.
Nothing you tick leaves your browser.
Source code: own it, and hold it
Source code is the human-readable recipe for your software. It should live in a code repository, an online service such as GitHub, GitLab or Bitbucket, under an account your business owns. Developers get access as members. When someone leaves, you remove their access, and the code stays with you.
Check your contract too. In the United States, work made by an outside contractor isn’t automatically owned by the client. Ownership usually has to be assigned in writing. Ask a lawyer to confirm that your agreement says the code belongs to you once you pay. (This is general information, not legal advice.) Our guide to hiring a developer, consultant or development company covers what to put in the contract.
Deployment: how changes go live
Deployment means taking a change and putting it on the live website or app. In a healthy setup, it’s automated and written down. A new developer can follow the steps, or the steps run on their own.
In a fragile setup, the only way to deploy is from one person’s laptop, using commands they remember. When that person leaves, nobody can safely change the software, and even a small fix turns into a project.
Security: who still has the keys?
When a developer leaves, their access should leave with them. That means removing their accounts and changing every password and key they knew. You can only do that if you know what all of them are, which is why a company password manager matters.
Check when the software was last updated, too. Software that nobody maintains collects known security holes over time, and attackers look for exactly that.
Documentation: the notes the next person needs
Documentation doesn’t need to be a thick manual. A few pages cover most of it: what the system does, how to set it up, how to release a change, what it connects to, and why a few unusual decisions were made.
Ask for documentation as part of every project and every major change, and pay for it. It’s far cheaper for the person who built the system to write it down than for a stranger to work it out later.
Maintenance: plan for the boring work
Software needs regular updates even when nobody asks for new features. If maintenance depends on one person remembering to do it, it stops when they leave. Agree who handles updates, how often, and how you’ll know they happened. A short monthly note is enough: what was updated, what was fixed, and anything that needs attention.
Knowledge transfer: a handover that works
If you know a developer is leaving, use the time you have. Four steps cover most small systems.
- Collect the keys
Move every account into the business’s name. Put every password in the company password manager.
- Write it down
The leaving developer writes the setup guide, the release steps and the system map.
- Work side by side
The new developer makes a few small changes while the old one is still there to answer questions.
- Prove it
The new developer releases a change alone, and someone restores a backup to a test copy.
For a small system with decent documentation, a few weeks of overlap is often enough. Without documentation, plan for longer.
If the developer is already gone
Most systems can be recovered. Go in this order.
- Secure what you can. Change the passwords you know. Contact your domain registrar and hosting company to confirm the business is the owner.
- Find the code. Look for a repository account and any shared folders. If the developer is reachable, ask politely for the code and for account access. Your contract helps here.
- Make backups. Copy the database and any files now, before anything else changes.
- Get an assessment. An experienced developer can review the code, the setup and the security, and tell you whether to keep, fix or replace it. Hold off on new features until you know what you have.
Recovery takes longer and costs more than a planned handover. That’s the best argument for working through the checklist above now.
For public-sector teams
Government agencies often rely on a contractor who built a system years ago. When the contract ends or moves to a new vendor, the same risks apply, plus public-records duties. Write ownership into the contract: the code, the data, the documentation, the accounts, and a transition plan with time set aside for knowledge transfer. Make the documentation a deliverable your team reviews and accepts, not a promise.
When to get help
You can work through the account checklist yourself. Get help when nobody left can explain the code, the software hasn’t been updated in a long time, or you need to decide whether to keep it, fix it or replace it.
Yippify takes over software built by other teams. We start with a review of the code, the deployment and the security, then explain in plain terms what’s working, what’s risky and where to start. See our modernization service for how that work runs.
Frequently asked questions
Who owns the code if I paid a freelancer to build it?
Not automatically you. In the United States, an independent contractor generally owns the copyright in what they create unless a written agreement assigns it to the client. Make sure your contract assigns the code and other work to your business on payment, and ask a lawyer to check it. This is general information, not legal advice.
What should software documentation include?
At minimum: what the system does, how to set it up on a new computer, how to release a change, what other systems and services it connects to, where the data and backups live, and the reasons behind any unusual decisions. A few clear pages are worth more than a long manual nobody updates.
How do I take over software when the developer won’t respond?
Secure what you can first: change the passwords you know and confirm with your domain registrar and hosting company that your business is the owner. Back up the database and files. Then have an experienced developer assess the code, deployment and security before anyone starts new work.
What is the bus factor?
It is the number of people who would have to leave suddenly before a project stalls. A bus factor of one means a single person holds knowledge or access that nobody else has. Documentation, shared accounts and a second person who reviews the work raise it.
Does your software depend on one person?
Tell us what the software does, who built it, and which accounts and passwords you control today. We’ll help you get control of the rest, review what you have, and plan what comes next.
- Accounts back in your name
- A plain review of the code and security
- Documentation the next person can use
A rough description is enough to start. No specification needed.