It usually starts with a resignation letter, or a freelancer who stops answering emails. Then comes the slower realisation: the system that runs your orders, your lab results or your field engineers was understood by one person, and that person is no longer here.
The instinct is to treat this as a recruitment problem. Find another developer, hand them the laptop, carry on. That is understandable, but it is the wrong first move.
The real problem is not the vacancy
A developer leaving does not create your risk. It reveals it. If one person's departure can put your operations in doubt, the business was already exposed; it just had not been tested yet.
That changes the question you should be asking. Not "who can we hire to replace them?" but "what do we actually have, who controls it, and what would break first?" You cannot answer the first question well until you have answered the second.
There is also a timing issue. The days after someone leaves are when you have the most leverage to recover access, documentation and context. Leave it a few months and goodwill fades, passwords expire and memories blur.
What to secure this week
Before anyone touches the code, make sure the business, not an individual, holds the keys. Work through this list:
Source code. Find out where it lives (GitHub, GitLab, Bitbucket, Azure DevOps or a folder on someone's machine). Confirm the repository is owned by a company account and that at least two people in the business have admin access.
Hosting and cloud accounts. Identify every service the system runs on: AWS, Azure, Google Cloud, a hosting provider, a database service. Check whose name and card are on each account.
Domains and DNS. Confirm who the registrant is for your domains and who can change DNS. A lapsed domain can take a system offline overnight.
Passwords and secrets. Change any shared credentials the departed developer knew, including database passwords, API keys and admin logins. Do it carefully and in a planned order, so you do not lock yourself out of something you need.
Third-party services. List the email, SMS, payment, mapping and monitoring services the system depends on, and make sure the accounts and billing sit with the company.
Backups. Find out whether backups exist, where they are stored and when one was last successfully restored. A backup nobody has tested is a hope, not a backup.
Documentation and knowledge. If the developer is still contactable and on reasonable terms, ask for a short handover session. Record it. Ask about anything fragile, any manual jobs they ran, and anything they were "meaning to fix".
If you only manage half of this list, you are still in a much stronger position than you were.
What to find out next
Once access is secure, you need an honest picture of the system itself. The useful questions are fairly simple:
What does the system do, and which parts of the business stop if it stops?
What is it built with, and are those technologies and versions still supported?
When were the server, framework and libraries last patched?
Is there anything only one person knew how to do, such as a monthly data fix or a manual deployment?
Are there obvious security weaknesses, such as exposed admin pages or out-of-date components?
You do not need to understand the answers in technical detail. You need someone you trust to translate them into risk: what is fine, what needs attention soon and what needs attention now.
Why hiring a replacement is rarely the whole answer
A new hire, or a new freelancer, may well be part of the solution. But dropping one person into an undocumented system recreates the exact dependency you have just been burned by. It also asks that person to learn the code, fix problems and keep the lights on at the same time, usually without anyone to check their work.
For many established businesses, the system is critical but does not need a full-time developer every day. What it needs is steady maintenance, someone watching security and patching, and the ability to call on more help when change is needed. That is a different shape of support from a single employee.
Inherited code is normal
If you are worried that your system is too old, too messy or too unusual for anyone else to pick up, you are probably not alone in that. Most bespoke software built over several years has quirks, gaps in documentation and decisions that made sense at the time. Taking over a software project like this is routine work for a team that does it regularly. The first step is simply an honest assessment, without judgement.
How Scaffold can help
Scaffold Care is our fixed monthly maintenance and support service, sized to your system rather than counted in hours, and we specialise in taking on systems that others built. You get a named team who learn your software, so your business stops depending on one person, along with patching records, backups and security evidence that stand up to your own audits. For systems we did not build, the way in is a fixed-price Health Check: a review of your code, hosting, security and risks that tells you what level of care the system needs. You keep the report whether or not you go ahead with us.
Book a Health Check and find out where you stand.
