User Consent Laravel Package

Product Decisions This Supports

• Build vs buy for a phase-1 consent surface. The package covers consent option CRUD, capture at registration, re-consent when policy changes, a user-facing "My Consents" review page, emailed receipts, and an admin-wide consent listing. That is roughly a sprint-plus of UI we would otherwise scope and design ourselves — the decision it enables is whether a compliance/trust milestone ships this quarter or next.
• Roadmap slicing. It draws a clean line between table-stakes consent (grant, re-grant, receipt, review) and the capabilities we still own: withdrawal/revocation, data-subject export and erasure, per-purpose granularity, localization, retention policy, and multi-tenant or regional policy matrices. Useful for splitting MVP from later phases and for pricing the gap honestly.
• Use cases it fits. Self-serve SaaS signup where terms and privacy acceptance must be evidenced; B2B onboarding with policy-update re-acknowledgment; internal tools where staff must re-accept updated policies; any product that needs an auditable "who agreed to what, when" view for support or compliance.
• An architecture decision disguised as a package evaluation. The registration consent form and "My Consents" page are Filament panel pages, so end users must be served through an authenticated Filament panel. Adopting this forces the "is Filament back-office only, or also customer-facing?" question early — which is valuable either way, because it settles a strategic constraint before we build around it.
• Scope discipline. Because the package stops at grant/re-grant/receipt, it prevents us from quietly assuming withdrawal and export are handled. Those become explicit roadmap items with owners rather than compliance surprises.

When to Consider This Package

Adopt when:

• We are already on Filament 4.x/5.x with Laravel 10–12 and PHP 8.2+, pinned to the branch matching the Filament major, and our Livewire version is compatible with the chosen line.
• End users are, or can credibly be, served through an authenticated Filament panel with registration enabled. This is the gating criterion — everything else is secondary.
• Requirements are grant, re-grant, receipt, and review: signup acceptance, prompted re-acceptance on policy updates, a self-service page, and an admin listing.
• We accept that we are the maintainers. Small team, short timeline, MIT license, and a named engineering owner with a documented fork-or-replace trigger.
• Policy wording can live in seeders or migrations under code review rather than in an admin-managed approval workflow.

Look elsewhere when:

• Filament is not the panel framework, or the end-user experience is a separate SPA or mobile app. Outside a Filament panel the package degrades to Eloquent models plus migrations, and we rebuild every screen — that is a reference implementation, not a dependency.
• Consent withdrawal, data-subject export or erasure, per-purpose or per-tenant scoping, or localization are in scope. None are evidenced, and bolting them onto someone else's schema is usually worse than starting clean.
• We operate in a regulated context that requires vendor support, append-only evidentiary guarantees, or code-reviewed policy text as a hard requirement rather than a nice-to-have.
• We are pinned to a Laravel or Filament version with no matching package major and no appetite for an upgrade project on someone else's schedule.

How to Pitch It (Stakeholders)

To executives: this buys a credible, demonstrable consent capability — signup capture, re-consent on policy change, user self-service review, and admin reporting — for the cost of a short integration rather than a bespoke build, under a permissive MIT license. The trade is maintenance, not money: small community, single maintainer, no SLA, and the package majors in lockstep with Filament, so each Filament major becomes a scheduled project of a few days. Recommend a time-boxed spike with an explicit go/no-go gate, and if it passes, fork at adoption rather than after a year of local modifications. Contain the blast radius: it touches the User model and the registration flow, our two highest-traffic paths.

To engineering: it is Filament-native, so installation is composer plus publishing migrations, config, and views. The real work is ownership. Publish and edit the migrations — confirm consent history is append-only, not overwritten on re-consent, and index user_id up front. Seed consent options so policy text is diffable and reviewable in pull requests rather than typed into an admin form. Set the consent page class through pages.consent_option_form_builder from day one; it is the supported seam for layout and chrome. Queue the consent email instead of sending it inline on the registration request, and treat delivery failures as a compliance gap with retry and a resend path. Add explicit tests for the "nothing left to consent to" redirect — there is prior art for a 403 in that flow. Budget half a day reading source: the docs drift from the actual config surface, and the naming across package, namespace, and config key varies. Document the spike outcome — adopt, fork, or replace — and the trigger for revisiting.