Laravel User Team Sync Laravel Package

Product Decisions This Supports

• Build vs. buy, for the plumbing layer. The package replaces the glue code every hub-and-spoke Laravel estate eventually writes: "user created in the hub → user must exist, with the right teams, in each satellite app." That work is commodity, it's boring, and it's exactly where teams quietly burn two to six weeks. Adopting this package is a decision to not staff that work — with the caveat that the reconciliation work (mapping our existing users/teams/invitations into its model) is still ours and is not small.
• Roadmap sequencing for multi-app expansion. If the roadmap includes any satellite app that needs team-aware features ("tenant-aware dashboards in app B," "regional instance," "internal tools sharing a directory"), this unblocks that launch without standing up a full identity provider. It is a stepping stone, not a destination — it does not replace Okta/Auth0/WorkOS/SCIM, and the roadmap narrative should say that explicitly so nobody assumes SSO comes free later.
• A scope line we need to draw now: propagation, not authorization. The package moves user records, active flags, team memberships, and password hashes (pre-hashed, publisher-side — a good sign). It does not own roles/permissions semantics in our app. Decide and document that our authorization layer stays ours; otherwise we drift into inheriting half a permissions system from a dependency we don't control.
• Feature-level decisions it enables. Any feature gated on "a new user is productive on day one in every app" or "removing someone from a team actually removes them everywhere" depends on this capability existing. Those are launch gates, and this is the cheapest credible way to clear them in a Laravel-only estate.
• Instrumentation the PM should demand up front (this package ships a SyncLog model and inbound/outbound logging, so the data is nearly free): sync lag per app, per-action failure rate, count of orphaned memberships (user exists in app B but not in hub, or vice versa), and retry-exhaustion events. Without these, you cannot tell a working sync from a silently half-broken one.
• One caveat that must be resolved before this informs roadmap messaging: the package's own documentation contradicts itself. The public description frames it as membership reconciliation "from a single source of truth"; the internal agent docs describe an HTTP + queue publisher/receiver system with API keys, observers, and per-app fan-out. Both are plausible; they imply different products. Do not put either version in a roadmap deck until engineering has read the code.

When to Consider This Package

Consider it when all of these hold:

• You run two or more Laravel apps with a duplicated User/Team model and manual or half-built sync between them.
• Membership is simple: a user↔team pivot with an optional role and an active flag. No nested teams, no polymorphic member types, no org hierarchy.
• The apps are Laravel-only on the receiving side — the receiver is Laravel API endpoints behind a bearer token, not a language-agnostic contract.
• You can run PHP 8.3+ / a current Laravel (the code style targets 8.3 with strict types throughout).
• Someone on the team can own a thin integration wrapper — pinning the version, reviewing each release diff, holding the fork-exit plan.
• Sync is not on the billing-entitlement or access-control critical path, or you're willing to fork if it breaks.

Look elsewhere when any of these hold:

• You need real identity: SSO/SAML/OIDC, SCIM provisioning, MFA, directory sync from a corporate IdP. That's WorkOS/Auth0/Keycloak/Cognito territory. This package is not an IdP and shouldn't be pitched as one.
• You need a non-Laravel receiver (a Node service, a data warehouse, a vendor SaaS). The receiving side is Laravel controllers; you'd be writing an adapter, which erases the buy argument.
• Membership carries business logic: entitlement calculation, seat counting, nested org structures, multi-tenant scoping with per-tenant rules. The package has an opinion, and you will fight it.
• You need vendor support, an SLA, a security disclosure policy, or SOC 2 evidence. None of these exist here. Zero stars, zero dependents, one maintainer, and a v1.7.0 release note that is literally just a compare link.
• The dependency would land on a regulated or audit-scoped path where you must be able to explain every write to membership data.
• You run one app. There is nothing to sync.

Maturity read: treat this as an internal-preview-grade dependency. That is not disqualifying for a hub-and-spoke estate where the alternative is writing the same code badly, but it caps the commitment. Approve a spike, not a platform bet.

How to Pitch It (Stakeholders)

To executives — one paragraph: We have multiple Laravel apps that each keep their own copy of users and teams, and keeping them in agreement is hand-rolled, fragile, and invisible until it breaks. This package is a maintained-in-the-open component that does that specific job: it propagates user records, active status, team memberships, and pre-hashed passwords from our hub to our secondary apps, with logging we can actually monitor. It's MIT-licensed and small enough to fork, which is our insurance policy. The honest risk is maturity: one maintainer, no support contract, and the latest release notes are empty, so we cannot yet say what changed. The ask is not "adopt this." It's "fund a one-to-two week spike and a feature-flagged rollout," with a hard gate: an engineer reads the release diff and runs the migrations against a production-shaped schema before anything ships.

To engineering — the framing they'll care about: the install is trivial (composer require, publish config, wire the service provider); the work is reconciliation — merging our invitations, roles, soft deletes, and tenant scoping into its pivot schema, plus a rollback script that restores the pre-migration state. Budget accordingly and don't let anyone call this a one-day ticket. Non-negotiables: pin ^1.7 exactly, snapshot membership tables before the first migration (pivot migrations are typically non-reversible once data lands), keep the integration surface thin enough that a fork is a weekend rather than a quarter, and prefer idempotent, resumable, queued sync jobs over inline ones — a mid-batch failure that leaves teams half-populated is the failure mode that costs us a weekend.

To whoever inherits it — the recurring cost: roughly an hour of release-diff review per minor version, forever, plus keeping our model changes in step with its schema. Cheap individually; it is a permanent tax and should be named as one so nobody is surprised in six months.

The honest counter-position, so the pitch survives scrutiny: we could build this ourselves in a few weeks and own it completely, or we could buy a real identity platform and solve the class of problem rather than this instance of it. This package is the middle option — faster than building, far cheaper than an IdP, and appropriate specifically because the problem is small and Laravel-shaped. If the multi-app estate grows beyond a handful of apps, or if SSO moves onto the roadmap within twelve months, the right call flips to WorkOS-style buy, and we should say that now rather than defend this choice later.