When the developer who built your system leaves, whether that was a permanent employee, a contractor you had used for years or a consultancy whose contract has come to an end, it is tempting to try to replace them as soon as possible. If you have a clearly defined roadmap and a backlog of work waiting, that may well be the right thing to do. If you do not, this is an opportunity to take a step back and look again at where you are.
Key takeaways
- Replacing the developer straight away makes sense if you already have a clear roadmap. Without one, the time is better spent working out what you have.
- If a contractor or consultancy ran the system on their own accounts, getting ownership transferred is the one genuinely urgent job.
- The most important thing you lose when someone leaves is their knowledge of why they have done things a certain way.
- Losing the person who built it is a reason to look at the whole system again, which is worth doing on its own terms even though the timing was forced on you.
- Work out whether you want more of the same or something different before you choose between a permanent developer, a contractor and a consultancy.
Take stock of what you have
Your developer leaving may feel like a crisis, but the application will keep running just like before, and any competent developer should be able to pick it up and support it. The key thing you have lost is the thinking behind the decisions that were made, and any knowledge about which parts are fragile.
Sometimes developers document all their designs and decisions, but more likely any documentation you have will be out of date.
One useful thing you can do is to get someone to review what you have. This involves a senior developer looking at the code to understand the technologies used and how it has been built, and nowadays an AI can make a huge difference to that job. However, it also involves looking at how the application is deployed and what infrastructure it depends on.
This is useful even if it is a mature application, because technologies change very quickly and sometimes a review will uncover issues that need to be addressed sooner rather than later.
No matter who built your application, whether that was a contractor, an employee or an AI, reviewing where you are will give you what you need to decide what comes next.
Decide where you want to get to
Once you know what you have, the question is what you want it to do next, and that is a business question rather than a technical one.
Think about how things were going up to this point. What went well? What was slow, or frustrating, or more expensive than you expected? What did you ask for and never get? If there were problems, then replacing like with like will not fix them.
Then decide what you want from the system itself. You may want it to carry on doing exactly what it does now, for as long as it keeps earning. You may want to build on it, because the business has moved and the software has not. Developers are renowned for wanting to throw it all away and start again. It is at least worth considering, although it is usually the wrong solution.
Choosing between these things before you hire matters, because each answer needs a different kind of person. Keeping a stable system running is maintenance work that a capable generalist can do in a few days a month, whereas building on it needs someone who will still be around in two years, and replacing it needs someone who can write a specification before anyone writes code.
Bring in the right person to get you there
If the plan is to leave the system alone, you may not need to hire anyone at all. Plenty of businesses run software for years in that state. What you need is backups you have tested, a list of what renews and when, and somebody's number to call if it stops, none of which amounts to a retainer however it is sold to you. Security patching still has to happen even if you never change a feature, so someone in the business has to understand that the patching and the renewals are now their responsibility.
If there is real work to do, there are three ways to buy it, and they suit different plans:
- A permanent developer is worth it when there is enough work to keep one person busy for years and you want the knowledge to stay inside the business. It is the slowest to arrange and the hardest to reverse, and you carry the cost whether the work is there or not.
- A contractor suits a defined piece of work with an end to it. You can get someone quickly and stop when the work stops, though you will be back where you are now when they leave unless you insist on things being written down as they go.
- A consultancy gives you more than one person. You can also expect them to think more about the long-term direction. It costs more per day, but is worth it when being wrong would be expensive.
The trade-offs between an individual and a firm are covered in more detail in should you hire a developer or an agency. Whichever you choose, brief them against the review and the plan rather than against the vacancy, because any quote to maintain, extend or replace a system that nobody has read is a number somebody invented.
What to do next
Work out whose accounts the system runs on this week, and get anything held in a supplier's name moved into yours, because that is the only part that gets worse if you wait. Get someone senior to read the system and tell you honestly what state it is in. Work out what was good and bad about the way you were working before, and where you want the system to be in two years. Then decide who you need, which might be a lot less than it feels like today.
If you have reached the point where nobody in the business can answer questions about software the business depends on, tell us what you have and what it does for you. We will tell you what we would need to look at, and whether you need someone permanently or just need somebody to make sense of it once. If the honest answer is that you need less than you feared, that is what we will say.
FAQs
Do we own the code our developer wrote?
Check the contract before you assume so. Paying for software does not automatically transfer copyright to you, and without a written assignment clause, you may hold only a licence to use it. Look for a clause assigning intellectual property to your business, and get a solicitor to read it. If you are commissioning work in future, settle this before the build rather than after.
Should we ask the developer who left to come back and help?
It is worth asking, but the time to do it is before they leave rather than after. Most people work a notice period, so anything you want written down should be written down then. Handover is also less valuable than people expect, because an AI can read a codebase and summarise what it does in a fraction of the time it takes to sit through a walkthrough. What an AI cannot tell you is why the system was built the way it was, so if you do get an hour of their time, spend it on the decisions rather than the code.
How long can we run without anyone maintaining it?
Stable systems often run for months with nobody touching them. The clock that matters is security patching and expiring certificates, not features. If nothing needs to change and someone is watching for renewals, you have time to choose well rather than quickly.