Designing multi-tenancy in Petal Pro

Nearly every SaaS app becomes multi-tenant eventually. One person signs up, then they want to invite their team, and suddenly you need organisations, roles, invitations, and a way to scope every piece of data to the right tenant. Retrofitting that later is one of the most painful migrations there is. So Petal Pro bakes it in from the start.

The model is deliberately simple. Users belong to organisations through memberships. The membership is where the role lives, so the same person can be an admin of one org and an ordinary member of another. Routes are scoped by an org slug, so /acme/dashboard and /globex/dashboard are naturally separate, and the current org is always obvious from the URL.

Billing hangs off the same structure. You can bill per user or per organisation, because real products do both, and which one you want is a config choice rather than a rewrite. A solo tool might charge the individual. A team product charges the org. Petal Pro doesn't decide that for you.

None of this is exotic, and that's the point. Multi-tenancy is a solved problem, but only if someone solved it before your deadline. The value isn't cleverness, it's that the boring, load-bearing decisions are already made in a sensible way. You can invite a teammate on day one and get back to the part of the product that's actually yours.