Subscribable Notifications Laravel Package

Product Decisions This Supports

• Build vs. buy for a notification preference layer. Laravel ships notifications and channels but no first-class "who wants what, on which channel" model. This package fills that gap, so the real decision is whether preference management is core product surface (build) or table stakes plumbing (buy/adopt). For most teams it is the latter.
• Roadmap timing for framework upgrades. v1.8.0 adds Laravel 13 compatibility. This is the single most decision-relevant fact in the release: it tells you the package is tracking Laravel majors rather than lagging them. If your platform roadmap includes a Laravel 13 upgrade, this package is not a blocker — but confirm it lands in the same window as your upgrade, and pin accordingly.
• Compliance and deliverability scope. A subscribable/unsubscribable notification model is the substrate for CAN-SPAM/GDPR-style unsubscribe requirements and for reducing list fatigue. Adopting the package lets you scope compliance work as "wire up preferences" rather than "design a preference domain model."
• Feature bets that depend on preference data. Digesting, quiet hours, channel fallback (email → SMS → in-app), and per-segment broadcast targeting all require a subscription/preference store. If any of these are on the roadmap, the data model decision comes first and this package constrains or enables those bets.
• Support-load forecasting. Every notification type you ship multiplies the preference matrix users can configure. The package makes that matrix cheap to expose — which is a product decision (how much control do we surface?) as much as an engineering one.

When to Consider This Package

Adopt when:

• You are on, or imminently moving to, a Laravel version this release supports (v1.8.0 explicitly covers Laravel 13; verify your exact version against the composer.json constraint rather than the release title).
• You need per-user, per-notification-type, per-channel opt-in/out and do not want to own that schema and its migrations.
• Your subscribers are polymorphic (users, teams, tenants) and you want that handled without bespoke joins.
• You want to stay inside Laravel's native Notification/Notifiable conventions rather than adopt a third-party notification platform.

Look elsewhere when:

• You need a full preference center UI, templating, scheduling, or delivery analytics. This package is the data/subscription layer, not a notification platform — pairing it with a product UI is still your work.
• You require enterprise-grade support, SLAs, or a large maintainer bench. A release cut as a single compatibility PR by one contributor suggests a small maintainer surface; that is a continuity risk worth a documented exit plan (the schema is simple enough to fork).
• You need complex routing logic (frequency capping, send-time optimization, cross-channel orchestration) — that belongs in your own service layer or a dedicated vendor.
• Your notification preferences are trivially binary (global unsubscribe only); the package is more model than you need.

Before committing, verify: the test matrix actually runs against Laravel 13 (a version-bump PR is not proof of green CI on the new major), whether illuminate/* constraints are bounded above (risk of silent breakage on the next major), and the changelog cadence between 1.7.0 and 1.8.0 for signs of maintenance liveness.

How to Pitch It (Stakeholders)

To executives: We need a way for users to control which notifications they receive and on which channel — it is a compliance requirement and a churn lever, not a differentiator. Rather than build and maintain that ourselves, this package gives us the subscription model on top of the notification system we already use. The new release confirms it stays current with Laravel 13, so adopting it does not create an upgrade liability. Cost is low; the main residual risk is that it is maintained by a small team, which we mitigate because the data model is simple enough to own if we ever have to.

To engineering: ylsideas/subscribable-notifications v1.8.0 adds Laravel 13 support. It supplies the subscribable-notification model (per-type, per-channel preferences, polymorphic subscribers) that we would otherwise hand-roll against Laravel's native notification system. Action items: confirm our target Laravel version against the package's illuminate/* constraints, confirm CI is green on 13 rather than just a version-constraint bump, and decide now whether the preference UI lives in our app or is deferred. Treat the upstream as a dependency with a small maintainer footprint — keep our usage close to the documented public API so a fork stays cheap.

Recommendation: adopt for the subscription layer, do not treat it as a notification platform, and re-assess at the next Laravel major.