Teams and Members
Teams are modeled as organizations. An organization owns projects, billing, invitations, and the member roster. Every project keeps its existing project_id, but access is granted through organization_members.
Plans
Teams are available on Pro and Enterprise.
| Plan | Teams |
|---|---|
| Hobby | Solo workspace |
| Starter | Solo workspace |
| Pro | Invite teammates and share projects |
| Enterprise | Teams plus SSO and SOC 2 controls |
The product enforces this in three places:
- The admin UI hides the invite form and shows an upgrade prompt.
- The API returns
402 feature_not_in_planfor invitation attempts below Pro. - The database rejects invitation inserts with the
invitations_plan_gatetrigger.
Roles
| Role | Use |
|---|---|
| Owner | Billing, plan changes, member management, last-owner protected |
| Admin | Invite users, manage project settings and integrations |
| Member | Work in shared projects and triage reports |
| Viewer | Read-only access to shared project data |
Invitation Flow
- An owner or admin opens Members in the admin console.
- They invite an email with a role.
- Mushi creates an
invitationsrow with a one-time token and sends a Supabase Auth invite email when possible. - The invitee signs in and opens
/invite/accept?token=.... - The
accept_invitation(token)RPC verifies the email, locks the invite row, inserts the membership, and marks the invite accepted.
The accept step is atomic so double-clicks, expired tokens, and email mismatches fail cleanly.
Last updated on