Multi-tenant context switching for serial founders

A growing fraction of the founders I work with run more than one company at a time. Sometimes it's intentional: an operator running a venture studio, a GP with two thesis investments, an indie hacker shipping a portfolio of small products. Sometimes it's accidental: the side project that turned out to be a real business, the advisor relationship that grew into a fractional COO role, the family business you can't quite let go of.

If you're in this group, you know the problem: every productivity tool was designed for one user / one company. Your AI assistants, in particular, are hilariously bad at remembering which hat you're wearing today.

This post is about how KlyHub solves that — and why "multi-tenant by default" turned out to be the most consequential architectural decision we made.

The single-tenant trap

Most AI tools have a context window and call it a day. You paste in your company info. The model uses it for this conversation. New conversation, fresh paste. Want to talk about a different company? Hope you remember which context you loaded.

This works for the median user (one job, one company) and fails dramatically for the serial-founder population. We've watched smart people do things like:

• Ask Claude to "draft a board update" without specifying which board, and get a generic mash-up of two unrelated companies.
• Push code into the wrong repo because Cursor inferred from "context" that the active project was the OTHER startup.
• Send a competitive analysis email that quoted the wrong customer because ChatGPT had three customers from three companies all loaded in long-term memory.

These aren't user errors. They're tool design errors. The tools assume single-tenant identity.

Multi-tenant from the database up

KlyHub treats every organization as a fully isolated tenant. That's not just a UI affordance — it's enforced at every layer.

At the database, every row carries a tenant_id. Every query opens a transaction with SET LOCAL app.tenant_id = '<id>'. Postgres' row-level security policies enforce that you can only see rows matching the bound tenant. A bug in our application code can't accidentally leak — the database refuses.

At the API, every request resolves a tenant from the URL path (mcp.klyhub.com/v1/{tenant-slug}), authenticates against that tenant specifically, and never escapes its boundary. An OAuth token issued for Tenant A literally cannot read Tenant B data, even if the user is the owner of both.

At the MCP server, each tenant runs as a logical instance with its own URL. When you wire Claude Desktop to multiple tenants, each appears as a separate connector — klyhub-acme, klyhub-otherco. You can scope a conversation by mentioning the connector by name.

In CI, we run a cross-tenant integration test on every commit. It tries to read Tenant B's data from inside a Tenant A session. It must return zero rows. The build fails if that invariant breaks. Multi-tenancy isn't a feature we shipped — it's a property we test.

The serial-founder workflow

Here's what a typical day looks like for a serial-founder KlyHub user:

Morning: open Claude Desktop. Ask "what's on my plate today?" Claude calls tools from klyhub-acme (your primary startup) and produces a prioritized list grounded in Acme's Operations layer (rituals, open experiments, hiring status).

Mid-morning: hop into a board call for Otherco (your side investment). Open a new Claude conversation. Type "use klyhub-otherco — summarize the last three Memory entries." Different company, different context, zero confusion.

Afternoon: a customer escalation on Acme. Back in klyhub-acme. Claude searches the Memory layer for "incident", finds the relevant postmortem, suggests the corrective-action playbook from Operations.

Evening: writing a strategic memo for the venture studio. Open the klyhub-studio tenant. Claude has the studio's thesis, portfolio companies, and check sizes — all separate from Acme and Otherco.

No paste. No "let me give you the context first." No accidental cross- contamination.

The owner-transfer story

Multi-tenancy also makes the handoff story work. When you decide to step away from a company you've been running:

1. Promote a new owner inside KlyHub (one click in /settings/members).
2. The new owner inherits the full knowledge base — Core, Market, Motion, Operations, Memory.
3. Stripe customer ownership transfers; Stripe customer record stays intact (we update the billing email, not delete the customer).
4. You leave the org cleanly. Your remaining tenants are unaffected.

Industry standard, well-understood — but it requires a multi-tenant base that doesn't assume "one company per user."

The deletion story

Multi-tenant also means delete one company without deleting yourself. You can schedule deletion of a single organization (30-day fully-usable grace period, persistent cancel banner, hard delete on day 30) without touching your account or any other tenants. The deletion runbook walks through every personal-data store (Postgres, R2, Stripe, Resend, PostHog, Sentry) per organization, with audit-grade verification logs retained for seven years.

Try doing that in a single-tenant tool. You can't.

Why this matters

The serial-founder demographic is small but growing fast. Operators are mobile. Capital is patient. The "one career, one company" pattern is dissolving into "many simultaneous relationships, each non-trivial."

The tools that serve this demographic in 2030 will be the tools that treated multi-tenancy as a first-class architectural primitive in 2026 — not the ones that bolted it on later as an enterprise tier.

KlyHub is in the first group. If you're running more than one company at once, try it. The mental relief of having your AI tools actually keep your contexts separate is hard to unsee.