Organizations Teams Laravel Package

Product Decisions This Supports

• Build vs. buy for core tenancy plumbing. This package covers the unglamorous but mandatory slice of B2B SaaS: teams, memberships, invitations, ownership, and switching between organizations. If our roadmap includes org accounts, this is a legitimate "buy" candidate to evaluate against a 2–4 week internal build.
• Feature sequencing for multi-tenant launch. The presence of "current-context boundaries" as a first-class concept forces an explicit product decision early: is tenancy resolved per-request (subdomain, header, session), and does every resource inherit that scope? Getting this wrong is expensive to retrofit.
• Ownership and lifecycle rules as product policy. Ownership transfer, invitation expiry, and membership roles are policy decisions, not just code. Having a package surface these as named concepts makes it easier to write acceptance criteria with design and support.
• Pricing and packaging inputs. Seats-per-org, invitation flows, and team switching directly shape how we meter usage and model plans (per-seat vs. per-org vs. per-team).
• Roadmap hook points. A clean membership/invitation abstraction is the seam where SSO, SCIM provisioning, audit logging, and granular roles will later attach — worth reserving design space for now even if we don't build them.

When to Consider This Package

Consider it when:

• We are greenfield on Laravel and need org/team primitives within a sprint rather than a quarter.
• Our tenancy model is the common case: user belongs to N orgs, one active at a time, invite-by-email, single owner.
• We can absorb vendor risk — a small team, a timeboxed spike, and willingness to fork or replace.
• We wrap it behind our own domain interfaces so the dependency is swappable.

Look elsewhere when:

• Adoption signals matter to the decision. Zero stars, zero dependents, and no known production users mean no community validation, no battle-tested edge cases, and single-maintainer risk. That is a real cost, not a cosmetic one.
• We need fine-grained RBAC/ABAC, policy inheritance, or per-resource permissions beyond membership roles — spatie/laravel-permission plus custom tenancy is the more common path.
• We need enterprise requirements now: SSO/SAML, SCIM, audit trails, data residency, or hard tenant isolation at the database level (consider stancl/tenancy).
• We want a batteries-included starter kit; Laravel Jetstream's team support is better supported and better documented.
• We cannot accept an unmaintained dependency. Verify the release history — the listed last-release date is anomalous relative to today, which itself warrants a check of commit activity before we rely on it.

How to Pitch It (Stakeholders)

For executives: There is a small, MIT-licensed Laravel package that implements the standard organization/team model — memberships, invitations, ownership, and switching — which is roughly 2–4 weeks of engineering we would otherwise spend before shipping a single customer-facing feature. It is not proven: no stars, no dependents, no visible production users. Recommendation is a one-to-two day spike, not an adoption decision. The spike costs little and either saves us weeks or tells us to build it ourselves with confidence.

For engineering: The domain fit is good and the scope is honest — it stops at the tenancy boundary rather than sprawling into billing or permissions. Treat it as a reference implementation and a possible accelerator. Integrate behind our own interfaces, pin the version, and assume we may fork. The real value is the vocabulary (current-context boundaries, ownership transfer, invitation lifecycle) as much as the code.

Decision requested: Approve a timeboxed evaluation. No production commitment until we have reviewed the source, confirmed maintenance activity, and validated the tenancy model against our roadmap.