Filament Browser Notifications Laravel Package

Product Decisions This Supports

• Build vs. buy for notification delivery. This is a "buy the plumbing, own the policy" decision. The package supplies the Web Push transport (VAPID keys, service worker, subscription lifecycle, iOS PWA manifest) that a team would otherwise spend a sprint or two reverse-engineering. What stays in-house is entirely product surface: which events deserve a push, what the copy says, and what the click lands on. That is the right split — the undifferentiated half is off-the-shelf, the differentiating half stays yours.
• Shipping an engagement surface without a roadmap slot. If you already have sendToDatabase() notifications in a Filament panel, this converts existing backlog value into delivered value. You can frame it as "activate a feature we already built" rather than "fund a new initiative," which is a materially easier conversation with a steering committee.
• Sequencing against a notification center. Push is the cheap, high-signal first slice. It validates whether users actually want out-of-app notification before you commit to a full in-app notification inbox, read-state model, digest emails, or per-user preference matrices. If opt-in rates are poor, you learn that before building the expensive half.
• Retention and time-to-acknowledge as product levers. For operational panels (approvals, SLA breaches, failed jobs, new orders, escalations), latency between event and human awareness is a real business metric. Browser push attacks it directly and gives you a measurable dial: opt-in rate, click-through rate, time from notification to action.
• Roadmap options this opens, contingent on adoption data: per-notification-type preferences, escalation chains (push → email → SMS), quiet hours, and mobile-first PWA positioning.
• Instrumentation you must define before rollout. The package gives you delivery, not measurement. Decide up front: push opt-in rate by role, click-through by notification class, dismiss/disable rate, and whether push shifts DAU or merely shifts channel. Without these, the feature is unarguable in either direction at the next planning cycle.

When to Consider This Package

Adopt when most of the following hold:

• You are on Laravel 10+ / Filament 3, 4, or 5 and the affected users are panel users, not public-facing consumers.
• You already emit sendToDatabase() or database-channel notifications — this is a piggyback, not a greenfield build, and its value collapses if there are no notifications to piggyback on.
• Your users are desk-based or intermittent — approvers, ops staff, account managers, backoffice admins who keep the panel open in a tab and benefit from a nudge.
• You can satisfy the hard prerequisites: HTTPS, a running queue worker, and a writable User model at install time (or a willingness to add the HasPushSubscriptions trait by hand in read-only container setups).
• Time-to-value beats control. You want push this week and you are comfortable with the plugin's opinionated defaults, then tuning later via config.
• You have a low blast-radius appetite for the experiment — MIT license, small surface area, one migration, reversible by removing the trait and uninstalling.

Look elsewhere when:

• Your app is not Filament, or push needs to reach a marketing/consumer audience with segmentation, campaigns, and A/B copy.
• You need delivery guarantees, receipting, or analytics — read receipts, delivery failures per user, funnel attribution. This package reports essentially nothing back.
• You need escalation and routing policy — on-call rotations, ack/SLA timers, multi-channel fallback. That is a notification platform decision, not a plugin decision.
• iOS is a primary channel. Push requires the user to install the panel as a Home Screen PWA; that friction will materially depress opt-in and the plugin can only guide, not remove it. If iOS dominance is likely, price that in.
• You require vendor support SLAs, security review artifacts, or a maintenance contract. At 15 stars and 0 dependents, this is single-maintainer software from a consultancy; evaluate it as you would any small OSS dependency — read the code, be prepared to fork.
• You need multi-tenant per-brand VAPID isolation or per-panel key management. Not a stated capability; verify before assuming.

How to Pitch It (Stakeholders)

For executives (one paragraph): We already generate in-app notifications that users only see when they happen to have the panel open — effectively a channel we built and never switched on. This MIT-licensed plugin turns every one of those into a native desktop/mobile browser notification with roughly a one-command install and no changes to our notification code. It is a low-cost activation of existing work aimed at a measurable outcome: how fast our team notices and acts on time-sensitive events. Total exposure is small and reversible; the main caveats are that it is early-stage, single-maintainer open source, and that iOS users must install the panel to their home screen for push to work.

For engineering (the honest summary): It hooks DatabaseNotification::created, extracts title/body/action URL, throttles bursts, and dispatches a queued job over VAPID Web Push. Install generates keys, runs one migration, and patches the User model with HasPushSubscriptions; the service worker is served from a route so there is nothing to publish. Constraints to sign off on: HTTPS and a queue worker are non-negotiable; the installer wants write access to app/Models/User.php and degrades gracefully if it cannot get it; the burst throttle (default 5s) will collapse rapid-fire notifications into a single "you have N new notifications" push, which is a product tradeoff you should accept deliberately. Opt-outs can be suppressed per notification via ->viewData(['silent' => true]). Dead subscriptions are cleaned up on 410 responses. Filament 3/4/5 are all supported, and there is a test command (browser-notifications:test {userId}) so we can validate on staging before rollout.

The ask: timeboxed pilot on one panel and one user cohort, with success criteria agreed in advance (opt-in rate, click-through, time-to-action), plus a named owner for the fork-and-maintain contingency if the upstream project stalls.