The question a board member should ask about a practice this size, answered before they have to ask it.
org.tech is founder-led. What happens if Sam is unavailable?
The risk is real and should not be hidden. One principal operates this practice, and no amount of tooling makes that untrue. What can be true is that the risk is bounded by where the platform lives, by what is handed over as a deliverable, and by the fact that every deployment is a release of a versioned product rather than a bespoke build only its author understands. This page states the bound and then states its limit.
Key-person risk is the first thing a competent procurement process finds in a founder-led supplier, and the standard response is to imply depth that does not exist: the passive voice, "our team", a page of stock photography. The plain version is more useful to you. If the founder is unavailable, the service org.tech sells is interrupted for as long as that lasts.
That is the exposure, stated. What follows is the part a larger supplier usually cannot offer in return: the thing you paid for is not held by us in the first place.
The distinction the rest of this page rests on
There are two separate questions inside "what if you disappear". One is what happens to the platform, which is a question about where it runs and who owns it. The other is what happens to the service, which is a question about people. The first has a strong answer. The second has an honest one, and they should not be blurred together to make the second sound better.
If your AI vendor disappeared tomorrow, would anything still run? With us, you log into your own cloud and keep running.The test this page has to pass
Three things that bound the risk.
BOUNDS · THREE OF THEM
01 Structural
You own the account.
The cloud account is yours: root credentials, billing, the resources and the data inside it. The provider invoices you directly and we hold no copy of your material on our infrastructure. There is nothing for us to hold hostage, deliberately or by accident, because possession was never the shape of the relationship.
At the Baseline posture there is no cross-account role for us at all. On Standard and Strict our management access is scoped and session-capped, and it exists inside your account, which means removing it is your decision to make and yours to carry out.
An engagement produces infrastructure as code, runbooks and an architecture record, because those are the things another provider would need to assume the work. They are written during the engagement rather than promised at the end of one, which is the only version of that promise worth anything.
The architecture record is not a drawing somebody maintains by hand: every deploy emits a discovered model from what was actually synthesized, reconciled against the drawn diagram.
Your deployment is a tagged release of one product, layered with your parameters. It is not a one-off system whose logic lives in the head of the person who wrote it, and the version it is running is stamped into health endpoints rather than remembered.
That is what makes a successor's job an engineering task instead of an archaeology project. The same property is why a practice this size can operate production systems at all.
The reason the first answer is strong is geographic, in a sense: the running system is not on our side of the line. Nothing in the diagram below that keeps working needs an org.tech server, an org.tech key or an org.tech person to be awake.
org{•}tech/ continuity / what-survivesKeeps running · stops · needs a person
Your cloud account Keeps running with nobody at org.tech
Sign-inYour user directory, in your account
Content policyA deny in cloud identity policy, still enforced
Chat and knowledgeMetered per person
Your data at restDocuments, sessions, the index
ModulesBusiness applications your people use
AdministrationUsers, roles, grants, quotas, editable at runtime
org.tech Stops
Releases and deploysNew versions stop arriving
Drift, diff, acceptance runsNobody is checking after a change
Catalogue refresh, cost watchNobody is watching the bill
The direct lineThe part with no substitute
The solid zone is yours and it does not depend on us being reachable. The red zone is the service, and it is the part that stops. Note what is deliberately on the left: your administrators can already add people, change roles and grants and adjust quotas at runtime, with no redeploy and no call to us.
Continuity·Simplified. The full topology is on the architecture page
Three columns, plainly set out.
SCENARIO · IF WE VANISHED TOMORROW
Area
What keeps working
What stops
What you would need
The running platform
✓Everything in your account, unchanged
✕Nothing, immediately
Nothing on day one
People and access
✓Your administrators add users, change roles, grants and quotas at runtime
✕Our help with unusual changes
An administrator who has done it before
Governance controls
✓The content policy, the denies and the audit record stay in force
✕Changing the policy, the tier or residency
Someone who can cut and deploy a release
Updates and fixes
✕Nothing new arrives
✕Releases, drift checks, acceptance runs
A cloud engineer, the source and the runbooks
Modules and new capability
△Existing ones keep serving your people
✕Admitting a new module, which is set at deploy time
A developer plus the deploy path
Cost
✓Your provider keeps billing you directly, unchanged
✕Our cost watch and budget review
Someone reading the bill monthly
Your data
✓It never left your account, so there is nothing to retrieve
✕Nothing
Nothing
Row three is the one people miss. Deploy-time parameters such as the content policy, the model allowlist, the posture tier, residency and module admission deliberately cannot be changed from inside the running system, by your administrators or by us. That is a control in normal operation and a dependency in this scenario, and both halves are true at once.
What we are doing about it, carefully stated.
CONCENTRATION · PRINCIPLE, NOT PLAN
No dates, no names, no promises
Two principles, and deliberately nothing beyond them.
A continuity page that announced a hiring plan would be making a promise with somebody else's calendar. So here are the two principles that actually govern the decision, and nothing that would read as a commitment we have not made.
01
Encode judgment into standards and tooling. Every time a decision becomes a validator rule, a test that fails the build, a factory precondition or a written runbook, it stops being knowledge held by one person. That is the same discipline that makes the product defensible, applied to the company.
02
Hire against contracted demand, not against hope. Capacity is added when committed work requires it, rather than to look larger during a sales process. A practice that staffs ahead of its commitments is carrying a cost its clients eventually pay for.
What you will not find here is a target headcount, a named successor, a date or a roadmap. Announced early, those stop being intentions and start being things a buyer is entitled to hold us to.
DeploysA factory that refusesTag not on the mainline, or a dirty tree: refused
GovernanceTests that fail the buildIf a deny is weakened, the build stops
ArchitectureDiscovered, not drawnEmitted on every deploy and reconciled
ControlsOne typed objectIt builds the infrastructure and generates your plan page
OperationsA dated journalWritten after the work, not from memory
ModulesManifest, validator, scaffoldThe contract is machine-checked, not explained
Transferable by construction·Each row is a thing a successor inherits
Where the reassurance stops.
THE LIMIT · SAID OUT LOUD
A
A successor needs real cloud engineering skill.
"You keep the platform" is true and it is not the same as "anyone can run it". Operating this afterwards means a competent cloud engineer who can read infrastructure as code, cut and deploy a release, and reason about identity policy. A managed IT provider who has never worked at that layer would struggle, so it is worth knowing which description fits your own people before the question is urgent.
Honest limitSkill, not access
B
It is built on one cloud.
The platform is deeply built on a single cloud provider. Moving it to another would be a rebuild rather than a migration, so a successor inherits the same dependency we have. What is genuinely portable is the model choice: switching which model serves a workload is configuration inside the same governed route.
Neither limit is something we hold back. You have the account, the root credentials, the source and the runbooks from the first deploy; what a successor has to bring is cloud engineering capability. If a formal exit plan matters to your board, make it part of the assessment and it is written against your own deployment. Ownership and exit.
What a board asks.
QUESTIONS · CONTINUITY
01Is our data at risk if org.tech ends?
No, and not because of a policy: your documents, sessions, index and usage records sit in storage inside your own cloud account, in the region you chose. We hold no copy on our infrastructure. There is no extraction project, no export request and no retention period to wait out, because nothing of yours was ever in our custody.
02Would the platform keep working the next morning?
Yes. Sign-in, chat, the knowledge base, the modules your people use and the governance controls all run in your account and do not call home. What stops is the stream of releases, the checks around changes, the catalogue refresh, cost watch and the direct line. Nothing switches off, and nothing new arrives.
03Can we write an exit into the agreement?
Yes, and it is a reasonable thing to ask for. The deliverables that make an exit workable are already part of the engagement: infrastructure as code, runbooks and the architecture record. Raise the specific board requirement in the assessment and it gets written against your deployment rather than as a generic clause. Ownership and exit covers the standing position.
04Could our own IT team take it over?
Day-to-day, they already do: users, roles, grants and quotas are theirs to run at runtime with no involvement from us. Taking over the platform itself is a different skill level. If your team has genuine cloud engineering capability, the runbooks and the infrastructure as code are written for exactly that reader. If it does not, you would be hiring that capability or contracting another provider, and it is better to know which of those it is before you need it.
05Does this argument work in reverse, if we leave you?
It is the same argument, which is the point. The monthly fee buys the service rather than access, so cancelling costs you us and nothing else. A supplier whose continuity story only works while you keep paying has not built one.
The claim this page exists to make
Founder-led is a risk. The answer is not a promise, it is an architecture.
A supplier this size cannot make key-person risk disappear, and should not try. What it can do is make sure the thing you depend on is not the supplier.
01
The platform is in your account. It runs whether or not we are reachable.
02
The handover exists already. Infrastructure as code, runbooks and a discovered architecture record.
03
The limit is stated. A successor needs real cloud engineering skill, and the runbooks are written for that reader.
⎯⎯ Book the strategic assessment ⎯⎯
Your private AI, inside your control ·
A bounded $2,500 engagement that can include the exit plan your board will ask for, written against your own deployment.