Consent Bundle Laravel Package

Product Decisions This Supports

• Consent as a first-class domain object. This package models the capture and storage of user consent — purposes, grants, withdrawals, timestamps — which is the data backbone behind GDPR/ePrivacy, CCPA/CPRA, LGPD, and PDPA obligations. It supports the decision to own consent data in your own database rather than renting it from a CMP vendor.
• Build vs. buy for compliance surfaces. Typical CMPs (OneTrust, Cookiebot, Usercentrics, Osano) run $500–$5,000+/month at scale. This repo is a candidate "build" option for the record-keeping layer, letting you defer or avoid a vendor contract while keeping the option open. The decision it informs: do we buy a platform, build a thin internal service, or fork a starting point like this?
• Roadmap sequencing for a compliance workstream. If consent capture is a prerequisite for launching in the EU/UK, or for a SOC 2 / ISO 27001 evidence trail, this gives engineering a concrete artifact to spike against — useful for sizing the "consent epic" in a quarter plan.
• Feature gating and preference management. Consent records double as entitlement data: marketing email opt-in, analytics cookies, data-sharing with sub-processors, AI training opt-in. This supports product decisions about granular preference centers and re-consent flows when policies change.
• Audit and dispute defense. An immutable-ish log of "who consented to what, under which policy version, when, from which IP/user agent" is the artifact legal will ask for during a DSAR or a regulator inquiry. That is a roadmap item worth funding before it is urgent.
• Reference architecture for a spike. Even if rejected, reviewing a small MIT-licensed implementation is a cheap way to align product, legal, and engineering on a shared vocabulary (purposes, lawful basis, withdrawal, retention) before committing to a schema.

When to Consider This Package

Consider it when most of the following hold:

• Your stack is PHP and Symfony-oriented. The Bundle suffix is Symfony convention — for a Laravel codebase this is a fit problem, not a detail. You would be adopting a foreign service-container and configuration idiom, and the integration cost likely exceeds the value of the code you inherit.
• Your need is the data model and persistence layer — consent records, purposes, versions, withdrawal — not a turnkey cookie banner, consent-mode script, or hosted preference center UI. Those are separate products and this package will not replace them.
• You are prepared to vendor the code into your repo and own it. With one star and zero dependents, there is no community, no security response process, and no credible maintenance guarantee. Treat it as a permissively licensed (MIT) starting point, not a dependency.
• Legal has signed off on your own consent taxonomy and policy text; you are using the package only as plumbing beneath a process you already designed.
• You have an engineer who can read the entire codebase in an afternoon and a test suite you can wrap around it. The due-diligence cost is low precisely because the codebase is small — that is the main thing it has going for it.

Look elsewhere when:

• You need a compliance outcome, not a library. No package grants consent compliance. The banner UX, the purpose taxonomy, the retention schedule, the withdrawal path, and the records-of-processing documentation are the actual work; the library is a small fraction of it.
• You need multi-jurisdiction policy content out of the box. Vendor CMPs sell regulatory templates and geo-detection; this does not.
• You need an SLA, security review artifact, or vendor indemnity. Procurement and security teams will not accept a one-star repository as a dependency without a fork-and-own plan on record.
• Your platform is Laravel. Reach for a Laravel-native consent package or a thin internal implementation instead; porting a Symfony bundle is the worst of both worlds.
• Consent volume or audit requirements are high-stakes (health, finance, children's data). In those contexts the cost of getting the schema and immutability semantics wrong dwarfs any savings.

Practical recommendation for the decision log: timebox a spike — half a day for one engineer to read the source, half a day to write a throwaway adapter and three tests. Fund a real build only if the spike shows the data model is defensible; otherwise keep it as a design reference and write your own 200-line implementation against your own schema. The package's value here is mostly as a conversation artifact, not as a dependency.

How to Pitch It (Stakeholders)

To executives: There is a credible open-source starting point for the consent record-keeping we need for EU/UK launch, under a permissive MIT license, that we can adopt without a vendor contract. The caveat is maturity — it has essentially no adoption, so we would fork and own it rather than depend on it. My recommendation is a low-cost evaluation spike, not an adoption decision: roughly one engineer-day to determine whether it saves us meaningful build time or merely renames work we would do anyway. It is a way to buy schedule with a small, bounded risk, and it keeps the "buy a CMP" option open rather than foreclosing it.

To engineering: Read all of it before committing — it is small enough to audit in an afternoon, and that is the point. Expect to fork it into our repo, add a test suite, pin our own purposes schema, and treat upstream as dead. The value is a head start on the entity model (consent, purpose, version, withdrawal, audit trail), not a library we take a version bump on. For a Laravel shop, call out early that the Symfony bundle conventions will cost more to integrate than to reimplement — decide that in the spike, not after.

To legal and compliance: This gives us a structured, queryable record of who consented to what, under which policy version, and when — the evidence artifact you will want for DSARs and regulator inquiries. It does not supply consent banners, jurisdiction detection, or policy language, and adopting it does not by itself make us compliant. Treat it as the ledger, not the program; the process, the UI, and the withdrawal path remain ours to design and must be reviewed separately.

Risk to state openly: one star, zero dependents, and a middling health score mean abandonment risk is high and there is no security response channel. The mitigation is the fork-and-own posture — if we adopt, we own it entirely, and we should record that decision rather than let it happen by default.