Useragreementsbundle Laravel Package

Product Decisions This Supports

• Consent/acceptance tracking as a real feature, not a checkbox. The package gives you records of which user accepted which agreement, which is the artifact you actually need when legal, support, or an auditor asks "can we prove this user agreed to the terms in force at the time?"
• Build vs. buy for a deceptively small problem. Dropping a checkbox and a boolean on users is a half-day of work; a versioned, auditable consent ledger is not. This package sits in that gap — cheap enough to avoid a custom build, opinionated enough to keep you out of the classic pitfalls (overwriting history, no version linkage).
• Roadmap input for legal/compliance asks. Typical triggers: new ToS or privacy policy requiring re-consent, regional rollout with different agreement texts, enterprise customers asking for acceptance evidence during procurement/security review. Having this in place turns a multi-sprint compliance scramble into a content/config change.
• Scoping the "we need a consent platform" conversation. It establishes a baseline that lets you say precisely what you do and don't need, so a later buy decision (OneTrust-class tooling) is driven by real gaps — multi-jurisdiction rule engines, granular purpose-level consent, DSAR workflows — rather than vibes.
• Registration and onboarding flows. The natural first application is the signup checkbox and the "we updated our terms" interstitial. Both are small features with outsized legal exposure if done carelessly.

When to Consider This Package

Adopt when:

• You're on Laravel/PHP and the app already owns user accounts and authentication.
• You need per-user, per-agreement, per-version acceptance records — i.e., "what did they agree to, and when," not just "did they tick the box."
• Your team is small and would otherwise hand-roll this in an afternoon and get the history model wrong.
• You can absorb the upgrade cost of a major version. Note on v2.0.0: it is a breaking release solely because checkbox fields now carry an id. Functionally trivial, but anything that targets the rendered form — CSS selectors, JS, end-to-end tests, analytics event tagging on the checkbox — needs a pass. Budget a short QA cycle, not a migration project. Treat it as a signal that the package is pre-1.x-stability in spirit: expect more markup-level breaks, so pin versions and read changelogs before composer update.

Look elsewhere when:

• You need enterprise consent management: multi-jurisdiction rule sets, purpose-level/tag-level consent, cookie and third-party script gating, DSAR tooling, or a vendor with an SLA and indemnity. This is not that product, and stretching it there is how you get an audit finding.
• You're not on Laravel, or you're on an older Laravel/PHP version the package doesn't track.
• The requirement is a legally reviewed, certified consent UX where legal wants a named vendor's paper trail.
• You want a single-maintainer dependency on your compliance-critical path without any internal fallback. Weigh the bus factor honestly; the mitigation is that the data model is simple enough to fork or reimplement if needed.

How to Pitch It (Stakeholders)

For executives: This is inexpensive insurance against a specific, plausible failure: being unable to demonstrate that a user accepted the terms that applied to them. It converts a compliance question from "we'd have to reconstruct it from logs, maybe" into a query. Cost is a dependency, a migration, and a form change; the alternative is either bespoke code we maintain forever or a commercial consent platform at orders of magnitude more spend. It does not replace legal review of the agreement text itself — it records acceptance of it.

For engineering: A small, focused Laravel package that handles agreement storage, versioning, and user acceptance records, so we don't reinvent a history table badly. The v2.0.0 release is a breaking change in name only: checkbox fields gained an id. Practical impact is limited to front-end selectors, E2E tests, and any analytics hooks bound to those inputs — roughly a half-day of verification, no data migration. Recommendation: pin the version, schedule the bump alongside an existing front-end change, and keep a thin adapter around it so a future swap stays contained.