# My Developer Left. Now What? A 7-Step Recovery Plan

> My developer left. Now what? Secure access, preserve the running system, assess the code, and choose a stable recovery path before making risky changes.

Source: https://keepstone.tech/blog/my-developer-left-now-what
Published: 2026-08-26
Modified: 2026-08-26

---

My developer left. Now what? Start by securing access and preserving the system exactly as it is. Do not rush into a rebuild or let a new developer make production changes before someone has mapped the code, data, infrastructure, and business dependencies.

A developer departure is not automatically a software emergency. It becomes an emergency when the system is down, data is exposed, payments or core workflows are failing, or the business does not control the accounts required to keep it running. If the application still works, you have time to make a controlled recovery plan.

## The 7-step recovery plan after your developer leaves

### 1. Confirm the system is operating

Run the few transactions that matter most to the business. Log in, complete a core workflow, confirm that scheduled outputs arrived, and check that payments or customer-facing actions still work. Record what you tested and the exact time.

Do not treat a successful login as proof that the whole system is healthy. The goal is a quick operating baseline: what works now, what is already broken, and which failures would stop the business.

**Immediate classification**

| Condition | Response |
|---|---|
| System works and no exposure is known | Preserve it and begin the access inventory |
| A core workflow is failing | Stabilize the affected path before adding features |
| Data or credentials may be exposed | Treat it as a security incident and restrict access |
| Hosting, domain, or database ownership is unclear | Start account recovery immediately |

### 2. Inventory every account and owner

Create one document with the service, account owner, billing owner, administrator, recovery email, and current access status. The first list should cover:

- Source repository — GitHub, GitLab, Bitbucket, or another host
- Domain registrar and DNS provider
- Hosting and cloud accounts
- Production and staging databases
- Deployment service and continuous-integration system
- Email, messaging, payments, analytics, and other integrations
- API keys, service accounts, certificates, and SSH keys
- Monitoring, error tracking, backups, and status alerts

If the repository sits in the developer's personal GitHub account, ask for a transfer while communication is still possible. [GitHub's repository-transfer documentation](https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository) confirms that an administrator can transfer a repository to another user or organization and that commit history, issues, pull requests, releases, and settings move with it.

The business should control the registrar, cloud bill, repository organization, database, and payment processor. A developer can administer those systems without owning them.

### 3. Preserve evidence before changing anything

Take recoverable copies before a new person starts “cleaning up.” Clone every repository and branch. Export or snapshot databases using the platform's supported process. Save deployment configuration, infrastructure files, current environment-variable names, provider invoices, system diagrams, and any handover messages.

Do not paste live secret values into the inventory document. Record where each secret is stored, what it is used for, and who can rotate it.

Backups are useful only if they can be restored. NIST's [contingency-planning guidance](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final) treats backup, recovery, testing, and system priorities as connected parts of a recovery plan. The practical takeaway is bounded: take a backup now, then have the technical assessment verify that the restore path works.

### 4. Remove access carefully

Remove the departed developer from accounts the business controls, especially the registrar, payment processor, repository organization, cloud console, and password manager. Preserve audit logs before changing memberships where the platform makes that possible.

Do not rotate every API key at once without knowing which production service uses it. A blind rotation can turn a personnel transition into an outage. Map the dependency, create the replacement credential, update and verify the application, then revoke the old credential.

The [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) recommends centralized storage, fine-grained access, auditing, and supported rotation. Those controls matter during a handoff because one shared, undocumented credential can connect several services and make the effect of revocation hard to predict.

### 5. Check what the business legally owns

Collect the employment agreement, contractor agreement, statement of work, invoices, intellectual-property assignment, repository records, and any written handover terms. Access to a repository and ownership of copyright are related but different questions.

