Concierge Laravel Package

Product Decisions This Supports

• Build vs. buy for undifferentiated plumbing — now with a clearer scope. Concierge still positions itself as a baseline Laravel essentials suite, but v0.8.1 shows it includes concrete workspace-invitation and membership behavior, not just generic helpers. That makes the build-vs-buy question sharper: are we buying invitation/member lifecycle plumbing, or only a thin scaffolding layer?
• Team/workspace onboarding as a roadmap lever. The new concierge.invitations.match_email setting and “Join as {email}” flow support a real product edge case: a user signed in with a different verified email can accept an invitation as themselves while expiry, revocation, inviter authorization, workspace membership status, and grant checks still apply. If your roadmap includes workspaces, invitations, or member administration, this can compress time-to-first-onboarding flow.
• Policy and trust decisions become explicit. The default remains match_email: true, preserving existing behavior; setting it to false is a deliberate product/security choice. PMs can now frame the trade-off directly: stricter invite binding vs. smoother acceptance for users with multiple verified emails. The invitation records who accepted and whether a different email was used, and member rows expose acceptedWithOtherEmail and invitedEmail for host visibility.
• Consolidating a homegrown starter kit — with operational cost included. A new migration (update_concierge_invitations_with_acceptor) and config surface mean adoption is no longer just “copy traits and helpers.” Any comparison against an internal skeleton should include migration ownership, config governance, and upgrade testing.
• Deferring non-differentiating work, within a narrower boundary. The strongest PM use case remains scope negotiation: avoid spending sprint capacity on baseline app hygiene and invitation edge cases, and spend it on the differentiator. That trade is defensible only if the team forks and owns the package, reviews the migration, and accepts the maintenance burden.

When to Consider This Package

Pilot Concierge when:

• You are starting greenfield Laravel work with workspace/team membership and invitation flows, and you have no blessed internal skeleton.
• You need invitation acceptance edge cases — different verified email, auditability of who accepted, host-visible member metadata — and would otherwise build those flows yourself.
• You are willing to fork and own the code, including running and reviewing new migrations such as update_concierge_invitations_with_acceptor.
• You can accept the default concierge.invitations.match_email: true behavior unless a product/security review explicitly justifies setting it to false.
• Your compliance posture tolerates an unaudited MIT dependency for internal scaffolding, with code review before use in regulated or request-path data flows.
• You can time-box a spike to enumerate exactly what the package contains beyond the release notes — traits, helpers, invitation logic, member UI data, migrations, and docs.

Look elsewhere — or build in-house — when:

• You need support SLAs, security responsiveness, or a maintained release cadence. v0.8.1 shows the project is still moving, but low adoption and single-maintainer risk remain the gating concern.
• You already run Laravel Breeze / Jetstream / Fortify / Filament or a dedicated team-management package. Overlapping auth, invitation, and membership scaffolding is a net cost.
• Your architecture is non-standard — multi-tenant, event-sourced, heavily modular, or with custom identity rules — such that Concierge’s invitation/member model becomes something you fight.
• You require documented upgrade paths across Laravel major versions. The new migration is small, but it is still migration ownership you inherit.
• The spike shows the suite is mostly thin traits and helpers plus a small invitation flow you could reproduce quickly. At that point “build” is better than inheriting maintenance for limited value.
• You cannot yet verify Laravel version compatibility, license, release history, and maintainer activity directly on the repository rather than trusting package-index metadata.

How to Pitch It (Stakeholders)

To executives: Concierge is a free, MIT-licensed Laravel accelerator for repetitive groundwork: baseline app plumbing plus workspace invitation and membership flows. The v0.8.1 release adds a configurable “join as signed-in account” path for invitations, with guardrails and audit fields. The business case is modest but concrete: it can shorten onboarding-flow delivery and reduce inconsistency across teams. The risk remains concentrated: low adoption and no evident community mean we should treat it as source code we adopt, not a vendor we rely on. Recommendation: fund a short evaluation spike, require a fork-and-own decision, review the new migration, and do not put it on a critical path until that review is complete.

To engineering: Treat v0.8.1 as a meaningful scope signal, not just a patch. Review the invitation implementation, the concierge.invitations.match_email setting, the new migration, the accept-page states, and the MembersIndex fields (acceptedWithOtherEmail, invitedEmail). Confirm Laravel compatibility, license, and release history directly on the repository. If the spike shows the suite covers concerns we would otherwise rebuild, fork it, pin it, own the migration, and add it to our internal starter. If it turns out to be a small invitation flow plus helpers, write our own and move on.