Browser Notifier Laravel Package

Product Decisions This Supports

• Re-engagement and retention features: Browser push is a low-friction channel for reaching users who never install a native app. This package is a candidate enabler for "notify me" flows, price-drop alerts, back-in-stock alerts, digest delivery, and security/account notifications.
• Roadmap sequencing for notification channels: If browser push is on the roadmap as a cheap alternative or supplement to email and SMS, adopting a notifier channel lets the team ship an MVP before committing to a paid delivery vendor (OneSignal, Firebase, Pusher Beams). That produces real opt-in and CTR data to justify or kill the larger investment.
• Build vs. buy vs. borrow: The honest comparison is (a) wire Web Push VAPID + service worker + subscription storage yourself, (b) adopt a maintained, Laravel-native notification channel package, or (c) use this package when the stack is already Symfony Notifier-centric. This package is the "borrow" option — the cheapest path only if Notifier is already the abstraction your notification layer speaks.
• Notification architecture standardization: Deciding whether to route all outbound messaging through a single channel abstraction (Symfony Notifier) versus framework-native channels (Laravel Notifications). Choosing this package implicitly bets on the former; that is an architecture decision, not just a dependency choice.
• Vendor and dependency risk assessment: With zero stars and zero dependents, adoption is itself a decision that needs a documented rationale, an owner, and an exit plan. Useful as a forcing function for defining what "acceptable dependency risk" means for the org.
• Time-boxed validation experiments: A one-sprint spike to measure browser opt-in rates and delivery reliability in your actual audience is a legitimate product decision — provided it is scoped as a disposable experiment, not a platform commitment.

When to Consider This Package

Consider it when:

• Your notification layer already speaks Symfony Notifier, or you are on a Symfony-based stack where adding a browser channel through the existing abstraction is genuinely less work than introducing a parallel system.
• You need a prototype or internal tool where a failed notification is inconvenient, not business-critical (admin alerts, dev/staging announcements, low-stakes digests).
• You are running a spike to measure browser push viability — opt-in rate, click-through, unsubscribe behavior — before selecting a long-term vendor.
• You can vendor the code or fork it and are comfortable owning the service worker registration, VAPID key management, and subscription lifecycle yourself.
• Your engineering team has reviewed the source and confirmed it covers the browser push semantics you need; the README-level description ("extension of Symfony Notifier for browser") does not tell you which delivery mechanism it uses or whether it manages subscriptions.

Look elsewhere when:

• You are Laravel-first. Laravel's native Notification system plus a maintained web-push channel package is the idiomatic path, avoids a second notification abstraction, and carries community review and issue history this package does not.
• You need production SLAs, security review, or compliance sign-off (SOC 2, data residency, PII handling in push payloads). Zero dependents and zero stars means no third-party audit trail and no evidence of production use.
• You require maintainer continuity. A single-maintainer package at this adoption level is an unmitigated bus-factor risk; there is no ecosystem pressure to keep it patched against PHP, Symfony, or browser API changes.
• You need channel maturity: segmentation, topic-based subscriptions, delivery receipts, A/B testing, analytics, or quiet hours. This package is a transport adapter; those capabilities will be yours to build.
• Browser API churn matters. Web Push and service worker behavior shift across Chrome, Safari, and Firefox (notably iOS Safari's install-to-home-screen requirement). A package with no visible user base is unlikely to track those changes promptly, so budget for that maintenance regardless.
• You are evaluating it purely on popularity signals. Zero stars and zero dependents is not disqualifying, but it means you are the first real user — treat the evaluation as a code audit, not a due-diligence checkbox.

How to Pitch It (Stakeholders)

To executives and product leadership: Browser push is the cheapest owned channel we have not tested. Rather than signing a vendor contract to find out whether our users opt in, we can run a four-to-six week experiment behind a feature flag using an open-source MIT-licensed adapter. Success criteria are concrete: opt-in rate, click-through rate, and unsubscribe rate against our email baseline. Total cost is engineering time, not licensing. If the numbers justify the channel, we migrate to a supported vendor or a maintained package; if not, we have saved the contract and learned something durable about our audience. The risk is bounded by scoping it as an experiment with a defined kill date.

To engineering: This is a thin adapter that plugs a browser channel into Symfony Notifier. That is attractive only if Notifier is already our notification abstraction — otherwise we are adding a second messaging path next to Laravel's. The package has no visible users, so we should assume we are the first production consumer. Concrete asks: (1) a two-day code audit of the service worker integration, VAPID handling, and subscription storage; (2) pin the dependency and fork it into our org so we control patches; (3) add our own integration tests around subscription lifecycle and payload encryption; (4) name an owner for browser API changes. If the audit turns up gaps in subscription management that exceed a sprint of work, we abandon the spike and evaluate a maintained Laravel-native channel instead.

One-line summary: A cheap, low-commitment way to test whether browser push earns a place on our roadmap — worth a time-boxed spike, not worth a strategic dependency until it proves itself.