Nova Notification Feed Laravel Package

Product Decisions This Supports

• Build vs. buy for internal notification visibility. The package answers one narrow question: "did this user actually receive the notification we triggered, and when?" If that question is currently resolved by grepping logs or opening a database client, this is a candidate shortcut worth pricing. But scope it honestly — it is a thin Nova tool over Laravel's native notifications table, not a notification platform. It is a reference design and a cheap alternative, not a strategic dependency.
• Support/CS tooling investment. A bell dropdown in the admin panel lets Tier-1 agents verify transactional notification delivery (welcome emails, password resets, order confirmations, digests) during a live ticket without escalating to engineering. That is a measurable deflection from Tier-1 to Tier-2 and a defensible line item in a support-tooling budget.
• Roadmap disambiguation — admin audience only. It signals an in-app notification surface for operators, not end users. Do not cite it as progress toward a customer-facing notification center with preferences and channel routing; that requirement is not served by this package, and conflating the two will corrupt the roadmap narrative.
• Incident triage. During any release touching notification classes, a per-user timeline shortens the "queued, sent, failed, or never created?" investigation — the most common question in notification-related incident threads, and a recurring tax on engineering time.
• A decision to not buy a platform, made explicitly. A ~99-star, single-author package with zero dependents and a last release of March 2020 is a real alternative to Novu, Knock, Courier, or a commercial Nova tool. Use this evaluation to price that alternative honestly rather than to justify adoption by default.

When to Consider This Package

Consider it only when all of the following hold:

• You are on Laravel Nova 1–3 with a contemporaneous Laravel (roughly 5.8–7.x). Nova 4 rewrote the frontend on Vue 3 with a reworked tooling model; there has been no release since March 2020, so assume incompatibility until proven otherwise.
• The need is internal, read-only, and low-stakes — an ops/CS convenience, not a system of record.
• You have one team and one database, with no multi-tenant partitioning or per-tenant scoping requirements.
• You are prepared to fork and own the code. It is MIT and small; treat upstream as abandoned, vendor a pinned commit into your monorepo, and name a maintainer at adoption time.
• Volume is modest enough that a browser-rendered, polling feed is acceptable. It ships no delivery metrics, alerting, retention policy, segmentation, or preference management.

Look elsewhere — or build in-house — when:

• You are on Nova 4/5 or Laravel 9+. Zero releases in five years plus zero dependents is a maintenance liability, not a dependency; the Vue 2 front end is the most likely break point and installation cannot be assumed.
• You need end-user preferences, digest scheduling, channel routing, or per-tenant scoping — the native notifications table will not model this well, and no amount of UI work on top fixes that.
• You need compliance/audit guarantees (retention, immutability, PII redaction, access logging). This is a UI over an application table and inherits none of it.
• You require vendor support, an SLA, or security response on dependencies — there is no vendor, no SLA, and no issue triage.
• Alternatives to weigh: a custom Nova Resource + Tool over the notifications table (~1–2 engineer-days, fully owned, works on current Nova); a bespoke Nova tool for Nova 4+ (~1–2 engineer-weeks including Vue work); or a dedicated transactional-messaging platform if the real requirement is delivery reliability rather than a viewer.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a free, MIT-licensed admin-panel add-on that lets support and operations staff confirm whether a given user received a system notification, without filing an engineering ticket. It would save an estimated 1–3 days of build time and carries zero license cost — but it has not been updated since March 2020 and has no downstream dependents, so it will not run on our current Nova/Laravel versions without a fork we must maintain; that fork also inherits Vue 2 component work on day one. My recommendation is to treat it as reference design, not a dependency: spend the same small effort on a ~150-line Nova resource over our existing notifications table. That delivers the same support-deflection benefit, on a supported stack, with no orphaned third-party code — and leaves the door open to a proper notification platform if volume or compliance needs grow.

To engineering (one paragraph): It's a Nova Tool that reads Laravel's notifications table and renders a per-user bell feed — the value is the UI pattern, not the logic. Given the 2020 cutoff and Nova 4's frontend rewrite, assume it will not install. Three hard gates before any commitment: the composer.json PHP and laravel/nova constraints must resolve against our lockfile; the published JS must compile under our Nova asset pipeline (Vue 2 vs. 3 is decisive); and the migration must be idempotent alongside our existing notifications table. Two paths: (a) fork it, bump constraints, and budget half a day to two days per Nova major upgrade while owning a package with one author and no dependents; or (b) reimplement the view as a Nova Resource with a notifiable filter and read_at column, index on (notifiable_type, notifiable_id, read_at, created_at), add a prune/retention job, and ship it in a sprint. I'd take (b) and cite this package as prior art in the ticket — either way, add a smoke check so a silent asset-compilation break doesn't just make the bell disappear unnoticed.