The instinct after a developer leaves is to find a new one and get back to building. Resist it for a couple of weeks. The first job isn't writing code. It's making sure your company actually controls the software it paid for, and finding out what shape it is really in. Everything after that goes faster and costs less.
Days 1 to 3: secure access
Before anything else, make sure your company, not a person, owns every account the software depends on. Make a list and work through it:
- Source code. The repository on GitHub, GitLab or Bitbucket, owned by a company account with you as an owner.
- Hosting. The servers or cloud account the application runs on, and the billing for it.
- Domain and DNS. The registrar and DNS provider, with your company email on file.
- Databases and backups. Where the data lives, and proof that a recent backup exists and can be restored.
- Third-party services. Payment processors, email senders, app store accounts, analytics, any API the software calls.
- Secrets. API keys and passwords. Once you have them, plan to rotate them, because someone who has left still knows the old ones.
Week 1: take inventory
Now write down what actually exists. Not what the original proposal promised, but what is running today.
- Every application, site, background job and scheduled task, and where each one runs.
- What each part depends on: languages, frameworks and their versions, outside services.
- What it all costs each month, and who is paying for it.
- How code gets from the repository to production. If the answer is "the old developer did it from their laptop", that is your first fix.
- Any documentation, however thin, and any open bugs or half-finished features.
Week 2: get an honest code review
A senior engineer should read the code and write you a plain-English report. It should answer a short list of questions:
- Is anything about to break? Expiring certificates, unsupported framework versions, a disk that is nearly full, a dependency with a known security issue.
- Are there security problems? Passwords stored in plain text, missing input validation, admin pages without proper login.
- Can it be deployed safely? Is there a repeatable way to release a change and roll it back?
- Is it understandable? Could a competent developer who has never seen it make a change in a reasonable time?
- What would the next three changes you want actually cost?
The report should be about the code, not about the person who wrote it. You need facts to make decisions, not a critique of your last hire.
Weeks 3 and 4: stabilize, then decide
Fix the urgent items from the review first: security holes, anything about to break, and a safe deploy process. Then you are in a position to make the real decision, with evidence instead of guesses.
Fix and extend, rewrite, or replace?
- Fix and extend when the code is understandable and the problems are local. This is often the right answer, and the cheapest.
- Rewrite in stages when the core is sound but parts are unmaintainable. Replace the worst parts one at a time while the rest keeps running.
- Replace with an off-the-shelf product when the custom software does something a mainstream tool now does well.
- Rewrite from scratch only when the existing code genuinely can't be moved forward. Be suspicious of anyone who recommends this before reading the code.
How to avoid doing this again
- Keep every account in the company's name from day one, with at least two people who can get in.
- Require a written deploy process and basic documentation as part of any engagement.
- Ask for regular, small releases instead of long silences followed by a big launch.
- Make sure the contract says the company owns the code.
If you are in this situation because a budget build went wrong, our post on the real cost of cheap development covers the red flags to watch for when you hire the next developer.
Where we come in
Taking over projects is one of the main things we do. We follow the order above: access first, then inventory, then a written review, then a priority list with estimates, and only then new work. Read more on our project rescue page, or tell us what was left behind.