Almost every business that commissions software asks what it will cost and when it will be ready. Very few ask what happens when the person who built it is no longer around. It is the question that matters most three years later, and by then it is usually too late to ask it cheaply.
Nobody needs to assume the worst about their developer. People retire, change jobs, take on bigger clients, or simply become hard to reach. Planning for it is not a judgement on anyone. It is the same reason you keep a spare key.
Three ways it happens
The freelancer moves on. The person who built your booking system takes a full-time job and stops answering emails about it. Nothing has gone wrong yet, but nobody else knows how it works.
The agency changes. The firm that built it is taken over, closes, or decides small support contracts are no longer worth its while. The developer who knew your system left two years ago in any case.
The staff member leaves. This is the most common and the least noticed. Someone inside the business built a set of spreadsheets, macros, Power Apps or automated flows that everyone now depends on. When they go, so does the only person who understood it. In Microsoft 365, things built under a personal account can stop working when that account is removed, unless someone else was made an owner. A flow that turns itself off is often the first sign.
What the next person needs
Whoever picks it up, whether a new developer or a new employee, needs five things. If they have all five, the handover is a few days of reading. If they are missing any, it can turn into a rebuild.
- Access. Logins to the hosting, the domain, the database and every service the software uses, held in the business’s name rather than the builder’s.
- The code. The current version, kept in a code repository the business controls, not only on the builder’s laptop.
- A way to run it. How to put a change live, and how to undo one. This is the step most often kept in someone’s head.
- The reasons. A short document explaining what the software does, what it connects to, and why anything unusual was done the way it was.
- The data. Where it lives, how it is backed up, and how to get a copy.
None of this is exotic. A competent builder produces most of it as a matter of course, and the rest takes an afternoon. The trouble is that nobody asks for it, so nobody checks it exists. Knowing where your business software actually lives covers the access part, and is a good place to start.
Who owns the code
Paying for software to be built does not automatically mean the business owns it. As a general rule, work done by an employee in the course of their job belongs to the employer, while a contractor usually owns the copyright in what they create unless the contract assigns it. The practical answer is simple: have the contract say plainly that the business owns the code, the data and the documentation, and that accounts are set up in the business’s name. A solicitor can confirm the wording for your situation.
A builder who refuses to hand over the code is not necessarily acting in bad faith. Some reuse their own components across clients, and a licence to use those is a reasonable arrangement. What matters is that you know which parts are yours, and that the rest is licensed in a way that survives the relationship ending.
Choosing a build someone else can pick up
The technology choice decides how hard a handover will be. Software built on common, well-documented tools can be maintained by thousands of developers. Software built on something obscure, or on a builder’s own private framework, can be maintained by very few.
This is a good argument for unfashionable choices. A small app on a widely used language and database, on ordinary hosting, is easy to hand to someone new. The same applies inside Microsoft 365: an app built with standard Power Platform tools and owned by a shared account is far easier to inherit than one held together by a single person’s clever workarounds.
It is fair to ask any builder, before work starts, how easily another developer could take it over. A good one will have a straightforward answer.
What ongoing maintenance should cover
While the builder is around, a maintenance arrangement keeps the software healthy: security updates, fixes when something it depends on changes, backups that are checked, and a named person to call. The ongoing costs of a custom app sets out what that usually involves.
A good maintenance arrangement also keeps the handover material current. Documentation written at launch and never touched again describes software that no longer exists. A line in the agreement saying the notes are updated when anything significant changes costs almost nothing and is worth a lot on the day it is needed.
Three situations, worked through
A dental practice’s online booking system was built by a freelancer who has stopped replying. The hosting is in the freelancer’s name and the practice has no code. The site still works, for now. The first job is to get the hosting moved into the practice’s name while it is still running, then ask for a copy of the code. If neither is possible, the practice is better planning a replacement calmly than waiting for it to fail.
An office manager who built the firm’s job tracking in Power Apps is leaving next month. There is time. Add a second owner to every app and flow, move anything in a personal account to a shared one, and spend an hour recording a walkthrough. A month’s notice is the cheapest handover there will ever be.
A distributor is about to commission a stock app. Before signing, they ask for the code to be kept in a repository under their own account, the hosting set up in their name, and a short handover document as part of delivery. The builder agrees without fuss, and the price barely moves.
Five things worth doing
- List every piece of software someone built for you, including spreadsheets and flows built by staff.
- Write the builder’s name next to each, and whether anyone else understands it.
- Move accounts into the business’s name while relationships are good. It is routine now and difficult later.
- Ask for the code and a one-page explanation of anything you depend on.
- Put ownership and handover in the contract for anything new.
Common misconceptions
- “It works, so it does not need anyone.” It works until something it depends on changes. Browsers, payment providers and email services all change on their own timetable.
- “Another developer can just pick it up.” Only if they can get in, find the code and understand it. Without those, they are guessing.
- “Things built by staff are not really software.” If the business stops when it breaks, it is software, whatever it was built in.
- “Asking for the code means we do not trust the builder.” Good builders expect it. It protects them as well, because it makes the arrangement clear.
The honest summary
Software outlives the working relationship that produced it more often than not. The protection is five things kept somewhere the business controls: access, the code, a way to run it, a short explanation, and the data. Ask for them at the start and they cost almost nothing. Ask for them after someone has gone and they can cost a rebuild.
If you have something running that only one person understands, describe what it does and who built it. Working out what a handover would need is usually a short conversation.
Common questions
What happens to custom software if the developer leaves?
It keeps running until something breaks or needs changing. Whether another developer can then take over depends on whether the business has access to the hosting, the code, and enough notes to understand it.
Who owns the code when a freelancer builds our app?
Unless the contract says otherwise, a contractor usually keeps the copyright in what they write. Have the contract assign ownership of the code, data and documentation to the business, and check the wording with a solicitor if it matters.
How do we take over an app from a developer who has stopped responding?
Start with the accounts: the domain and hosting providers can often transfer an account to the business with proof of ownership. Then ask another developer to assess what is running. If the code cannot be recovered, planning a replacement while it still works is far better than waiting.
What should a software handover document include?
What the software does, what it connects to, where the code and data are, how to put a change live and undo it, and why anything unusual was done the way it was. One or two pages is usually enough.