T

The founder's next message was a question, and it was the wrong one. How fast can we replace him?

Thirty days. One person who has ever deployed the thing that pays everyone's salary. When the only developer leaving a startup is also the only person who has touched production, those thirty days are not recruiting time. They are extraction time, and the two activities compete for the same calendar.

Spend the notice period buying knowledge rather than screening candidates. The first three days go on account ownership and the deploy path, because those are the two things that can take the product down while you are still interviewing. The next four weeks go on a handover you commission as a defined piece of work with a written deliverable. Recruit after that. An engineer who arrives into an undocumented system spends their first quarter doing archaeology at senior rates, and you will have paid twice for the same map.

I have been the person who arrives after. The first week is never spent reading code. It is spent finding out which of the four AWS accounts is the live one.

What do I do in the first 72 hours?

The window you are working inside is goodwill, and goodwill decays faster than notice periods. In week one they will screen-share for an hour and answer follow-ups the same day. By week four they are mentally in the new job and their replies get shorter. Everything expensive to reconstruct should be extracted while the answers are still generous.

Start with anything owned by a person rather than by the company. Credentials in the shared 1Password vault are already yours and can wait. What you are hunting is the AWS root account opened with a personal Gmail in year one, the Cloudflare zone sitting on their own login, the domain at a registrar nobody has signed into since a renewal email in 2023. Ownership transfer on those runs through email verification and support tickets, and it takes days. It cannot start after the account holder has stopped caring.

Then the deploy path, written by them, in their words, while you watch them do it. Not an architecture diagram. A numbered sequence of commands, in order, with what to check after each one. If the sequence contains the phrase "and then I usually SSH in and restart the worker", that single line is the most valuable output of the week, because it is the step that exists nowhere except in a habit.

Then the things that run without anyone asking. Cron entries, scheduled jobs, a nightly script on a box that appears on no diagram anyone has drawn. Ask it as a specific question rather than a general one: what runs on a schedule, and what breaks if it does not run for three days? The answer is never "nothing."

Then the external systems that are waiting for something from you. Let's Encrypt has issued certificates with a 90-day lifetime since it opened to the public in 2015, and yours renew through an ACME client somebody configured once and never looked at again. Stripe retries a failed webhook with backoff and eventually gives up. Sentry alerts route to a mailbox that gets deactivated on the 29th, which means your monitoring quietly ends on the 30th. Each of these is silent right up until it is an incident.

Put the output in the repository, not in a wiki page. The repository is the only place your next engineer is guaranteed to look.

Should I pay for the handover?

Yes, and scope it like work rather than like a favour.

An exit interview is the wrong container for this. It produces goodwill and platitudes, both of which are pleasant and neither of which tells anyone how to restore the database. What you want is a purchase order: a fixed number of hours, a named list of documents, and a delivery date before the last day. Deploy runbook. Restore procedure. Account and credential inventory. Data model notes covering the tables whose names lie about their contents. A list of every scheduled job with its blast radius.

The step almost everyone skips is review, and it is the step that makes the documents true. Somebody who did not write the runbook has to follow it, on a real environment, before the author leaves. A runbook nobody has executed is a wish with formatting.

Four responses to the same thirty days, priced honestly:

Most of the founders I have watched handle this well used the middle two together and treated the first as a separate hiring decision made in month two.

Days 4 to 30: what does an incoming engineer actually need?

Reconstruct in the order that unblocks the next thing, which means environment, deploy path, data model, business logic.

Environment first. Can a new person get the system running locally or in a branch environment without asking anyone a question? Until that is true, every piece of curiosity they have costs somebody else's afternoon, and they will stop being curious.

Then the deploy path, because someone who cannot ship a one-line change is a spectator. Their first commit should be trivial and go to production on day two, not for the value of the change but as proof that the path works when the usual person is not driving it.

The data model comes after that, and I don't mean the ORM classes, which anyone can read in an afternoon. What matters is the tables whose names no longer describe what they hold, the column that is nullable because of a migration in 2022 and is now load-bearing, and the two places customer state is duplicated with a rule about which one wins.

Business logic goes last, which founders usually find backwards. It happens to be the one layer that is faster to learn from the code than from a person, because the code is the definitive statement of what the system does. Everything above it lives in habits and open browser tabs. So the departing engineer's remaining hours go on operations rather than on code walkthroughs.

