Concierge Laravel Package

Technical Evaluation

Update basis (v0.8.1) The release notes materially change several assumptions in the previous assessment, and one of them was the pivotal unknown. tey/concierge is not a thin metapackage. It is first-party, code-bearing, and domain-specific: it owns invitations, workspaces, membership, and authorization grants ("the inviter still authorised, grants unchanged, and already a member"), ships database migrations, publishes config, and defines UI-facing contracts (an accept page with a "ready state", MembersIndex row payloads, switchAccount). It also demonstrates real development history — PR #127, a changelog with an explicit compare link from v0.8.0, and maintained docs/scenarios.md with an accept decision tree — which softens, but does not eliminate, the "zero adoption / no issue history" risk.

Architecture fit Reframed: this is a bounded, high-value domain layer for multi-tenant SaaS invitation and membership flows, not a grab-bag of utilities. That is a better architectural story than "opinionated bundle of essentials" and a worse integration story, because the package sits directly in the authorization path and owns schema. Fit is good for a greenfield multi-tenant product that would otherwise build invitations/workspaces from scratch — that is genuinely non-trivial work, and the release shows the edge cases (expiry, revoked, workspace accepting members, inviter authorization, already-a-member) are being handled explicitly. Fit is poor for any existing application with its own tenancy, roles, or membership model, because the package's tables, grants, and accept-flow state machine become the source of truth.

Removal cost is now known to be high: uninstalling leaves columns, an acceptor record, and UI contract assumptions behind. Treat this as a build-vs-buy decision on the invitation/workspace domain, not a utility adoption.

Integration feasibility Not "composer require and go." The v0.8.1 upgrade notes require publish + run a migration, and the feature requires the host app to pass new arguments (otherEmail, signedInAs, a switchAccount link) into the ready state. So integration costs span: dependency, schema, config, backend wiring, and front-end view changes. Feasibility depends on answers we still don't have around data ownership (does the package own the workspaces/members tables, or reference ours?) and front-end binding (which rendering layer the accept page and MembersIndex components target).

Technical risk

• Pre-1.0 with schema churn in patch releases. v0.8.0 → v0.8.1 added a database column. Under semver, a patch bump should be safe to take automatically; here it requires a migration and a deploy step. That is the single most important operational finding in this release.
• Authorization blast radius. The package enforces inviter authorization and membership grants. A defect or regression here is a security incident, not a bug ticket. It now requires security review, not just code review.
• New identity-linking surface. concierge.invitations.match_email (default true, preserving behaviour) lets a signed-in user with a different verified email accept an invitation. This is a deliberate, useful feature, but it expands the policy surface for account/invitation confusion. Good sign: the release records who accepted and whether the email differed, and the docs' decision tree was updated — auditability was considered.
• Still no external adopters. Unchanged: we remain the reference production deployment. Mitigated somewhat by a visible PR/release cadence and scenario documentation.
• Metadata anomaly, partially resolved. A sequential tag chain (v0.8.0 → v0.8.1), changelog, and PR references corroborate that releases are real artifacts rather than planning artifacts. The anomalous future publish date remains unexplained; verify tag provenance and publish timestamps before pinning.
• Deploy-order coupling. An additive boolean column defaulting false is likely safe for rolling deploys, but the package now imposes a migrate-before-code ordering that our pipeline must encode.

Key questions

1. Which tables and foreign keys does the package own outright versus reference in our schema? Can it attach to an existing users/tenants model?
2. Are published migrations additive-only, and is there a documented rollback for update_concierge_invitations_with_acceptor?
3. Why did a schema change ship in a patch release? Is there a stated BC policy and a migration policy going into 1.0?
4. Is match_email: false gated on server-side verified-email checks, and what is logged when acceptance uses a different email?
5. Who owns the grants/roles model — the package or the host app — and what happens on a mid-flight invite if a role is deleted?
6. Which front-end layer does the accept page and MembersIndex target (Inertia/Vue, Livewire, Blade), and how tightly are those contracts versioned?
7. Full removal cost: which columns, tables, and UI assumptions survive an uninstall?
8. Declared Laravel/PHP constraint matrix and CI coverage — the standard upgrade-liability check.

