Taking over software after the developer leaves
A practical sequence for inheriting a system whose builder is gone: secure access, understand production, write down what nobody wrote, then change things.
Paul BădărăuWhen the developer who built your software leaves, the software does not change. Your relationship to it does. You now own a system nobody on your side understands, and the order in which you do the next things matters more than how fast you do them.
This is the sequence we follow when we take over a system in that state.
First: secure access before anything else
Before reading a line of code, collect and verify access to everything the system depends on: source control, hosting, domain registrar, DNS, databases, email sending, payment providers, third-party APIs, app store accounts, and monitoring. Confirm that each account is owned by the company, not by a personal address that left with the developer.
Rotate credentials the departed developer had. Do it carefully, one system at a time, with a way to roll back. A rushed credential rotation is the most common way a takeover causes its first outage.
Check billing. Systems fail months after a departure because a card on a forgotten account expired.
Second: understand production, not the repository
The repository tells you what the developer intended. Production tells you what is true. Start there.
- What is actually deployed, from which commit, and does the repository match it?
- What runs on a schedule? Cron jobs, queues, and scheduled functions are where surprises live.
- What talks to what? Map every external service, webhook, and integration.
- What data exists, where, how large, and when it was last backed up? Then restore a backup somewhere safe to prove it works.
- What do the logs and error trackers say has been failing quietly?
This phase produces a map. It usually reveals two or three things that were one bad day away from failing.
Third: write down what nobody wrote down
Every inherited system has knowledge that lived only in the developer's head. Recover as much as you can while it is recoverable. If the developer is reachable and willing, a few paid hours of questions are worth more than weeks of archaeology. Ask about the decisions, not the code: why this database, why this hosting, what they would change, what they were afraid of.
Then write the operating manual the system never had. How to deploy. How to roll back. How to restore. Who to call at each external provider. Where the secrets live. It does not need to be long. It needs to exist and to be correct.
Fourth: make one change safely
Before any real work, make a trivial change and ship it through the full path: commit, review, test, deploy, verify, and know how you would undo it. If any step is missing or manual, fix that first. The ability to change the system safely is the foundation for everything else, and it is worth a week of effort even if the change itself is a typo in a footer.
Fifth: address the fragile parts, then the wanted ones
Now the map from step two becomes a plan. Expired certificates, unsupported dependencies, failing backups, and single points of failure come first. They are rarely what the business asked for and always what it needs.
Feature work starts after that. It goes faster than expected, because by now someone understands the system, and estimates are based on knowledge instead of hope.
What to expect
A takeover done in this order takes several weeks before the business sees a new feature. That is the cost of not doing it, made visible. Teams that skip to feature work inherit every risk the previous developer was silently managing and discover them one incident at a time.
The goal is not to replace the departed developer. It is to make the system not depend on any single person again. The full list of what to inspect is in the codebase takeover checklist, and software takeover is the service when you would rather we did it.