Every SaaS with both solo users and teams eventually answers one question: who owns things? The answer gets baked into the schema early, and it’s one of the most expensive decisions to reverse. We just made it for trigger.fyi, so here’s the field guide we wish we’d had.

#The three models

1. User-only. Everything belongs to a person. Pushover is close to this. Simple schema, happy solo users. Then the first team arrives: shared credentials, a company alert tied to one employee’s email, and no clean handoff when that person leaves. If artifacts in your product can outlive a person’s involvement, user-only ownership eventually strands them.

2. Workspace-first. Slack, Notion, and Linear start with the workspace as the main container; solo users get a workspace of one. That makes team billing and roles easy — then forces exceptions for guests, shared pages, channels, and cross-workspace collaboration. The other costs: solo users carry team machinery they never asked for, and identity fragments (“which workspace am I in? which email did I use for this one?”). Workspace-first fits products that are inherently collaborative — a chat tool for one person is a note-taking app.

3. Namespaces — personal and org as peers. GitHub’s model. A person owns things; an organization owns things; both are namespaces with the same shape, and artifacts transfer between them — GitHub moves a repo between a user and an org with issues, webhooks, and deploy keys intact. Vercel is adjacent: users work in a default Hobby context, and teams become the collaboration and billing container. Namespaces are the most schema work of the three, because they force a distinction the other models blur: ownership (billing, limits, ultimate control) versus access (who can see and use the thing).

There’s a fourth pattern that arrives later regardless of which model you pick: domain claiming. Once companies adopt you, someone asks for SSO, auto-join by email domain, and admin takeover of assets employees created before the company showed up. It’s an extension, not a model — but if your ownership story can’t answer “an employee made this before we claimed the domain,” enterprise deals will ask the question for you.

#How to choose: four questions

Who is the buyer, and who is the user? If they’re always the same person, user-only can last. The moment a company card pays for an employee’s tool, you need an owner that is not a human login.

Do artifacts outlive people? A repo, a production API key, an alert channel — these belong to the work, not the person who clicked “create.” If your product has these, ownership must be transferable to something durable.

Is sharing per-artifact or all-or-nothing? Workspace membership is a broad gate. If users need to share one artifact with an outsider, you still need object-level access — guests, shares, invites, memberships — whichever model you start from.

The transfer test. A solo project becomes a company project. Do the API keys, URLs, history, and subscribers survive the owner change? If the honest answer is “recreate it under the team,” your model taxes the exact moment expansion should be easiest.

#What we picked, and the rule that made it work

trigger.fyi chose namespaces because an app here is a production artifact: a send key wired into CI, plus operational history someone may need months later. It outlives the intern who set it up. So:

• Every app is owned by exactly one billing entity — a person or an org. Ownership carries the plan and limits.
• Access is separate: app members can read history and receive notifications on their own devices, with their own mutes. Sending stays a separate credential — inviting a teammate never hands over billing or the send key.
• Going solo→team is a transfer, not a rebuild: the org takes ownership; the key, the history, and everyone’s subscriptions don’t move, because they never belonged to the owner in the first place.

And the rule that keeps the whole thing honest: a solo user must never see the org machinery. No “create your workspace” during onboarding. No empty team settings tab for one user. Org concepts appear at exactly one moment — when a second person shows up and the product has something real to organize.

If you’re building on better-auth, the organization plugin gives you orgs, members, and roles out of the box. It does not decide what owns an artifact, what transfers, or which permissions belong to the thing versus the person. That’s the actual decision.

---

Related: What is trigger.fyi · Notification as a service · Backend push notifications