Founder Continuity: Rehearse a Day Without You

A founder continuity rehearsal tests whether an authorized backup can keep essential work moving when you are unavailable. Choose a bounded scenario, give the backup their own approved access and written instructions, then watch them find the next obligation without your help. Record every blocked step and test the repair.

Imagine a customer asking whether tomorrow’s migration is still happening. Your backup can see the calendar, but the hosting account sends approval requests to your phone. The invoice lives in your personal inbox. The customer believes they hired a business; the instructions still assume they can reach you.

A recent Show HN discussion about Death Plan Switch brought that dependency into view. Its author described an earlier hospitalization and difficulty getting information to a technical colleague. That is a personal account, not evidence about how often founders face this problem. It does make a useful question concrete: what could someone do after receiving your emergency message?

The following exercise focuses on temporary unavailability. It helps you find operational gaps while you can still fix them. It does not settle company ownership, inheritance or anyone’s authority to make decisions for you.

What should a founder continuity rehearsal prove?

Your rehearsal should prove that another person can perform a few named, authorized tasks with the information you have already provided. Start with a small slice of the business that has a real consequence if neglected.

You might choose answering an urgent customer request, finding the next hosting bill and identifying an interview that needs a new host. Each task needs an observable result. “Understands the business” is too broad to assess; “finds the invoice, its due date and the approved payer” gives you evidence.

NIST’s contingency planning guide covers business impact analysis, recovery responsibilities, exercises and plan maintenance. It was written for federal information systems in 2010. The smaller rehearsal here borrows those planning ideas; it is an editorial adaptation for founders, not a NIST certification checklist.

Write your scenario before inviting the backup:

You cannot reach me through the end of the next working day. Keep existing commitments visible, identify urgent risks and prepare the approved responses. Stop before any action outside the written scope.

That gives your backup a workable assignment. They do not need to impersonate you, infer your wishes or diagnose why you are missing. They need to follow a plan that names what they may do and who can decide anything beyond it.

Choose an observer if someone is available. Their job is to record where the backup hesitates, what they cannot find and when they ask you for an answer. If you run the exercise alone with your backup, take those notes yourself and resist supplying hints.

Separate the notification from the work that follows

An emergency notification tells someone to look at a problem. Your instructions and approved access determine whether they can respond.

The Death Plan Switch README describes a self-hosted email notification tool, rather than a document or business-credential vault. Its configuration does contain an SMTP password, stored in plaintext. It explicitly warns that it depends on its server, scheduler and mail service. Its documentation is evidence of the project’s stated design, rather than an independent reliability assessment or a recommendation to deploy it.

This distinction matters even if your alert reaches everyone. “Contact our backup developer” leaves several unanswered questions: has that person agreed, are they available, can they authenticate and do they know which customer commitments take priority?

Make the first instruction useful on its own. Name the person coordinating the response, where the approved operating instructions live and how recipients can verify an unexpected message. Put a review date on the instructions so your backup can recognize an old copy.

Check the route to those instructions. If opening them requires your unavailable phone or an approval from your locked account, the message has delivered a dead end. During the exercise, ask the backup to retrieve the current copy using their own identity.

Google’s Inactive Account Manager documentation illustrates another boundary: it describes sharing selected account data or notifying contacts after inactivity. Receiving data is different from being able to operate every business account connected to it. Keep each provider’s documented process separate from your own expectations.

Name a backup and define what they may do

Your backup needs an agreed role, a reachable contact method and a written scope. A name in a folder is incomplete until that person has accepted the work.

Ask them to repeat the assignment in their own words. Can they cover customer communication? Can they inspect infrastructure? Are they comfortable finding bills but unable to approve payment? Those differences should change the plan before an emergency does.

Separate routine work from decisions that require another approver. An illustrative scope might look like this:

This table is a planning example. Adapt the actions to the authority your business has already established and the controls each provider supports. Resolve questions about signing, spending or ownership through the appropriate company process before treating them as available powers.

You may need different people for technical work, payment and communication. Give each person the information their role needs. A backup handling interview schedules rarely needs broad access to payroll files or customer exports.

If nobody can cover a responsibility, record it explicitly. That is a useful result. It tells you where you need an agreed pause, a narrower service commitment or additional help.

Build an obligation register before a credential list

List the work that would become urgent during your absence, then connect each obligation to its system and authorized operator. Start with consequences and deadlines.

A credential list can be extensive while missing the reason any account matters. Your backup needs to know which service supports paying customers, which renewal is approaching and which unanswered message has a promised response date.

Use a compact register:

Keep secrets in the approved credential system. The register should point to the controlled location, without copying passwords, recovery codes or private keys into a general document. Confirm that your backup can reach the entries they are permitted to use.

For every recurring bill, ask what would happen if the usual payment failed. Automatic payment is a setting to inspect, not a substitute for an identified payer. During the rehearsal, locate the current payment method and contact route without making an unnecessary purchase.

