Laravel Membership Laravel Package

Product Decisions This Supports

• Build vs. buy for the "membership" domain. Every B2B product eventually needs "who belongs to what, with which role." This package makes that a concrete, low-cost comparison: adopt a ~1-day integration versus a 2–4 sprint internal build (schema, polymorphic pivot, role enum, hierarchy checks, guard integration, policy helpers, events, soft deletes, tests).
• Multi-container roadmap decisions. Because memberships are polymorphic, it supports a product model with more than one organizational container — workspace, team, project, board, client account — without a schema fork per container. This directly informs whether you ship "Projects" as a sub-entity of "Workspaces" or as a peer concept.
• Role model decisions. Enum-backed roles with a hierarchy let you decide, and later revise, whether roles are flat (owner/admin/member) or ordered ($role->atLeast(Role::Admin)). That is a pricing and packaging decision as much as an engineering one — seat tiers, admin-only features, enterprise gating.
• Authorization architecture. Policy helpers + guard integration determine whether authorization lives in Laravel policies (cheap, conventional) or in a heavier permission system. Choosing this narrows the later choice between "roles on membership" and "permissions on resources."
• Feature sequencing. Events and soft deletes make audit logs, invitation/acceptance flows, offboarding, and "removed member" history cheap follow-ons — useful for deciding whether audit trails land in v1 or v2.
• Representative use cases: B2B SaaS with workspaces/projects; agencies managing client accounts; marketplaces with two-sided membership; internal tools with per-team scoping.

When to Consider This Package

Adopt when:

• You need membership across two or more polymorphic container types — this is the package's core differentiator and where hand-rolling gets expensive.
• Your role model is coarse and enum-shaped (owner/admin/member/viewer) with ordering, not arbitrary permission sets.
• You want Laravel-native integration — policies, guards, events, soft deletes — rather than a parallel auth system.
• Your team is small and a thin, readable dependency beats a maintained internal module.
• You can accept a fork-and-own posture: MIT, schema + trait based, data portable, exit cost low.

Look elsewhere when:

• You need fine-grained, resource-level permissions (per-record sharing, permission inheritance, wildcard abilities) — that is spatie/laravel-permission territory, and pairing both adds confusion.
• You need invitations, UI, billing/seat sync out of the box — this is a domain layer, not a product feature; Jetstream/Spark or your own flow still owns that.
• You require database-per-tenant isolation — that is stancl/tenancy, a different problem.
• You need enterprise identity (SSO/SAML/SCIM, role sync from an IdP) — not in scope.
• Your procurement requires proven production adoption or a support contract. With 5 stars and 0 dependents there is no public evidence of production use; treat it as unvetted code.
• Maintenance cadence is unverifiable. The listed last release (2026-10-04) is a future date, which suggests either a data artifact or a pre-release tag — confirm real commit activity, open issues, and test coverage before committing. A single-maintainer package with no downstream users is a bus-factor risk.
• You need audited, security-reviewed dependencies for a regulated environment.

Adoption gate (practical): read the migration and trait source end to end (should be under an hour), confirm test coverage for the polymorphic pivot and role hierarchy, and pin the version. If the code is small and legible, the risk is bounded; if it is not, walk away — the build is not that large.

How to Pitch It (Stakeholders)

To executives: Membership — who belongs to what, in which role — is a feature every B2B product rebuilds, and it is never the differentiator. This is a small MIT-licensed Laravel package that gives us the standard version for roughly a day of integration instead of a multi-sprint build, with no license cost and no meaningful lock-in: the data lives in ordinary tables we control, so we can fork or replace it. Recommendation is a time-boxed technical evaluation, not a commitment — the package has no visible production adoption, so we validate the code before we depend on it.

To engineering: It is a polymorphic membership pivot with enum roles and a role hierarchy, plus guard integration, policy helpers, model events, and soft deletes — the plumbing we would otherwise write and then maintain. It is deliberately narrow: it does not do invitations, UI, billing seat counts, or fine-grained per-record permissions, so it composes with spatie/laravel-permission or our own flows rather than competing with them. The escape hatch is trivial: schema and traits are ours to fork, and the data is portable. Caveat: single maintainer, no dependents, release metadata looks off — pin the version and review the source before we ship it.

Ask: one engineer, one day, to audit the migrations/traits and prototype a workspace→project membership against our auth model. Decision to adopt, fork, or build follows from that.