What to Do When the Developer Who Built Your System Is Gone

Businesses routinely run on software that only one person fully understands. The developer who built it — often over many years — leaves. The business discovers the extent of the dependency only after the person is gone: no documentation, no handover, credentials scattered across emails and personal devices, business logic that exists only in the code and in the departed developer's memory.

This situation is more common than it should be, and it creates a specific category of problem that is different from normal software maintenance. The first response matters. Getting it right reduces the risk of what could otherwise become a crisis.

What Typically Happens

The immediate period after a developer leaves is often characterised by a wait-and-see approach: the system is running, nothing is visibly broken, so nothing needs to be done right now. This is understandable. It is also how small problems become large ones.

A system that nobody fully understands is fragile in ways that aren't immediately visible. It will continue running until something changes: a server is updated, a dependency is modified, data reaches a condition the code doesn't handle, or a user encounters a code path that was never tested. At that point, the lack of knowledge and documentation becomes urgent rather than theoretical.

The businesses that manage this situation well are the ones that act before it becomes urgent — when there is still time to be methodical.

The Immediate Priority: Stabilise Before Improving

Before anything else, confirm that the basic infrastructure for continuing operations is in place. This is about establishing a floor — making sure the worst-case scenarios are covered before attempting anything more sophisticated.

Source code. Does the business have the source code, and is it accessible? The ideal is that it is in a version control repository (Git, TFVC, SVN) that the business controls. The worst case is that it exists only on the developer's personal machine or laptop. If the source code is on hardware controlled by the departed developer, recovering it is urgent — even if the business doesn't know yet what to do with it.

Database backups. Are database backups running? Have they been verified — are they actually restorable? A backup that runs but has been silently failing for months is not a backup. A verified, tested database backup is the single most important disaster recovery asset for most business applications.

Credentials and access. Are the production server passwords, database credentials, hosting account access, and domain registrar access documented and held by someone in the business? These are regularly the most immediately problematic item when a developer leaves — particularly a developer who was also managing the hosting infrastructure.

Server and infrastructure documentation. What servers does the application run on? How is it deployed? Are there background services or scheduled tasks that run separately from the main application? Are there third-party integrations — payment gateways, external APIs, email services — with credentials that need to be documented?

If any of these are missing or uncertain, finding and documenting them is the first project. Everything else depends on having this foundation in place.

Recovering Source Code

If the developer left on good terms, the source code handover should have happened as part of an orderly offboarding. If it did not, it is worth asking — most developers are willing to hand over the code for a system they built, particularly if they are compensated appropriately for the time.

If the developer is unavailable or unwilling and the business does not have the source code, the situation is more difficult. Compiled application binaries can sometimes be decompiled to recover an approximation of the original source — this is imperfect but may be better than nothing. The original developer may have licensed or contracted work that legally belongs to the business, in which case the business has recourse.

In some cases, starting from the binaries and rebuilding the application with the system's behaviour as the specification is the most practical path — particularly if the original technology stack is very old and the codebase would have needed significant work regardless.

Understanding What You Have

Once source code, database access, and credentials are in hand, a structured assessment of the system is the next step. The goal is not to immediately fix or improve anything — it is to understand the system well enough to make informed decisions about it.

Key questions a technical assessment should answer:

• What is the technology stack? Framework versions, language versions, major dependencies and their versions.
• What does the application actually do? What are the main workflows and processes from a business perspective?
• What does the database schema look like? How many tables, and what are the key relationships?
• Are there undocumented integrations with external systems — APIs, file drops, SFTP connections, email triggers?
• Are there background jobs, Windows Services, or scheduled tasks that run separately from the main application?
• Are there known bugs or workarounds that users apply in day-to-day use?
• What is the deployment process? How does code get from development to production?

This assessment produces a documented picture of the system that did not exist before. It is the starting point for all subsequent decisions.

The Inherited Codebase Problem

Code written by a single developer over years has a specific character. Variable and method names reflect that developer's terminology, not any standard. Patterns that made sense to that developer are applied consistently in ways that are unfamiliar to anyone else. Business logic is in places that wouldn't be expected. Comments explain the obvious and omit the non-obvious. Edge cases are handled by code that looks like dead code but isn't.

This is normal. It does not mean the code is bad, and it does not mean it is irreplaceable. An experienced engineer who is comfortable reading unfamiliar code can build an accurate model of how the system works from the code alone — it takes time, but it is standard work.

What would accelerate the process: any emails or documents from the developer that describe specific decisions, any users who can describe the intended behaviour of specific parts of the system, and any historic bug reports or feature requests that illuminate what the code is supposed to do.

What Not to Do

The instinct when inheriting an unfamiliar codebase is often to rewrite it. The code feels foreign. The patterns are uncomfortable. The new engineer prefers to start with something they built themselves. The suggestion of a rewrite is almost always made within weeks of the original developer leaving.

Resist this instinct until the system is fully understood. A rewrite of a system that isn't understood yet will reproduce all of the problems that have been found, and add new ones. It will take longer than estimated. The business logic that is currently working — even if the code that implements it is uncomfortable to read — will need to be re-discovered in production.

The time to consider a rewrite is after the assessment is complete and the system is understood. At that point, the decision can be made with actual information about what the system does and what the alternatives would involve.

Finding Someone to Work on It

The skill required to work effectively on an inherited codebase is different from the skill required to build new systems. An engineer who is comfortable with greenfield development, who prefers working with modern tooling and well-structured code, is not necessarily the right choice for taking over a legacy system.

The required capability is code reading and incremental improvement: the ability to form an accurate mental model of how an existing system works, to make targeted changes without breaking things, and to improve things gradually without requiring a stable foundation that doesn't yet exist. This is a specific skill, and it is worth looking for it specifically.

What to Do: The Sequence

1. Secure the assets. Get source code, database backups, and credentials into the business's control.
2. Document what you know. Even incomplete documentation is better than none. Record what is known about the infrastructure, the technology stack, and the key workflows.
3. Stabilise. Confirm that backups are running and tested, that monitoring is in place, and that the system can be restored if something goes wrong.
4. Assess. Conduct a structured technical assessment to understand the system before making decisions about changing it.
5. Improve incrementally. Once the system is understood, improvements can be made with reasonable confidence about the effects. Add tests around critical paths. Fix specific problems. Improve what is causing pain. Consider more fundamental changes only when the system is well understood and the alternatives have been properly evaluated.