Short answer
Make sure the business owns and can reach everything: the code, the hosting, the passwords and the steps to release a change. Then get a second team working in the codebase alongside your developer, because knowledge spreads by doing the work, not by reading a handover document.
The question to ask now
Imagine your developer handed in their notice this morning, or simply went on a long holiday. Who could log in to the servers? Who could fix the portal if bookings stopped coming through? Who knows why the invoice export to Xero runs at 2am? If the honest answer is “nobody”, the business depends on one person’s health, goodwill and next job offer.
This usually isn’t anyone’s fault. A system built by an agency years ago gets taken in-house, one capable person keeps it running, and the workload grows around them until they’re the only one who understands it.
A check you can do this week
Does the business own and control these?
- The code, in a repository the company owns, with at least two admins.
- Hosting, domain names and app store accounts, in the company’s name.
- Passwords and keys, in a company password manager, not one person’s laptop.
- Backups, and proof that a restore has actually been tested.
- A list of every system the software talks to: accounting, couriers, payment providers, customers’ systems.
- Written steps for releasing a change, which someone other than your developer has followed.
- A shared list of current work and known problems.
Most of this is an afternoon’s work with your developer, and they’ll usually be glad someone asked.
Why a handover document won’t fix it
Documentation helps, but nobody learns a five-year-old system by reading about it. The real knowledge is in why things were built the way they were, which parts are fragile, and what breaks when you touch them. That spreads when a second set of people works in the code week after week, ideally while the original developer is still there to answer questions.
Getting a second opinion you can trust
If you’re not technical, it’s hard to judge whether an estimate is right or whether a problem is as serious as you’re told. That isn’t a criticism of your developer. Sole developers rarely get their work reviewed by anyone, and a senior peer to sanity-check decisions is often a relief to them too. What you want is someone senior who will tell you, in plain English, what’s worth building and in what order.
Bringing in help without upsetting your developer
Your developer can make or break this. If a second team looks like a replacement, they’ll resist it, and they’d be right to worry. So:
- Talk to them first, and frame it as help with the queue, because it is.
- Let them decide which work moves: the improvements list, the new integration, or the day-to-day fixes.
- Keep them as the owner of the system and its architecture.
- Include them in the first calls with any supplier.
How we work with one-developer teams
We start with a review of the codebase before we change anything, then take work from a shared queue that you and your developer order together. A senior developer reviews every release, urgent production bugs jump the queue on every plan, and there are no scoping documents or change orders: one flat fee, whatever ends up in the queue. Embedded starts at £2,500 a month with a monthly check-in; Embedded Plus adds a half-day CTO and planning session each month. How we work with one-developer teams.
Questions
Will our developer see this as a threat?
Not if it’s framed honestly as help, and if they choose which work moves. Most sole developers are relieved to have someone take part of the queue and review their decisions.
What if something breaks while our developer is on holiday?
On a subscription, urgent production bugs jump to the front of the queue on every plan. Because we’ve been working in the codebase, we’re not starting from scratch.
Do we need our developer’s help to get started?
It makes the start much smoother. We’ll need access sorted and an hour or two of their time while we review the codebase, then we work alongside them.