Teamwork Laravel Package

Product Decisions This Supports

• Build vs. buy for B2B table stakes. A user↔team pivot with role, ownership, and a "current team" concept is the same 200 lines every SaaS rewrites. Use this package as the reference implementation: it answers "what's the minimum viable org model?" before you commit engineering weeks to a bespoke schema.
• Feature scoping for the first B2B release. It cleanly draws the line between membership (who belongs, what role, who owns it) and everything else you actually differentiate on — permissions, invitations, seat billing, SSO. That boundary is the scope negotiation you need with engineering and sales.
• Schema and data-model commitments. The pivot shape (team_id, user_id, role) and the single "current team" pointer are the decisions that are expensive to change later. Adopting this makes them explicit and reviewable now rather than discovered in month nine.
• Roadmap sequencing. It supports a defensible order: membership → role checks → policies/gates → invitations → seat-based billing → SSO/SCIM. Each stage is a separate buy/build call; this package only closes the first.
• UX decisions that follow from "current team." Team switcher placement, session-scoped context, default-team behavior, notification and deep-link scoping, and what a user sees when they belong to zero teams.
• Packaging and pricing. Ownership semantics and role strings are the hooks a seat-based or per-workspace pricing model attaches to. Knowing they exist (and are cheap) lets you price on seats without a platform rewrite.
• Support and onboarding load. Invitation and first-login flows drive a disproportionate share of B2B support tickets; deciding early whether team membership is self-serve or admin-provisioned is a PM call this work surfaces.

When to Consider This Package

Adopt when:

• You need flat teams/organizations with one role per member and an owner — no hierarchy, no per-resource grants.
• You're on (or can verify compatibility with) your target Laravel version; the "Laravel 5" framing means you must confirm it runs clean on your current framework before it enters the dependency graph.
• You want low lock-in: MIT, small surface area, schema you own. Forking or replacing it is a day, not a quarter — which makes the risk of trying it asymmetric in your favor.
• Your team is small and velocity matters more than a governance model.

Look elsewhere when:

• You need granular RBAC/ABAC, per-team resource authorization, or audit trails — pair with spatie/laravel-permission and Laravel policies, or evaluate a dedicated identity provider.
• You need true tenant data isolation (row scoping, per-tenant databases) — that's tenancy (stancl/tenancy), a different product.
• You need SSO/SAML, SCIM provisioning, or org management as a sold feature — buy from WorkOS/Clerk-class vendors rather than assembling it.
• Enterprise buyers will ask for role hierarchies, custom roles, or approval workflows; the pivot role string won't survive that conversation.
• Maintenance signals matter more than code size: one maintainer, thin dependent base, and an aging release line mean you should budget for ownership internally, or vendor the code into your app.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Laravel package that gives us the org/membership foundation every B2B product needs — users belong to teams, teams have owners, roles are attached — in days rather than a multi-week build. There's no license cost and no vendor relationship; the code is small enough that we own it either way, so the downside is bounded. It doesn't solve permissions, billing, or SSO, and it shouldn't: those are the parts we'll differentiate on and should decide deliberately. Recommendation: use it to ship team membership in the current cycle, and treat roles/permissions and seat billing as explicit follow-on decisions with their own build-vs-buy calls.

To engineering: It's unopinionated Eloquent traits plus a migration — no architectural commitment, no framework lock-in, and the schema stays ours. We inherit a role column and a current-team session concept, which is exactly the contract we want to stabilize before layering policies on top. Main caveats: verify it runs clean on our Laravel version, and assume we maintain our fork if upstream goes quiet. Exit cost is low; the value is in not re-litigating the data model three sprints from now.