Your Only Developer Left. What to Do in the First 30 Days

"Our only senior engineer left three months ago, and nobody on the team can safely deploy." That's a line from a real job post we read on Upwork. Three months. For three months the business kept running on software nobody could touch.

It's a common story. The first weeks decide how expensive it gets, because the mistakes people make in a panic, such as letting a stranger push changes to a live system or agreeing to start over from scratch before anyone has read a line of the existing code, are the ones that cost the most to undo. Here's the order we'd do things in if it happened to a client of ours, with rough costs at our rate of $40 an hour.

Day one: two rules

Don't change anything. The product works today. Leave it. Every "small fix" made without understanding the system is a chance to take it down, and nobody is around to bring it back.

Don't agree to a rewrite yet. The first developer you talk to may say the code is a mess and should be redone. Sometimes that's true. Often it's the easiest thing to say about someone else's work, and it turns a $2,000 problem into a $30,000 one. You'll know which it is after an audit, not before.

Week 1: get the keys and a copy

Before anyone looks at the code, make sure the business can't lose the product. Access first, code later.

Go through this list and write down, for each item, who has access and where the login lives:

• the domain registrar
• hosting and the server, or the cloud account
• the code repository, usually GitHub, GitLab or Bitbucket
• the database and its admin panel
• payments, usually Stripe or PayPal
• email sending, analytics, error tracking, any AI or maps service the app uses
• app store accounts, if there's a mobile app

If an account is registered to the developer's personal email, ask them to transfer it, politely and in writing. Most will. If they've gone quiet, the registrar and hosting company can usually move an account to the paying business with proof of payment, but it takes weeks. Start now.

Then take a copy of everything: the code, a database export, the files users uploaded. Put it somewhere two people can reach. This is a day of work for a developer, around $320, and it's the best money you'll spend this month.

Last, change the passwords and remove the old access. Not because the developer is a villain, but because an account nobody watches is how breaches happen.

Week 2: an audit, not a rebuild

Now someone needs to read the code and tell you what you've got. Not fix it. Not improve it. Read it, run it, and report back.

A good audit takes 8 to 12 hours and gives you a one-page answer to five questions:

1. Can the app be deployed from the code in the repository, or does it only exist on the server?
2. Where are the secret keys and passwords, and are any of them in the code?
3. What's out of date, and does any of it carry a known security problem?
4. What's documented, what isn't, and what would a new developer need a week to work out?
5. What breaks first if nobody touches this for six months?

Ask for the answers in plain language, as a list sorted by risk, not a 40-page report nobody will open. If the auditor can't explain a problem without jargon, they don't understand it well enough yet.

Weeks 2 to 3: decide who comes next

The audit tells you how much work there is. That, and nothing else, decides who you hire.

• A few hours a month of fixes and updates. A freelancer or a small studio on a retainer. You don't need a full-time salary for a product that's stable.
• A backlog of features and a product that's still changing. Someone close to full time. A studio gets you started faster, because they've seen fifty codebases and yours isn't the strangest; an in-house hire costs less per hour once the ramp-up is over.
• A product that's a liability. If the audit says the foundations can't hold what you plan to build, that's the moment to talk about a rebuild, with a budget and a feature list, not out of panic.

Whoever you pick, ask one question in the interview: "How would you make your first change to a codebase you've never seen?" The right answer involves reading, running it locally and a small, reversible change. The wrong answer starts with "I'd rewrite".

Week 4: make it so this can't happen again

The new developer's first week isn't a feature. It's four things, a day or two in total, that most small products never had in the first place:

• Deploy from the repository, so the product can be put back up from the code alone.
• Automatic backups of the database, tested once by restoring one.
• Error alerts that go to an email the business reads, not only to the developer.
• A one-page handover note: what runs where, how to deploy, what to check when something looks wrong.

And give a second person access to everything on the week 1 list. The owner, a co-founder, a trusted ops person. Anyone. The problem was never that the developer left. It was that they were the only one who could get in.

If the developer is still reachable

Pay for a two-hour handover call, even if the parting wasn't warm. Two hours at their rate is nothing against a week of a stranger guessing, and most developers will say yes to being paid to talk about their own work. Record it. Ask:

• how do you deploy a change, step by step
• what breaks most often, and what do you do when it does
• what did you mean to fix and never got to
• which third-party services send invoices, and when

What it costs

Around $1,000 to $1,700 to go from "nobody can touch it" to "any competent developer can pick it up". A rebuild starts at ten times that. Do the first three steps first.