The week your only engineer resigns

The message is short and it is not really about you. The one engineer you have — the person who wrote every line of the thing your customers log into — has taken something else, and you have two weeks. The instinct is to open a job board that afternoon. That instinct is not wrong so much as badly ordered, because you are running two clocks of very different lengths. Replacing the person is measured in months. The window in which they will still answer a question is measured in days, and almost everything that is genuinely unrecoverable is on the short clock. This week is about the short clock. Nothing else.

Know the base rate first, because it explains why you have no plan. In July 2026, at private establishments with 1 to 9 employees, the quits rate was 1.2 percent and 286,000 people left — against 2.1 percent and 2,866,000 across the total private sector (US Bureau of Labor Statistics, Job Openings and Labor Turnover Survey, Table 7: levels and rates by establishment size class, seasonally adjusted, July 2026 preliminary, released 1 September 2026). Quitting is rarer at the smallest employers than anywhere else in the private economy, which is exactly why no founder has rehearsed it: the event is rare where it is catastrophic and common where it is survivable. The same table carries the other half of the picture. Those 1-to-9-employee establishments held a job openings rate of 5.7 percent while hiring at 3.0 percent. Small firms carry vacancies they do not fill. You are about to become one of them, and the plan has to assume that.

So spend the notice period buying answers, not code. The code is already yours and it is not going anywhere; it will still be sitting in the repository in March. What leaves on the last day is the reasoning — why the payments table has two status columns, which of the three cron jobs actually matters, what the manual step is before the monthly export, which failure the retry logic exists because of. None of that is reconstructable by reading, and all of it is cheap to capture while someone is still being paid to answer. Put a document in front of them on day one and treat filling it in as the job, ahead of any feature, ahead of finishing whatever is in flight. A half-finished feature costs you a sprint. A half-understood system costs you a year.

Ask for four things, in this order, and be specific enough that the answers are checkable. A map of the system in their words — every running piece, what it does, where it lives, what wakes it up. The decisions they made that they would expect a successor to argue with, each with the reason and with what would justify reversing it. The parts of the code that look wrong and are deliberate, which is the category that gets “fixed” by the next engineer in week three and takes production down in week four. And the failure modes they know about that never reached a ticket: the customer whose data imports badly, the report that is wrong on the first of the month, the thing they restart quietly. That last list is the genuinely irrecoverable one. Everything else can be rediscovered by reading. The known-bad edge case nobody wrote down gets rediscovered by a customer.

While that is happening, run the access and ownership pass, because it has a deadline the knowledge work does not. The control frameworks are unusually concrete here. NIST's personnel-termination control asks an organisation, on termination of employment, to “Disable system access within [Assignment: organization-defined time period]”, to “Terminate or revoke any authenticators and credentials associated with the individual”, to “Retrieve all security-related organizational system-related property”, and — the clause founders skip — to “Retain access to organizational information and systems formerly controlled by terminated individual” (National Institute of Standards and Technology, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5, control PS-4). Read those four in order. The first three are about what they can still reach. The fourth is about what you can reach afterwards, and it is the one that produces the disaster, because the accounts that matter are almost never in your name. The domain registrar. The Apple and Google developer accounts. The cloud billing owner. The email provider's admin role. The error tracker. The SMS gateway. Revoke before you transfer and you have locked yourself out of your own product with a polite security posture.

The register of what those accounts are, and who should hold each one, is the same list you should have received from any outside partner — the handover: what you must receive sets it out in full, and nine of its ten items are ownership and access rather than code. If you have never built that register, build it this week rather than next quarter. It is the only part of this that gets strictly harder after the last day.

Now the question almost nobody asks in time: was this person an employee, or a contractor? The distinction is not administrative, and it decides whether you own what they wrote. US copyright law treats a work as made for hire in two situations, the first of which is “A work prepared by an employee within the scope of his or her employment”. But the statute does not define employee, and the Supreme Court held in Community for Creative Non-Violence v. Reid that Congress intended the term “to be understood in light of agency law”, with courts relying “on the general common law of agency, rather than on the law of any particular [s]tate, to give meaning to these terms.” The Copyright Office then lists the questions that decide it, and they are the ones your arrangement actually turns on: “How was the creator paid? Did the hiring party offer employee benefits? Did the hiring party remove taxes from the creator's pay?”; “Does the creator have his or her own business? Was the creator able to hire and pay assistants?”; “Could the hiring party direct the creator when and how long to work?” (US Copyright Office, Works Made for Hire, Circular 30, revised August 2024).

If the answers put your person on the contractor side — they invoiced you, you did not withhold tax, they worked their own hours, they had other clients — then work made for hire almost certainly does not apply, because custom software is not among the nine categories of specially commissioned work the statute allows, and what you have instead is a licence whose terms nobody wrote down. The remedy is a signed assignment, and the week somebody is leaving on good terms is the last week you will ever have real leverage to get one. Ask for it alongside the documentation, in the same conversation, unemotionally. A year later it is a cold email to a stranger with no reason to reply, and a diligence question you cannot answer. What the clause has to say, and why the work-for-hire wording alone will not carry it, is the subject of what belongs in a white-label subcontract — written for agencies, but the drafting point is identical.

