Continuity and key custody
NOT YET IN FORCE. Requires: Steward appointed, credential escrow configured.
Last reviewed 2026-08-18. Tested: never.
NOT YET IN FORCE
Takes effect when a Steward has been appointed and credential escrow is configured per section 5. Until then, no continuity plan exists and customers should rely on section 2 only.
1. The risk, stated plainly
Saberra is one person. If Rick Broider is unavailable, no one else can currently deploy the platform, access the credentials, answer a customer, or wind the company down. This is the largest uninsured risk Saberra carries and it exists independently of any audit.
A solo founder cannot have a successor who runs the company. What a solo founder can have is a continuity steward who can reach the systems, tell the customers the truth, and close things cleanly. That is what this document provides. It is a wind-down and handover plan, not a succession plan, and calling it succession would overstate it.
2. Why customers are already protected, mostly
This part is true today, with no plan required.
Customer records live in the customer's own Notion workspace, under the customer's own account. Saberra reads and writes them. Saberra does not hold them and could not withhold them. If Saberra disappeared without warning tonight:
- Every customer's records would remain in their workspace, intact, readable, and theirs.
- No export, migration, or cooperation from Saberra would be required.
- What would stop is the capture and extraction: new email would no longer become records.
- Billing would continue until the customer cancelled, which is the one real harm and section 6 addresses it.
This is a consequence of the architecture, not of a promise. It is the reason a solo-founder company can responsibly sell institutional memory at all.
3. Trigger
The plan activates on unresponsiveness, which is observable, rather than on incapacity, which requires a judgment no one is positioned to make.
| Day | Event |
|---|---|
| 0 | Steward is unable to reach the founder through two channels, or is notified by a third party |
| 7 | Steward attempts contact again, including the emergency contact on file |
| 30 | Continuity period begins. Steward requests credential escrow release |
| 30 + escrow waiting period | Steward gains access, notifies customers per section 6, suspends new billing |
| 90 | If still unresponsive, Steward executes wind-down or transfer per section 7 |
5. Key custody
Credentials are held in a password manager with a built-in emergency access feature. The Steward is configured as an emergency-access recipient with a waiting period of 30 days, so a request grants access only if the founder does not decline within that window.
Note, and it is a live gap: no password manager is currently named in Saberra's own credential documentation. Selecting one and migrating credentials into it is a prerequisite for this section, not a detail of it.
Held in escrow: password manager master access, domain registrar and DNS, hosting and database provider, payment processor, customer list with contact details and contract status, and this document set.
Not held in escrow, deliberately: customer Notion workspaces. Saberra holds delegated access, not ownership, and that access dies with the customer's own revocation. There is nothing to hand over because there is nothing held.
6. What customers are told, and when
At day 30, every active customer receives a notice that says, without softening:
- Saberra's founder is unreachable and the continuity plan is active.
- Their records are in their own workspace and are unaffected.
- Capture and extraction may stop; here is how to check.
- Billing is suspended from today, and unused prepaid time will be refunded.
- Here is the Steward's contact, and here is the date by which a decision will be made.
8. What this does not fix
The company still stops working the day the founder does. Nothing in this document keeps Saberra operating, and no document can. What it does is guarantee that customers keep their records, learn the truth quickly, stop being charged, and get a clean ending.
The real fix is a second person who can operate the platform. That is a hiring decision, not a governance one, and until it happens this document is the honest substitute.