Helper CTO Series 02 | Your Engineer Left and the System's Still Running: 12 Things to Get Back First

"He left the company last month, the system's still running, so let's leave it alone for now." A system doesn't break the day someone leaves. It breaks months later, at the most inconvenient moment possible — the domain expires because nobody renewed it, the hosting payment fails, a vulnerability gets picked up by an automated scan — and that's when you discover the company doesn't even have the password to log into the server. It's not that you were careless; it's that nobody ever turned these things into a checklist and handed it to the company. Here are the 12 items to get back before something goes wrong.

"The system's still running" doesn't mean everything's fine

A system keeps running because of things that are already configured, not because someone's actively watching it. But three kinds of things have expiration dates, and when time runs out, something breaks:

• Credentials and renewals with a deadline. Domains renew yearly, hosting is billed monthly, encryption certificates rotate every few months. Tied to a personal email or a personal credit card, the notice never reaches you.
• Security vulnerabilities nobody's patching. New vulnerabilities keep being found in the underlying packages a system depends on. Once the person's gone, updates stop, and the door stays open.
• Exceptions only he knew about. A command that has to run first at month-end, a specific customer's data that needs special handling — anything that was never written down turns into a customer complaint the first time nobody handles it.

What these have in common: invisible right now, urgent the moment something goes wrong.

12 items to get back first, in four groups

This is the first checklist we ask about when we take over a system. You don't need to understand the technical details — just confirm whether the company has each item, and go after them in this order:

One, server and domain (ask whoever the bills get sent to):

• The hosting provider's control panel account: without it, nobody knows if a payment fails.
• The key or password to log into the server: without it, all you can do is watch it go down.
• The domain registrar's account: miss a renewal and the site disappears.

Two, database and backups (ask the departed engineer or check the program's config files):

• Database login credentials: without them, you can see the data but you can't get it out.
• Where backups are stored and how often they run: not confirming this is the same as not knowing whether you have any.
• How to actually restore one: if nobody knows how, it's about the same as having no backup at all.

Three, source code and repository (ask the departed engineer or the repository service):

• The latest source code, and confirmation it's the same version running in production.
• Admin access to the repository, or you'll have nowhere to push changes and no way to add people.
• Instructions for getting the program running: without them, whoever takes over spends days guessing.

Four, third-party services and keys (cross-check against the company's payment records):

• A list of external services and accounts: which providers handle payments, SMS, and email.
• Where each service's keys are stored: a key is the pass that lets the program talk to an outside service.
• The deployment process: once code is fixed, how does it actually get onto production?

If more than half of these 12 items come back "we don't know," don't panic — that's common. A more complete walkthrough is in our system operations handoff guide.

What to do when you can't get something back: three situations, in order

• The person is still reachable: schedule a handover meeting and go through each item, and have them transfer ownership of each account to an email address the company owns. Handing over a password isn't a transfer — they can still change it back.
• The person is unreachable, but accounts are under the company's name: run the "forgot password" flow from a company email address, and recover items group by group in the order above.
• The person is unreachable and accounts are under their personal name: find the recurring monthly charges in the company's payment records and request a transfer from each provider — you'll usually need to prove the company is the actual payer.

Whichever situation applies, the first thing to do once you get access back is rotate every password and key. It's not about distrusting the former employee — it's that you have no way of confirming where they were ever stored.

Once you have everything back, get someone to look at it before you rush to hand it off

Once the items are in hand, the real question starts: is this system worth keeping alive? Whether the code is readable, whether the data can actually be exported, whether backups exist, whether the deployment can be redone — none of this should be judged by the owner alone, or by the next engineer's guesswork. Engineers are getting harder to find, and outsourcing thinking for a talent-scarce era covers why many companies no longer rely on a single person. Get someone to assess it first, and you'll know what kind of person you actually need.

Four commitments when Nerdtechnic takes over a system

• The same team handles it start to finish: takeover, maintenance, improvements, ongoing development — you never have to re-explain how the company works every time someone new is assigned.
• We look before we quote: the health check isn't tied to a contract; you decide whether to work with us after seeing the results.
• Someone responds when something breaks: a response within 1 business day when the server or a service goes down, an assessment within 2 business days when you report a bug.
• When the engagement ends, the documentation and records are yours — switching to someone else doesn't turn into a black box.

One person leaving shouldn't leave the whole company's system hanging in limbo.

Taking over a system after an engineer leaves is one of the most common things we handle as Helper CTO — like an in-house tech lead, just not on your payroll, and the same team maintains and improves the system after taking it over. The first step is a 60-minute system health check: we only need to see the code, no credentials to your production environment required, and within 3–5 business days you'll get a one-page report telling you whether the system can be taken over as-is, needs cleanup first, or would be cheaper to rebuild. If you can't gather all 12 items right now, you can start here: Helper CTO: System Maintenance Plan.