And be clear about the one lever you do not have. The temptation, when the documentation is thin and the last day is Friday, is to let the final payment drift until the handover looks complete. In Virginia the statute is flat: “Upon termination of employment an employee shall be paid all wages due him for work performed prior thereto; such payment shall be made on or before the date on which he would have been paid for such work had his employment not been terminated.” It also forbids making forfeiture a condition of employment — “No employer shall require any employee, except executive personnel, to sign any contract or agreement which provides for the forfeiture of the employee's wages for time worked as a condition of employment” — and it prices the mistake criminally: an employer who wilfully or with intent to defraud fails to pay is “guilty of a Class 1 misdemeanor if the value of the wages earned and not paid by the employer is less than $10,000”, and of a Class 6 felony at $10,000 or more (Code of Virginia, § 40.1-29, Time and medium of payment; withholding wages, retrieved 28 September 2026). Check your own state, because the wording differs and the direction does not. Goodwill is the only instrument you have here, and it is a better one than the paycheck ever was.

Then the work in flight, where the default is worse than doing nothing. The reflex is to let the leaver finish what they started. Do not. A branch merged on the way out is one more region of the system whose only reader has gone, and it arrives at exactly the moment nobody can review it. Freeze new work from the day of the conversation. What is already deployed stays deployed; what is half-built goes on the map as half-built, described in writing, and waits. The exception is anything that is currently broken for a paying customer — and what you owe that customer while you are short-handed is a separate obligation with its own deadlines, set out in what you owe a customer when your product breaks. Even there the fix should be the smallest one that holds rather than the right one, because the right one is a design decision and the person who would have to live with it has not been hired yet.

Ship one deploy with them watching, and do not skip this because it feels beneath the moment. Have someone who is staying — you, if it is only you — take a one-line change from a laptop to production while the leaver sits and says nothing. Most founders discover here that the pipeline has a manual step, or that the deploy key is on a machine that is about to be wiped, or that the staging database has been restored from a backup nobody can currently produce. Every one of those is a ten-minute conversation this week and a three-day outage in November. The wider version of this exercise — the six drills that tell you whether a system can actually be operated by somebody other than its author — is how to tell if your system is production-ready.

Only now, with days six to ten, does the hiring question earn attention — and the honest first answer is that you should not make a permanent hire in this state. You are frightened, you are short-handed, and you have just lost the only person who could have helped you evaluate a candidate. Those are the three worst conditions under which to judge an engineer, and the failure mode is well known: the panic hire who interviews confidently, is unopposable because nobody else can read the code, and takes six months to be visibly wrong. What is judgeable by a founder who cannot read code is a much shorter list than most hiring processes pretend, and hiring your first engineer when you cannot judge one is that list. Read it before you write a job description, not after the second interview.

Between now and that hire, there are three honest shapes and they are not equally good. Buy continuity — a contractor or a firm whose brief is to take custody of a running system rather than to build anything, judged on whether they can operate it by week two. Buy judgement — someone senior and part-time to make the architectural calls you cannot, which is the right instrument only when the job in front of you is genuinely made of decisions rather than of presence, a distinction when a fractional CTO is the wrong answer draws precisely. Or buy nothing and freeze: keep the product running, ship no features, and accept a visible pause. The third option has the worst reputation and is frequently correct, because a frozen product loses less than a product being changed by someone who does not yet understand it.

Whoever takes custody, give them the same brief you would give anyone inheriting an unfamiliar codebase, and insist on the artefacts rather than the velocity: a written description of the system in their own words to compare against the leaver's map, an explicit list of what they have not understood yet, and one non-trivial change shipped end to end. The eight signals that actually decide what an existing application costs to own are in what to check before you inherit a React codebase, and none of them is how the code looks.

The structural fix is the one you will not want to hear in week one, and it is the only thing that changes the next time. Being one deep is not a staffing condition; it is an architecture. It shows up as decisions that live in a head instead of a document, an environment that exists on one laptop, a deploy nobody else has performed, and dependencies whose accounts are in a personal name. Each of those is cheap to fix while the person is still there and expensive to fix afterwards, and a firm that has run long engagements builds against it on purpose — the student information system we built for Concordia Colleges across 150+ branches is the shape of that: one owned data model, per-branch isolation and audit trails enforced in the platform rather than in anybody's memory, on a stack a second team can pick up. The related question of what you are renting rather than owning, and what that means when a dependency changes its terms, is do you own your product, or are you renting it? — and the departure week is when most founders find out the answer.

The last thing to write down is the one you will want least. Before the leaver goes, ask them what they would have fixed if they had stayed another six months, and what they think you are wrong about. You are getting an unguarded technical opinion from someone with no remaining incentive to manage you, which is a thing you will not be offered again for a long time. Write it down verbatim, even the parts that sting, and read it again in a month when you are calmer. Some of it will be personal. Some of it is the only honest technical review your product has ever had.

None of this is a substitute for the judgement you now have to exercise alone, and that boundary — what a founder must own and what is genuinely somebody else's craft — is set out in what a non-technical founder should own. If the map you end this week with is thinner than you can live with, the free production-readiness diagnostic will name what an outsider can see about your system from the outside, and the AI readiness assessment produces the written version of the map the leaver did not have time to finish. Either is a better first purchase than a permanent hire made in the second week. A startup software development company worth engaging will say the same thing, and will want to see the map before it proposes anything at all.