How to Reduce Dependence on One Developer

Start with an honest list. Write down every login, deployment step and piece of undocumented logic that exists only in one person’s head or personal accounts, and do it while that developer still cooperates. Rebuilding it afterwards costs far more. Ask the developer to narrate a typical release while someone else takes notes, because spoken walkthroughs surface steps that written lists forget.

Consider an interior design firm whose project tracker and client approval tool has been maintained by one in-house developer for six years. That person probably knows which server to restart when a batch job hangs, which client’s data has a known quirk, and how an integration was patched around a limitation. Write those details down first.

Many repositories, hosting plans, domains and API subscriptions were opened under the developer’s personal login, which was convenient then and is a single point of failure now. Move each into a company account. Give the developer access as a team member rather than as the account holder, so that leaving, illness or a lost phone no longer locks the business out.

Close the checklist completely. One forgotten account recreates the whole risk, and the classic example is a paid API key still billed to a personal card that nobody else knows about.

Documentation need not be exhaustive. It must cover what would otherwise live in one memory: the path from source code to a running system, where data is backed up, and how a restore works. Keep the documents in the company repository or wiki, not in the developer’s notes app, so they survive the same departure they are meant to protect against.

Also cover the common failures: a bad deployment, a database fault and an expired certificate, each with the exact steps and the person to call. Write for a stranger. Aim the text at a competent developer who has never seen the system and skip any context that only an existing employee would have. Can a newcomer follow it?

Code review is cheap insurance. At least one other person reads and understands each change before it goes live, so familiarity with the codebase builds change by change instead of arriving all at once. Pull requests with a named second reviewer create a visible record of who has seen which part of the system, which later tells you where knowledge is still thin.

Shared ownership extends the same idea by rotating who handles each part, pairing on harder changes, and making sure two people have worked in every module. Otherwise modules stay private property.

The clearest test is a rehearsal. A second person, either a teammate or an outside contractor, deploys a change using only the documentation and access already set up, with no help from the main developer. Record every place they stall. Pick a change small enough to finish in an afternoon, such as a text edit or configuration value, so the exercise tests access and instructions rather than coding skill.

Run the rehearsal on a calm schedule rather than discovering the gaps during an emergency, when nobody has time to read documents or call anyone. Repeat it after big changes. Documentation goes stale quietly, often right after someone edits the deployment script, and only a fresh rehearsal catches the drift before a real handover does.