Privacy Settings Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for consent and privacy preferences. This package offers a pre-built model for consent categories, per-subject preference persistence, and a service API for "is consent granted?" checks. That maps to a recurring product question: do we build our own consent layer or adopt an open-source one? This is a candidate input to that comparison — not a decision by itself.
• Regulatory roadmap sequencing. If GDPR/DSAR obligations are on the roadmap, a consent category + persistence primitive like this can accelerate an early compliance milestone. It informs how soon we can ship a baseline consent experience vs. a bespoke build.
• Feature scope for a "privacy center" surface. The Twig helpers and category configuration imply a user-facing preference UI. That supports a product decision about whether to expose a granular preferences screen (marketing, analytics, functional cookies, etc.) versus a simple accept/reject banner.
• Reusability as an architectural lever. The service-API-plus-event-hooks design means consent checks can be called from anywhere and consent changes can trigger downstream actions. That's relevant to a PM decision about whether consent enforcement should be centralized (one system of record) or distributed across features.
• Framework-fit reality check. The package is explicitly a Symfony bundle (symfinity/privacy-settings-bundle, -bundle naming, Symfony container conventions). If our stack is Laravel/PHP, this purchase/adoption decision is not apples-to-apples with a Laravel-native package; using it implies an adapter we own. PM should treat this as a "borrow the design, be careful about the dependency" input, not a drop-in.
• Vendor/alternative evaluation. At 0 GitHub stars and pre-1.0 (v0.2.3), this is useful as a reference implementation and a checklist for what we require (categories, storage, checking API, UI hooks). It strengthens the case for either building in-house or choosing a more mature alternative.

When to Consider This Package

Consider it when most of the following hold:

• The stack is Symfony (or we're willing to own a Symfony→Laravel adapter). On a Laravel codebase, adopt only if the team accepts an adapter layer and the ongoing cost of maintaining it.
• We need a baseline, not a full CMP. If the requirement is "define categories, store per-user choices, check them in code, render controls," this covers that scope. If we need vendor-tag management, tag-blocking before consent, geo-targeting, or a compliance-certified product, look elsewhere.
• We're comfortable operating a young dependency in a high-consequence domain. Pre-1.0 with opaque release notes (v0.2.3 is a date-only patch pointing at a CHANGELOG) means every minor bump needs review. That's acceptable when we have engineering time budgeted for it; not acceptable if we need set-and-forget.
• We can wrap it behind our own consent interface. Replaceability must be a design requirement. If the code is written so consent checks go through our own abstraction, a future swap (or a fork) is cheap.
• Legal/privacy has a seat at the table. We need a reviewer outside engineering to sign off on fail-closed behavior (errors must mean "no consent granted") and on the audit/DSAR export story.

Look elsewhere when any of these are true:

• We need a Laravel-native, auto-discovered, migration-publishable package. A Symfony bundle imposes integration cost that a Laravel-native option likely beats on a 24-month TCO basis.
• We require a vendor SLA, security disclosure policy, LTS branch, or guaranteed CVE response. Single-maintainer namespace (symfinity/*) implies community-only support.
• We can't tolerate fail-open risk in consent enforcement. If default behavior on error is anything other than "deny," that's disqualifying regardless of code quality.
• The consent data must be trivially joinable to our user records and exportable for DSAR. If storage is package-owned and not joinable to our schema, the audit story breaks down.
• We need a mature, 1.0+ dependency. At v0.2.3, semver allows breaking changes on minor releases; every 0.2.x → 0.3.0 is a potential re-plan event.

How to Pitch It (Stakeholders)

For executives:

This is an open-source building block for privacy consent — categories of data use, storing a user's choices, and checking "did this person consent?" from anywhere in the app. It's a candidate to accelerate a GDPR-style consent baseline, but it is early-stage (zero community traction, pre-1.0, single maintainer) and it is built for Symfony, not Laravel. It's a reference and a possible accelerator, not a low-risk drop-in. Recommendation: run a short spike (days, not weeks) to validate fit, treat it as borrowable design and a replaceable component, and keep a more mature Laravel-native or vendor option on the table.

For engineering:

• Framework mismatch is the first gate. Confirm whether composer.json declares framework-agnostic interfaces or Symfony-only wiring. If Symfony-only, integration means an adapter we own and maintain.
• Fail-closed is non-negotiable. We must prove that if the consent check throws or times out, the result is "no consent," not "granted." Add an injected-failure test.
• Pin exactly. Pre-1.0 semver means minor bumps can break behavior on a compliance control. Pin to ~0.2.3, review the CHANGELOG.md body and the diff before any upgrade, and require a documented upgrade path.
• Design for replaceability. Route all consent checks through our own interface so the package can be swapped or vendored without touching call sites.
• Plan coexistence, not cutover. Consent data is stateful and audited: map current records to the package's record shape, backfill, keep a documented "unknown/legacy" state so we don't silently reclassify historical users as opted in, and dual-write or shadow-read for one release before it becomes the system of record.
• Verify operations up front. Confirm read caching / session memoization (per-request consent lookups hit the database otherwise), reversible migrations, DSAR export, and an audit trail. Plan ~2–3 days integration plus ~3–5 days of compliance-adjacent review before production.
• Treat maintenance as a real cost. No SLA, no backport policy, unknown CVE responsiveness. We inherit it. If a Laravel-native package at 1.0+ exists, its higher up-front cost may still win on total cost of ownership.