Snooze Laravel Package

Product Decisions This Supports

• Time-shifted notification features without custom infrastructure — Snooze lets a notifiable model defer a notification (snooze(), snoozeFor(), snoozeUntil()), so PMs can spec reminder, follow-up, trial-expiry, digest, and "nudge later" behaviours without asking engineering to build a scheduling layer on top of Laravel's queue.
• Build vs. buy for messaging cadence — if the roadmap needs delayed or user-deferred notifications, this package removes a chunk of custom work; the decision reduces to whether the desired cadence semantics (fixed delays, absolute datetimes, per-user preferences) map onto the package's API.
• Snooze/remind-me-later UX — directly supports product patterns like "remind me tomorrow," deferred onboarding emails, or re-engagement prompts, which are otherwise deceptively expensive to get right (idempotency, queue restarts, cancellations).
• Laravel 13 readiness — the 2.9.1 release adds Laravel 13 support, which is a framework-upgrade enabler. If the platform roadmap includes a Laravel 13 migration, this package is no longer a blocker in the dependency audit; it should be reflected in upgrade planning and in the "known-good dependencies" list.
• Low strategic lock-in — it is a thin convenience layer over Laravel's native notification/queue system, so it does not constrain long-term messaging architecture choices the way a third-party messaging platform would.

When to Consider This Package

Consider adoption when:

• The product already runs Laravel notifications and the queue, and the gap is purely timing, not delivery channel or templating.
• Requirements are notification-level scheduling tied to a model (per-user, per-entity), not complex multi-step campaign orchestration or cross-channel journey logic.
• The team values a dependency with a narrow surface area and an actively maintained compatibility track (2.9.1 landing Laravel 13 support is a positive maintenance signal).
• You are planning a Laravel 13 upgrade and need to confirm the notification-scheduling layer will not block it.

Look elsewhere when:

• You need full marketing-automation semantics: branching journeys, A/B tests, frequency caps, send-time optimisation, or a campaign UI for non-engineers. That is a different category of tool.
• Correctness requirements are high-stakes (billing, compliance, regulated messaging) and you would rather own the scheduling and audit path explicitly than delegate it to a convenience wrapper.
• The platform is not on a supported Laravel major, or the team pins framework versions and cannot absorb a dependency upgrade cadence.
• You need guaranteed delivery semantics beyond what the queue provides (dead-letter handling, delivery receipts, per-message observability) — those must be built or sourced separately regardless.

How to Pitch It (Stakeholders)

To executives: Snooze is a small, focused Laravel package that gives us scheduled and "remind me later" notifications without building and maintaining that machinery ourselves. It is a low-cost, low-risk dependency: narrow scope, standard Laravel primitives underneath, no vendor relationship or data-sharing. The newest release (2.9.1) adds Laravel 13 support, which clears a known item from our framework-upgrade checklist and reduces the risk of the upgrade slipping. Net effect: faster delivery of reminder/follow-up features and one less obstacle to the platform upgrade.

To engineering: This is a thin layer over Laravel's notification and queue system — it adds model-level scheduling (snooze, snoozeFor, snoozeUntil) rather than a parallel delivery mechanism, so it inherits our existing queue, retry, and observability behaviour and does not introduce a new runtime to operate. Version 2.9.1 is a compatibility release only (Laravel 13 support, one new contributor); no breaking changes, no migration work, no config changes implied. Recommended action: bump the constraint, run the notification test suite against Laravel 13 in CI, and treat this as an approved dependency for notification-timing work. Keep an eye on whether we outgrow it — if requirements move toward multi-step campaign orchestration, we should revisit and build that separately rather than extending this package beyond its intent.