Which knowledge is actually dangerous to lose?

The code is safe. It is in git, it compiles, and it will still compile in March.

What leaves the building is operational. Which alert fires every Tuesday and is safe to ignore, and why that is safe. Which customer has a bespoke configuration that a routine deploy will break. Which migration has been written, reviewed, merged, and never once run against production-sized data.

Ask those three as literal questions and write the answers down verbatim.

The migration one is where I have seen the worst outcomes. A schema change tested only against a development dataset of a few thousand rows behaves completely differently on a table with forty million, where an ALTER TABLE on Postgres can take an ACCESS EXCLUSIVE lock and hold every read behind it. The new engineer, doing exactly what the ticket says, runs it on a Thursday afternoon. Nothing in the code review would have caught that, because the knowledge that the table is enormous was in someone's head and that someone now works elsewhere.

There is a second version of this problem that shows up later, when an enterprise prospect sends a security questionnaire and there is nobody in the company who can answer the architecture questions you can't answer.

Should I hire the replacement now or later?

Later, and the arithmetic is not close.

A senior backend engineer on €95,000 gross costs roughly €120,000 fully loaded once employer contributions and overhead are counted, which is about €10,000 a month. Three months of a new hire reconstructing an undocumented system is €30,000 of salary spent on archaeology, and during those three months your feature output is close to zero because they are reading rather than building. That is the real bill, and it does not appear in any budget line because it looks like onboarding.

A structured two-week diagnostic on the same system produces the document that new hire would have written in their head, except it exists on disk before they arrive. The same exercise sits behind a technical debt audit, which is the format I would use here, because the output is a prioritised map rather than a report card.

Hiring in a panic also produces worse hires, and there is a specific reason it does. Assessing a backend engineer requires an engineer, and you have just lost yours. Founders in this position tend to over-weight the interview signals they can read, which are communication and confidence, and under-weight the ones they cannot, which is most of the job. If you must run the loop now, borrow a senior engineer for the technical screen and give them a rubric, because there are ways to evaluate engineering work without being an engineer that hold up better than a gut read.

Now the recommendation that costs us money to make.

Sometimes the correct move is to put the departing engineer on a retainer for six months of two hours a week, paid at a rate that will feel insulting. Eight hours a month at €150 an hour across six months is €7,200. Against €30,000 of rediscovery, that is a rounding error, and it buys you the one thing no document contains, which is the ability to ask a question in context and get an answer in twenty minutes. We sell senior engineering. The retainer is the option that earns us the least and it is the first one I raise, because in the majority of these situations it is what I would do with my own company.

It feels bad. You are writing cheques to the person who left, and one arrives every month to remind you. That is a different thing from it being expensive.

If you are raising in the next twelve months there is one more reason to close this properly, which is that an investor's engineer looks for exactly this pattern and files it under key-person risk.

Questions founders ask in the first week

My only developer is leaving and there is no documentation. Where do I start? Account ownership, then the deploy path, then anything that runs on a schedule. Those three can break the product while you are still hiring, and all three are cheap to capture while the person is still answering messages the same day.

How much should I pay for a handover? Between 20 and 40 hours at a consulting rate, scoped as named deliverables with a date, not as extra hours on the notice period. Pay it as a separate invoice so both sides treat it as work.

Should I hire a replacement or bring in an agency? Neither, in the first month. Get the handover done, then decide with a map in front of you. The decision is easier once you know whether the system needs one senior engineer for a year or three specialists for six weeks.

How long before a new engineer is productive on an undocumented codebase? Three months to independent, longer if deploys require tribal knowledge. Two weeks of the leaver's time compresses that to about six weeks, which is the strongest argument for doing the extraction first.

Can I ask a departing engineer to stay on part time? Yes, and most say yes if you ask before the relationship cools and pay properly. Put it in writing with a defined response window, because "message me any time" degrades into silence by week five.

The list of accounts held in a person's name rather than the company's is usually shorter than founders fear and longer than they expect. It is also the only part of this that can stop being possible. Everything else here can be recovered late and at cost, but an ownership transfer on an account belonging to someone who has stopped answering email is a different category of problem, and the difference arrives on their last day.