Give domains their own row. Website hosting, DNS management and domain registration may involve different accounts. Let the backup explain which account controls each part of your setup. If the explanation depends on your memory, add the missing map.

Use the business impact questions in NIST SP 800-34 Rev. 1 as a prompt to rank these obligations. Decide what interruption you can tolerate for each one. Set your own targets from commitments and consequences; there is no universal safe delay for a small company.

Test access with the backup’s own identity

A successful founder login proves little about your backup’s access. Have them use their own account and authentication method, then open the specific record required by the task.

Choose read-only checks where they can answer the question safely. The backup can inspect an invoice, find an existing customer thread or open a domain’s renewal details. A rehearsal does not need a live DNS change or a payment to demonstrate that the instructions are incomplete.

Check the entire path. A team invitation may still be pending. An account may open while the relevant project remains restricted. A billing page may require a separate role. Record the exact blocked action instead of writing “access problem.”

Try the exercise without borrowing your already authenticated browser session. Otherwise, your session can conceal the very dependency you want to discover. If a sign-in needs your approval, stop there and record which approved alternative is missing.

Then check whether the backup can interpret what they find. Opening a dashboard is insufficient if they cannot tell which environment serves customers or which invoice belongs to the production account. Instructions should name the account and explain how to recognize it.

Your self-hosting staffing plan can help identify technical responsibilities worth testing. Keep this exercise narrower: choose the next few obligations a person would face while you are away, and verify their route to each one.

Run the first day without coaching

Give the backup a realistic prompt and observe their next steps. Every answer you supply during the exercise should become a recorded dependency.

Here is a suggested session sequence, not a benchmark:

1. Retrieve the instructions. The backup finds the approved copy and confirms its review date.
2. Identify urgent work. They use the obligation register to select what needs attention first.
3. Open the required accounts. They authenticate with their own approved identity and inspect the named records.
4. Prepare a response. They draft a customer reply, payment escalation or interview reschedule within their scope.
5. Explain the stop points. They identify what requires another person’s decision.
6. Record the gaps. You agree who will repair each blocked step and how to retest it.

Use a test customer and consenting colleagues for any message you actually send. Mark drafts clearly. Keep the exercise out of a real customer’s inbox unless that contact has deliberately agreed to participate.

Add one complication after the basic path works. Perhaps the primary backup cannot attend, or the instruction link is unavailable. Ask what happens next. Stop when you have enough evidence to identify the missing route; manufacturing a larger outage adds little to an unresolved first step.

A separate recovery exercise can later test whether a backup restores correctly. Locating a backup file in this session does not establish that it is complete, current or usable. Keep those results distinct in your notes.

NIST’s testing and exercise guidance distinguishes discussion exercises from functional tests. Use the same care when describing your result: you rehearsed the named actions under the stated conditions. You have not demonstrated recovery from every possible disruption.

Turn each blocked step into a repair and retest

The useful output is a short list of observed failures with owners and follow-up checks. A completed meeting is not evidence that the plan works.

Capture enough detail that someone can reproduce each problem:

These are illustrative failures, not findings from a measured study. Your register should contain what happened in your exercise, including partial success and work you did not attempt.

Give repairs a named owner and a due date. Retest the blocked action after the change. If the task still needs a hint from you, keep it open and improve the instruction or access arrangement.

Schedule another review when the person, provider or responsibility changes. New authentication settings can invalidate an old path; a different backup may need different context. NIST’s plan maintenance guidance includes reviewing and updating plans as systems and responsibilities change.

Finish by telling participants that the rehearsal has ended. Remove temporary test access where applicable, retain the agreed operational access and record the remaining limitations. Your result should be easy to state: these tasks worked, these tasks were blocked and these tasks were outside the exercise.

Use Kit to rehearse the hiring work you already share

For hiring continuity, choose an authorized teammate and test whether they can find the next candidate commitment in the shared records. The immediate concern is the person waiting for an interview, a reply or a decision.

Kit’s team roles distinguish account responsibilities from product access. A Billing Admin can manage the Kit subscription and starts without module access. A Hiring admin has Hiring permissions; that role does not by itself grant account billing control. Use the role needed for the task and check the resulting access.

For a hiring rehearsal, ask the authorized teammate to sign in with their own account and open the relevant job, candidate application and stage review themselves. Have them explain what is scheduled, what evidence has been recorded and where they would stop for a decision. Team access controls and item assignments determine what they can reach.

Kit does not provide a founder dead-man switch or an emergency inheritance process. A second account Admin can hold operational permissions, but account ownership transfer requires the current owner. Do not make an absent founder’s ownership transferable merely by writing that expectation into a handover document.

Choose one hiring obligation and rehearse it while you are available. If you are evaluating Kit, you can start a trial and test that shared workflow with a teammate. The useful result is a verified next action, plus a clear record of what still depends on you.