Nova Push Notification Laravel Package

Product Decisions This Supports

• Build vs. buy for internal notification tooling. This package is effectively a ~one-screen admin panel that wraps OneSignal's send API. The real decision is whether to buy a push-delivery vendor (OneSignal) and expose it through your existing admin surface, or invest in a first-class notification system. This package represents the cheapest version of the "expose the vendor to ops" option.
• Roadmap placement for push as a channel. It supports a "push is an operational/marketing capability, not a product feature" stance: someone in ops or marketing composes a message and fires it to a segment. If push is on your roadmap as a lifecycle/messaging channel (onboarding nudges, re-engagement, transactional alerts), this package only covers the manual-broadcast slice — not triggered, event-driven, or personalized messaging.
• Who owns sending. Adopting it moves the "send a push" capability out of engineering tickets and into a Nova admin screen — a decision about operational autonomy and the support burden that follows (who's accountable for copy, targeting, and send mistakes).
• Vendor concentration risk. It hardwires OneSignal. That constrains a later migration to FCM/APNs or a multi-channel provider (Braze, Customer.io, Knock) and should be priced into any decision that touches long-term messaging architecture.
• Make-vs-fork for a small internal tool. Given its size and staleness, the credible product options are: (a) adopt as a dependency, (b) fork and vendor a thin Nova action of your own, or (c) skip it and build the action in-house against the OneSignal SDK. This package is more useful as a reference implementation than as a dependency.

When to Consider This Package

Consider it when:

• You already run Laravel Nova in production and OneSignal is your push provider (or you're choosing one now and are comfortable with it).
• You need manual, ops-driven broadcast pushes — a form with title/body/segment — and nothing more sophisticated.
• You're on a legacy Laravel/Nova stack matching its 2019-era release, and a quick internal tool is worth more than a maintained dependency.
• You treat it as a fork/vendor candidate: read it, copy the ~handful of files, and own the code so staleness and compatibility are your problem, not a package maintainer's.

Look elsewhere when:

• You don't use Nova. The entire value is the Nova admin integration; outside that it's a thin OneSignal wrapper you'd write yourself in an afternoon.
• You need a maintained dependency. Last release March 2019, 16 stars, zero dependents — no evidence of upkeep, security review, or compatibility with current Laravel/Nova versions. Expect to patch it yourself.
• Push must be triggered or personalized. No event-driven sends, no behavioral segmentation, no templates beyond what OneSignal offers.
• You need multi-channel or provider portability. OneSignal-only; migrating later means replacing this tool entirely.
• You have compliance, audit, or approval requirements. No approval workflows, send logs, roles/permissions, or unsubscribe governance visible — all of that would be on you.
• Push is a revenue-critical or customer-facing channel. Wrong risk profile for a single-maintainer, unmaintained package.

How to Pitch It (Stakeholders)

To executives: This is a small, free admin-panel add-on that lets ops send push notifications through OneSignal without engineering involvement — a low-cost way to test whether push is a channel worth investing in. The catch: it's an unmaintained 2019 open-source component with a single upstream maintainer and near-zero adoption. Treat it as a prototype or stopgap, not a platform. The recommendation is to use it (or copy its ~few files into our codebase) to prove demand and learn what ops actually needs, then decide whether push deserves a real build or a paid messaging vendor.

To engineering: It's a Nova tool with a form that calls OneSignal's send API — no data model, no queues, no abstractions worth inheriting. Given the 2019 release date and no dependents, don't take a hard dependency; vendor or reimplement the Nova action so we control compatibility, secrets handling, and logging. Budget it as hours, not a sprint, and use it to validate requirements (targeting, scheduling, approval, audit) before we commit to a notification architecture.