Integration Approach

Stack fit Two hard gates now. First, version constraints: pre-1.0 means a minor bump may carry breaking changes and a patch bump may carry a migration — pin exact versions, no caret ranges. Second, rendering-layer fit: the release describes page states and row payloads, implying a specific front-end convention; if we are not on that stack, adoption cost rises sharply. Verify both before any spike.

Migration path Greenfield or isolated service only. The viable path is unchanged but with a heavier audit: install into a throwaway Laravel skeleton, run composer why, composer audit, capture an SBOM, then publish migrations and inspect the resulting schema — that schema is the real commitment. If the schema duplicates concepts we already own, stop and default to reimplementation.

Compatibility Re-check collisions with new information: config key concierge.invitations.*, the published migration namespace, view/component names (MembersIndex, accept page), and any helper names. The migration is additive (one boolean, default false), so collision risk is low but table-name collisions in multi-tenant apps are not.

Sequencing

1. Audit (1–2 days): providers, transitive deps, SBOM, and a full read of published migrations and docs/scenarios.md.
2. Security review (1–2 days, new step): threat-model the accept flow, especially match_email: false — token handling, verified-email enforcement, audit records, and grant re-evaluation at accept time.
3. Spike (2–3 days): install in a skeleton, run the migration, exercise both match_email modes, and diff registered providers and config against a clean skeleton. The diff plus schema delta is the integration contract.
4. Decision gate: adopt wholesale (only if the product needs this exact tenancy/invitation model and the rendering layer matches), vendor/fork with an internal owner and pinned tag, or reference implementation — read the decision tree and edge-case handling and reimplement the ~20% we need.
5. Guardrails: exact pins, mandatory review on every bump (assume migrations), deploy ordering encoded in the pipeline, ADR naming an internal owner, and a rehearsed rollback.

Prior composite of 28.5 and zero dependents still argues against wholesale adoption for an existing codebase. What changed: the feature set is substantive enough that fork-and-vendor is now a credible middle path, and the default recommendation narrows to "reference implementation or vendored subset," with wholesale adoption limited to greenfield products that need precisely this model.

Operational Impact

Maintenance We now co-own production schema with an upstream that ships migrations in patch releases. Every bump is a potential deploy task, not a lockfile update. Budget for reading migrations before merging them and for maintaining our own copy if the project goes quiet mid-flight — a fork now includes data-bearing migrations, which makes forking more expensive than it looked previously.

Support Materially improved versus the previous assessment: an active release trail, PR references, and maintained scenario documentation mean we can often read our way to an answer. There is still no external community and no commercial support; upstream responsiveness should be assumed slow, and internal ownership named before merge.

Scaling Runtime cost remains boot-time and per-request query work on invitation/member lookups — check indexes on invitation token, invited email, and workspace membership. The larger scaling risk is organizational: the more services adopt the package, the more expensive a coordinated migration becomes, because each adoption introduces a schema our rollback plan must account for.

Failure modes

• Migration arriving in a patch bump that a developer accepts as routine, then deploys code without the schema step (or vice versa) — the most likely failure introduced by this release.
• Authorization regression in the accept flow, including the new join-as path, surfacing as a membership or grant escalation.
• Identity confusion where a user accepts an invitation intended for another address, if match_email is disabled without a considered policy.
• Blocking a Laravel major upgrade — still the highest-expected-cost failure.
• Orphaned schema on removal, making "just uninstall it" a data project.
• Front-end contract drift between releases in page state and row payload shapes.

Ramp-up The domain is legible and documented, so engine-level onboarding is reasonable — but engineers must understand the accept decision tree, both email-matching modes, and what the package owns in the schema before touching it. Write an internal one-pager covering registered providers, owned tables, config defaults, deploy ordering, and the audit model for join-as acceptance. Allocate roughly a week plus a security review before committing; the added migration and authorization surface is why the estimate does not shrink despite better documentation.