Laravel Notification Subscriptions Laravel Package

Product Decisions This Supports

• Notification preference center: build vs. buy vs. adopt. This package is the "adopt" option for one of the most consistently requested end-user features in B2B SaaS: a self-serve screen where a user chooses which notifications they receive, on which channel (mail, SMS, database, broadcast). It replaces a schema-and-controller sprint with a trait, a migration, and a signed-URL unsubscribe flow.
• Compliance roadmap. Granular, persisted opt-outs are the technical prerequisite for CAN-SPAM, GDPR legitimate-interest hygiene, and TCPA-style SMS consent. Adopting a package that already models subscription state at the (notifiable × notification type × channel) grain de-risks a compliance milestone without a custom data model.
• Deliverability and engagement strategy. Per-channel opt-down (rather than all-or-nothing unsubscribe) preserves the email relationship instead of losing the recipient entirely. This is a retention lever, not just a compliance checkbox — it supports decisions like "should we ship a preference center before or after the next lifecycle-email campaign?"
• Segmentation of transactional vs. marketing messaging. Subscription state lets you enforce the product rule "password resets and invoices always send; digests and product news respect preferences." That is a policy decision worth making explicitly in the roadmap, and this package gives you the primitive to enforce it.
• Scope calibration for a preference-center epic. Because the package covers storage and opt-out mechanics but not UI, digests, quiet hours, or batching, it clarifies the real build surface: your team's remaining work is presentation and policy, not plumbing. Useful for sizing the epic and deciding whether the preference center is a v1 checkbox or a v2 differentiator.
• Multi-product / multi-tenant messaging decisions. If you are weighing a centralized notification platform (Novu, Knock, Courier) against staying in-app, trialing this package is a cheap way to learn whether your requirements are genuinely simple — an in-app table plus a controller — or actually need orchestration.

When to Consider This Package

Consider adoption when most of the following hold:

• The stack is Laravel, and notifications already flow through Laravel's Notifiable / Notification system — this package extends that model rather than replacing it.
• You need per-user, per-notification-type, per-channel opt-outs and currently have none, or have a boolean email_opt_out column that no longer fits.
• You want signed unsubscribe links and the subscription state machine without designing the table, the trait, and the controller yourself.
• Your team is small and the feature is table stakes, not differentiating — a preference center that is 80% conventional is a fine outcome.
• You are comfortable vendoring or forking a small MIT-licensed package and owning it thereafter.

Look elsewhere — or build in-house — when:

• Support and longevity are hard requirements. 127 stars, zero listed dependents, and a single maintainer mean no community backstop and no vendor SLA. Treat it as source code you are adopting, not a dependency you are consuming. Budget a fork.
• You need more than opt-in/opt-out. Digests, batching, quiet hours, per-timezone send windows, frequency caps, and in-app preference UIs are all out of scope here.
• Enterprise or regulated procurement requires maintained dependencies with security policy, CVE response, and versioned LTS commitments.
• A notification platform is already in play, or you are evaluating one — introducing a parallel subscription table creates a second source of truth for preferences.
• Multi-tenant or complex RBAC requirements mean preference scoping gets subtle (org-level vs. user-level subscriptions), and you will end up rewriting the queries anyway.
• Laravel version currency matters and you are on a framework release the package has not been tested against.

How to Pitch It (Stakeholders)

To executives (one paragraph): We can ship a notification preference center — the screen that lets customers choose what we email and text them, and the plumbing that makes those choices stick — in days rather than a sprint or two, by adopting a small open-source Laravel package. It directly supports our compliance posture on unsubscribe and SMS consent, and it should reduce list churn because customers can turn down one channel instead of opting out entirely. Cost is effectively zero and the license is permissive. The trade-off is that it is a small, single-maintainer project, so we should plan to fork it into our own codebase rather than depend on it being maintained — an hour of engineering time, not a budget line.

To engineering: This is the Notifiable-native option. It gives us a subscriptions table, a HasNotificationSubscriptions trait, subscribe/unsubscribe APIs, and signed unsubscribe routes — the conventional 80%. It does not give us a UI, digests, quiet hours, or frequency capping, so scope those separately. Recommendation: vendor the package, wrap it behind our own service so we retain the option to swap it out, and pin the Laravel version it was tested against. Do not add it as an unpinned Composer dependency with no fork path.

To design and support: The preference model is per notification type and per channel, which is more granular than what we expose today and should cut "I can't turn off these emails" tickets. The default-on/default-off policy per notification type is a product decision we need to make explicitly — the package stores the state, but we choose the defaults.