Laravel Legal Consent Laravel Package

Product Decisions This Supports

• Regulatory go-to-market readiness (GDPR / ePrivacy / CCPA-style regimes): the package provides the record-keeping layer behind cookie banners, privacy policy acceptance, terms of service acceptance, and marketing/profiling consent. That directly underpins any roadmap item that gates a launch on "can we legally serve EU/UK users?"
• Re-consent workflows as a product feature, not a legal chore: because legal documents are versioned, you can decide when users must re-accept (new DPA, updated terms, changed marketing scope) and treat that as a product requirement with its own UX, comms plan, and success metric (re-acceptance rate, time-to-reaccept).
• Consent as an auditable data asset: timestamped, per-user, per-document-version acceptance records support DSARs (subject access requests), consent withdrawal, and audit responses. This is the difference between "we have a banner" and "we can prove consent" — a distinction that shows up in enterprise security questionnaires and procurement reviews.
• Build vs. buy: the realistic comparison is (a) build in-house, (b) adopt a commercial CMP (OneTrust, Cookiebot, Usercentrics, Osano), or (c) adopt this package as the consent system of record while keeping a lightweight front-end banner. It is attractive when you already run Laravel and want consent data inside your own database rather than a third-party SaaS — no per-MAU pricing, no data residency debate, no vendor DPA to negotiate.
• Feature gating by consent state: analytics, personalization, ad retargeting, and third-party embeds can be gated on consent records. This lets product decide which capabilities are "strictly necessary" vs. "opt-in" per market rather than shipping one global compromise.
• Platform currency decisions: the 3.3.0 release explicitly supports Laravel 11–13 and PHP 8.2–8.5, so adopting this package no longer pins your framework upgrade path. If your roadmap includes a Laravel 12/13 or PHP 8.5 migration, this is now a non-blocker — a meaningful change vs. earlier 3.x releases.
• Roadmap risk flag: the changelog for this cycle is dominated by Dependabot CI bumps plus one large maintenance PR. That is a signal about maintenance cadence, not about consent functionality. Treat it as a reason to plan an exit ramp (thin adapter around the package's models/events) rather than a reason to avoid it.

When to Consider This Package

Consider it when:

• You are on Laravel and want consent records in your own database, under your own retention and deletion policies.
• You need versioned legal documents with per-user acceptance history — the audit trail is the core requirement, not the banner UI.
• You have (or will have) users in jurisdictions requiring demonstrable consent, and legal/procurement is asking "where is consent stored and can you prove it?"
• You want to avoid per-MAU CMP pricing or a vendor that would become the data processor for your consent records.
• You are on Laravel 11–13 / PHP 8.2–8.5 and want a dependency that won't block framework upgrades.
• Your team is small enough that a composable package plus a custom banner (or a thin JS CMP for the UI layer) beats a full platform.

Look elsewhere when:

• You need a complete CMP: geo-based banner behavior, tag/script blocking and vendor scanning, consent-mode signaling to ad platforms, cookie categorization discovery, or a marketing-operated admin UI. This package is the persistence and versioning layer; the enforcement/UI surface is yours to build.
• You are multi-stack (Rails/Django/Node services, native mobile apps) and need one consent source of truth across all of them — a vendor with multi-platform SDKs is a better fit.
• You need turnkey regulatory templates, jurisdiction rule engines, or legal content authoring — that is a legal-ops/CMP purchase, not a Laravel package.
• You require a vendor with a support SLA, indemnification, or a published security certification. This is community open source; you own the risk.
• You cannot tolerate a dependency whose recent release history is mostly automated dependency bumps — in that case, wrap it thinly or vendor the models.

How to Pitch It (Stakeholders)

For executives: This is a small, self-hosted open-source Laravel component that gives us a defensible record of user consent — who agreed to which version of which policy, and when. It lets us ship into regulated markets without a per-user CMP subscription, and keeps consent data inside our own database, which shortens privacy reviews and simplifies data-residency and processor questions in enterprise deals. Cost is engineering time for the banner and the re-consent UX, not licence fees. The 3.3.0 release brings it current with Laravel 11–13 and PHP 8.2–8.5, so it won't hold back our platform upgrades. Main caveat to acknowledge: it is community-maintained, so we should design a thin boundary around it so we can swap it out if maintenance stalls — the consent records are ours either way.

For engineering: The package owns the consent domain model — versioned legal documents plus per-user acceptance records — and we own the presentation and enforcement layers. 3.3.0 modernizes the toolchain (Pest, Pint, Larastan) and widens the support matrix to Laravel 11–13 and PHP 8.2–8.5, so it fits our upgrade roadmap. Because it sits on our own schema, DSAR exports, consent withdrawal, and retention purges are ordinary Eloquent work rather than vendor API calls. Recommended adoption pattern: depend on its models/events but route all reads/writes through our own repository/service so that a future replacement, or a shift to a full CMP for banner enforcement, is a contained change rather than a migration.