What to do when the developer who built your software disappears

Your developer stops answering.

Maybe they quit. Maybe they got another job. Maybe the freelancer decided that selling handmade candles is less stressful than maintaining your booking system. Or maybe the relationship simply ended badly.

Whatever happened, you now have software that your business depends on and nobody who understands how it works.

This is unpleasant, but usually not a disaster. The biggest mistake is treating it like one.

First, secure what you already have

Before thinking about improvements, new developers, rewrites, or migration plans, make sure you actually control your own software.

You need access to the source code repository, servers, domains, DNS, databases, cloud accounts, email services, payment systems, app stores, third-party APIs, and anything else the application depends on. If some of those accounts belong to the previous developer personally, this should immediately become your highest priority.

Do not assume that because you pay for the software, you automatically control its infrastructure.

I have seen businesses discover that their production server was sitting inside a freelancer’s personal cloud account. The freelancer wasn’t trying to hold anyone hostage. They had simply created the server three years earlier, nobody thought about ownership, and everyone moved on.

Until somebody disappeared.

Change passwords where appropriate, remove accounts that should no longer have access, and enable two-factor authentication. But don’t blindly rotate every credential at once. An application may contain old API keys or passwords that nobody documented, and changing them can break production in surprisingly creative ways.

Make a copy before touching anything

Your next goal is preservation.

Create backups of the source code, database, uploaded files, server configuration, environment variables, and anything else required to reproduce the system. Ideally, verify that the database backup can actually be restored. A backup that has never been tested is partly a backup and partly a motivational poster.

If there is no source repository, copy the files from the production server. If the only copy of the database lives on that server, back it up immediately.

Do this before anyone starts “cleaning things up.”

A new developer will naturally want to improve questionable configuration, update dependencies, move files, rename things, or replace some mysterious script written in 2019. Those changes may eventually be good ideas. They are much safer after you have frozen a working copy of the current system.

Don’t start with a rewrite

This is one of the most expensive reactions to inheriting unfamiliar software.

A new developer looks at the code and says, “This is terrible. We should rewrite it.”

Maybe they’re right about the first sentence.

That doesn’t automatically make the second sentence true.

Old software often contains years of accumulated business rules that nobody remembers well enough to describe. A strange 17-line condition may look ridiculous until someone removes it and invoices for customers in Belgium suddenly stop working.

Before replacing the system, understand what it actually does.

A boring PHP application that has been processing orders reliably for eight years may be more valuable than a beautiful new architecture that is 40% finished.

Find someone who can investigate before they improve

The first job for the replacement developer isn’t feature development. It is reconnaissance.

Ask them to determine how the application is deployed, where its data lives, which external services it talks to, how authentication works, whether backups exist, how scheduled jobs run, and what happens when something fails.

You also want to know what condition the code is in. Are dependencies five years out of date? Are secrets stored inside the repository? Are there automated tests? Is there a staging environment? Can another developer run the application locally without performing an archaeological expedition?

This doesn’t need to become a 60-page technical audit.

For a small system, a few pages of useful notes may be enough. The important part is turning invisible knowledge into visible knowledge.

Watch the production system before changing it

Logs are often more useful than documentation.

A developer can learn a surprising amount by looking at application errors, server logs, database activity, background jobs, API requests, monitoring history, and deployment records.

The goal is to distinguish ugly code from dangerous code.

Those are not the same thing.

A system may have terrible naming conventions and work perfectly. Another may look clean while silently failing to process 3% of incoming requests.

Fix the second one first.

Identify the real dependencies

Most business software is not one application anymore.

It might depend on Stripe, Twilio, Google Maps, AWS S3, Cloudflare, SendGrid, Telegram, accounting software, a shipping API, OAuth providers, cron jobs, webhooks, or a small service running on a server nobody remembers.

Make a list.

For each service, record what it does, who owns the account, how it is billed, and where its credentials are stored. Also check whether anyone still has access to the email address used to register the account.

This exercise is boring.

It is also much less boring than discovering during a payment outage that the Stripe account belongs to somebody who left the company two years ago.

Stabilize first, modernize later

Once the system is understood, fix the things that can realistically hurt the business.

Broken backups are important. Expired certificates are important. Critical security vulnerabilities are important. A server that is almost out of disk space is important.

Whether the project uses the fashionable JavaScript framework of September 2026 probably isn’t.

There will be plenty of tempting improvements. Upgrade the framework. Replace the database layer. Move everything to Kubernetes because apparently your five-person company now operates Netflix.

Resist the urge.

A useful first milestone is much simpler: another developer can deploy the application, restore it from backup, diagnose failures, and make a small change without being terrified.

That is already a major improvement.

Document the system while people are learning it

Documentation written from memory six months later rarely happens.

Ask the new developer to document important discoveries as they work: deployment steps, infrastructure, services, unusual business rules, backup procedures, configuration, and known problems.

Keep this documentation somewhere the company controls.

You do not need a beautiful internal encyclopedia. A README file containing ten accurate paragraphs is worth more than an empty company wiki with 47 carefully organized categories.

The goal is simple: the next developer should not have to start from zero.

Reduce the chance of this happening again

Developers leaving is normal.

Software becoming unusable because one developer leaves is not.

Your business should own the repositories, hosting accounts, domains, cloud services, and third-party accounts whenever practical. More than one trusted person should have access to critical infrastructure. Backups should run automatically, and somebody should occasionally verify them.

You should also be able to answer a few basic questions without calling a specific developer:

• Where is the source code?
• Where is production running?
• Where is the database?
• How do we deploy?
• How do we restore from backup?
• What external services does the application depend on?

You don’t need to understand how the code works. You do need to know where the keys to the building are.

The disappearing developer is usually not the real problem

People leave projects for all kinds of reasons. Freelancers disappear. Employees resign. Agencies close. Developers get sick, move countries, change careers, or simply stop enjoying a project.

You cannot prevent that.

What you can prevent is building a business where one person’s laptop, memory, and collection of passwords are part of the critical infrastructure.

If your software survives only while one particular developer remains available, you don’t really own a software system yet.

You own a dependency on a person.