Cookie Consent Laravel Package

Product Decisions This Supports

• Feature/roadmap item: unblocking EU analytics and marketing tracking. The banner is the gate between "we can't ship tags in the EU" and "we can launch." This package makes that a small, scheduled task rather than a legal-and-engineering program, so it directly affects launch sequencing for any EU/UK-facing release.
• Build vs. buy vs. borrow. The banner is a commodity: configurable copy, buttons, styling, cookie lifetime, view exposure, and a helper to gate scripts. Buy/borrow that. The compliance program — consent records with timestamps and versions, purpose-level granularity, revocation, audit exports — is where your differentiation and your legal exposure live. Expect to build or buy that separately; do not assume this package covers it.
• Use cases where this is the right-sized call: internal tools and admin apps with minimal cookie surface; marketing/landing sites with a single analytics vendor; MVPs shipping to the EU where a 1–3 day integration is the difference between a sprint and a quarter; multi-language sites that need translatable banner copy without a SaaS contract.
• Use cases where it is the wrong call: anything needing IAB TCF, Google Consent Mode v2, tag-manager-driven per-purpose consent, cross-brand/domain consent state, or a demonstrable consent audit trail. Those are CMP (consent management platform) requirements, and a Blade banner plus a cookie is not that.
• Scope boundary to record explicitly in the PRD: the package displays a notice, remembers a choice in a cookie, and conditionally renders script tags in your views. It does not stop server-side collection, does not log consent for evidentiary purposes, and its client-side cookie state is not tamper-proof. Any team that reads "GDPR-compliant" as an assurance will be wrong, and that's a PM-level expectation to set before, not after, launch.
• Vendor/exit decision: exit cost is near zero — Blade views, a cookie, and a helper. That lowers the stakes of trying it and makes it a reversible, low-regret decision, which is exactly the profile you want for a compliance-adjacent component you may later replace.

When to Consider This Package

Adopt when:

• The app is standard Laravel, the team owns the front end, and the cookie inventory is short and stable (analytics plus at most a pixel or two).
• You want no external JavaScript dependency and no additional third-party script sitting on your pages — a banner that introduces its own vendor tracker defeats the purpose.
• You need control over copy, button wording, styling, and translations, and you need it quickly.
• You accept that legal review of the banner text and cookie policy is your workstream, not the package's.

Look elsewhere when:

• You need auditable consent records, per-purpose categories, revocation flows, TCF, or Consent Mode integration — go to a CMP or build a consent service.
• You operate in a regulated or enterprise procurement context that requires a vendor questionnaire, DPA, security policy, support SLA, or evidence of active maintenance.
• You need to gate trackers that fire server-side or are injected by a third-party tag manager; this package gates markup you control.

Adoption risks to verify before committing (these are the PM's due-diligence checklist):

• Bus factor. Single maintainer, zero stars, no visible adoption. Treat it as "vendor this code into our repo" rather than "depend on an upstream." Fork-and-own is a legitimate outcome and should be the default assumption.
• No visible test suite or CI, and a package score in the low range. Plan for your own smoke tests around the gating helper and the consent state.
• Compatibility matrix unstated. Confirm supported PHP/Laravel versions against your target before it enters a sprint.
• v1.0.2 renamed PHP classes to PascalCase. Low technical risk but a real integration hazard: stale Composer classmaps, Laravel config/route/view caches, hardcoded references, and case-sensitive Linux filesystems. Pin the version, regenerate autoload, clear caches, and grep for old class names during rollout. Confirm whether aliases exist for prior names — if not, treat it as breaking.
• Compliance substance. Confirm the banner does not pre-tick or imply consent, that rejecting is as easy as accepting, and that a revocation path exists. If the package doesn't support those, that's scope you must add — and it must be in the estimate, not discovered in legal review.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost component that removes a blocker between us and EU-facing launch and analytics. It is a commodity banner, not a compliance program — legal still owns the policy text and the consent standard, and we should not present it as certification. The technology risk is low; the real risk is that a zero-star, single-maintainer package has no support path, so we should vendor or fork it and own the code. Exit cost is negligible, and it does not lock us into a SaaS contract, which keeps the door open to a full CMP later if our footprint grows.

To engineering: Standard Laravel/Composer integration — service provider, publishable config, and either a Blade component or middleware injection. Small surface area, no heavy front-end dependency. Expect roughly days, not weeks, but budget explicitly for: pinning the version, regenerating autoload and clearing caches (the v1.0.2 PascalCase class rename is the main hazard on case-sensitive filesystems), adding tests around the script-gating helper, and writing down which scripts are gated so the inventory doesn't drift. Keep the banner views in our repo so a fork is trivial.

To legal/privacy: Here is the mechanism, here is what it does and does not do. It shows a notice, stores a choice in a cookie, and withholds configured scripts until acceptance. It does not produce an audit trail of consent, does not enforce purpose-level granularity, and its cookie state is client-side and not tamper-evident. We need your sign-off on the banner copy, the reject-as-easily-as-accept behavior, and whether our record-keeping obligations require more than this — if they do, tell us now, because that changes the build.