If you are still validating a single-player workflow, a simpler boilerplate plus a later migration can beat starting with full org switching. Buy multi-tenant when B2B workspaces are the product.
Isolation patterns to look for
- Shared database with tenant_id columns (common and fine when enforced everywhere).
- Schema-per-tenant (rarer in starter kits; demand clear migrations).
- Middleware that sets tenant context from subdomain or path.
- Row-level security in Postgres if the kit claims it - verify policies ship.
Membership and invites
Real B2B products live or die on invites. Look for email invite tokens, role assignment, and what happens when a user belongs to multiple orgs. Kits that only have a tenant enum on signup are not finished.
Filter multi-tenant-systems on Twenty, then read setup instructions for invite emails and Stripe customer-per-workspace mapping.
Billing per workspace
- One Stripe customer per org is the usual mental model.
- Seat-based plans need webhook updates when members join or leave.
- Owner vs billing admin roles should be explicit.
Security review questions
- Can a crafted ID in a URL read another tenant's row?
- Are background jobs tenant-scoped?
- Do file uploads live under tenant prefixes?
- Are audit logs tagged with org id?
When not to buy multi-tenant yet
- You have zero paying teams and a solo workflow.
- Your differentiation is not collaboration.
- You cannot explain who pays the invoice inside an org.
Migration path from single-tenant
Many successful products add orgs later. If you start single-tenant, keep user_id foreign keys clean and avoid global singleton tables. That makes a future tenant_id migration possible without a rewrite.
Agencies and B2B SaaS should prefer this category early. Indie consumer apps usually should not.