For US work, the Copyright Office says a work made for hire generally covers work created by an employee within the scope of employment or a qualifying commissioned work covered by an express signed agreement. Its [Circular 30](https://www.copyright.gov/circs/circ30.pdf) also warns that the issue is fact-specific.

This article is not legal advice. If a contractor disputes ownership, withholds code, or the agreement lacks a clear IP assignment, take the documents to a technology attorney before assuming that payment alone settled the issue.

### 6. Assess the system before choosing the remedy

A useful assessment answers business questions, not just code-quality questions:

1. What does the system do, and which workflows are critical?
2. Where do the code, data, infrastructure, credentials, and integrations live?
3. Can a qualified person deploy a small change safely and roll it back?
4. Are logs, alerts, and backups present and usable?
5. Which dependencies or security findings require immediate action?
6. What knowledge existed only in the departed developer's head?
7. Is the system stable enough to operate, in need of hardening, or cheaper to replace?

Keepstone scores this work against the 8 layers of the [Software Ops Agent Framework](/framework): engineering workflow, infrastructure, observability, triage, documentation, security, continuity, and governance. The output should separate immediate risks, hardening work, and optional improvements.

An assessment is different from an open-ended takeover. It should end with a written inventory, ranked findings, a recommendation, and a bounded scope for whatever happens next.

### 7. Choose stabilize, operate, or rebuild

Do not let “the developer left” decide the technical strategy. Choose based on the system's condition and the business's needs.

| Path | When it fits | First objective |
|---|---|---|
| Stabilize and hand over | The system works, but ownership and operating controls are weak | Secure access, document dependencies, and prove deploy and recovery paths |
| Harden and operate | The system is valuable and repairable, but lacks ongoing ownership | Bring the operating layers to baseline and assign recurring accountability |
| Rebuild selectively | Specific components are unsafe or block necessary change | Replace bounded parts while preserving proven business logic and data |
| Full rebuild | The existing system cannot support the required workflow or risk level economically | Preserve data and requirements before replacing the application |

A rebuild is a business decision with migration risk, not a default response to unfamiliar code. The right successor should be able to explain what can stay, what must change, and what evidence supports that recommendation.

## What to ask the replacement developer or operator

The next arrangement should remove the same [key-person risk](/blog/when-your-internal-tool-has-only-one-brain) that created the problem. Ask every candidate:

1. Who owns the repository, cloud accounts, domain, database, and credentials during the engagement?
2. What written assessment will you complete before changing production?
3. How will changes be tested, reviewed, deployed, and rolled back?
4. What monitoring and incident history will the business be able to see?
5. Which documentation is included and how will it stay current?
6. How are backups tested rather than merely scheduled?
7. What happens to access, documentation, and work product when the engagement ends?

A strong answer is concrete. It names accounts, artifacts, review gates, and exit steps. “We will take care of everything” is not an operating model.

## The durable fix is operational ownership

Replacing one developer with another restores capacity, but it does not automatically restore continuity. The durable fix is to make the system operable by someone who did not build it.

That means source control owned by the business, documented infrastructure, secrets outside the code, visible health signals, a reversible release process, tested recovery, current runbooks, and a named person accountable for decisions. Keepstone calls the recurring discipline around those controls [Software Ops](/what-we-do).

If your developer has left and the system is already running, the next step is a [free software assessment](/start?path=assess). It produces a written view of what you control, what is fragile, and what it would take to operate the system without recreating the same single-person dependency.

## Frequently asked questions

### Is it an emergency if my developer left but the app still works?

Not necessarily. It is an emergency if the system is failing, data or credentials are exposed, or the business cannot control the accounts that keep it running. A functioning system with clear account ownership usually gives you time to inventory, assess, and choose a successor carefully.

### Should I change every password and API key immediately?

Remove unnecessary human access quickly, but rotate application credentials in a controlled sequence. First map which service uses each credential, then introduce and test the replacement before revoking the old value. Blind rotation can cause an avoidable outage.

### What if the developer kept the repository in a personal account?

Request a repository transfer to an organization the business controls. If the developer is unreachable, look for local clones, deployment artifacts, connected continuous-integration services, and backups. Do not assume the deployed application can always be turned back into the original source code.

### Should I hire a new developer before getting an assessment?

Hire for the assessment first, not for an open-ended rebuild. The assessment should identify ownership, architecture, operating gaps, immediate risks, and the realistic options before anyone quotes a large remediation or replacement project.

### How do I stop this from happening again?

Keep critical accounts in company ownership, require reviewable and reversible changes, maintain current documentation, test backups, and define exit obligations in writing. Most importantly, assign ongoing operational ownership instead of relying on the original builder's availability.