Notifier Laravel Package

Product Decisions This Supports

1. Where notification logic lives — and who owns it. This package forces a useful architectural decision into the open: does notification composition and delivery live in your domain model (Laravel's native Notifiable/Notification primitives), or in an admin-platform layer (Orchestra)? For customer-facing product the answer is the framework primitive plus a thin internal convention. For an internal admin/ops tool already built on Orchestra Platform, evaluating this component is legitimate — and that is the full extent of the decision it supports.

2. Build vs. buy vs. adopt-OSS, framed honestly. "Build from scratch" isn't on the table; Laravel ships notifications, channels, queues, and localization out of the box. The real comparison is framework primitive + a thin internal convention against a platform-specific wrapper. The former is cheaper, portable, and independent of a third party's release cadence. That's the trade-off to put in the decision record.

3. Roadmap posture: maintain or migrate — never greenfield. With zero stars, zero dependents, and a composite score of 0.3, this is not a forward-looking dependency. Its practical PM value is archaeological: if you've inherited an Orchestra Platform install, this package defines your current notification surface area and tells you exactly what must be reimplemented — templates, recipient resolution, transports, inbox/read-state — when you move to a supported Laravel line.

4. Feature-level decisions it actually touches (all table stakes, none differentiating):

• Internal admin announcements over the database channel — the lowest-blast-radius first use case.
• Transactional/account emails triggered by platform events.
• A simple authenticated in-app inbox with read/unread state.

5. Scoping the exit plan as a feature, not an afterthought. Because there's no upstream fix path, the insurance policy is an application-owned NotificationDispatcher contract with two implementations — one backed by this package, one backed by Illuminate\Notifications. Writing both in the same sprint converts a future migration from a rewrite into a container binding change. That's a roadmap commitment with a cost and a payoff you can defend.

6. Risk budgeting at upgrade planning. v6.0.0's entire changelog is "Update support to Laravel Framework v8" — that's the compatibility ceiling, not a floor. Every future Laravel upgrade is blocked on either a fork or a removal. Budget it as a line item at each upgrade planning cycle and assign a named owner. "No one noticed it stopped working" is the realistic failure mode for an unmaintained dependency sitting on a customer-visible surface.

7. Opportunity scores are not adoption signals. A non-zero "opportunity" figure against zero adoption typically describes an abandoned niche, not an underserved market. Don't let a metric invert the adoption decision.

When to Consider This Package

Consider it only when all of the following hold:

• You actively maintain an Orchestra Platform (or Orchestra-based extension) installation on a legacy Laravel line — ideally Laravel 8 — and this component is already installed or transitively required. Run composer why orchestra/notifier first; if it arrived as a transitive dependency, you inherit it and the job is to contain it, not to adopt it.
• You must preserve parity with existing notification records, templates, or inbox behaviour during a migration, and reading this source is materially faster than reverse-engineering the schema.
• Legal and security review is satisfied with the license and with the fact that there is no active release stream and effectively a single, inactive maintainer.
• You have the engineering capacity to write and maintain the adapter layer and integration tests yourself — you cannot patch the package.

Look elsewhere when:

• You are greenfield. Zero dependents means no battle-testing, no issue triage, and no CVE response path — supply-chain risk accepted for zero functional upside over Illuminate\Notifications.
• You need real capability. Multi-channel delivery, per-user channel preferences, digesting, and templating are all better served by the native stack, where you control the seams.
• You are on Laravel 9+. The solver will refuse or you'll be pinning illuminate/* to 8.x and downgrading the rest of the app. Find that out in a thirty-second --dry-run rather than after a branch of work.
• You need a vendor you can escalate to. There is no upstream issue tracker to search. Every "did the notification send?" investigation ends in reading vendor/ source.
• The notification surface is customer-visible and revenue-adjacent. Deliverability, retry semantics, idempotency, and duplicate sends on retry are all yours to solve behind an adapter — not something you can lean on the package for.

How to Pitch It (Stakeholders)

To executives — one paragraph: This is an internal component of a legacy admin platform, not a strategic dependency. It has zero external adopters, zero downstream dependents, and a maintenance ceiling of Laravel 8. Its value to us is narrow and real: if we run Orchestra Platform today, it defines our existing notification behaviour and tells us precisely what must be rebuilt to move onto a supported Laravel line. It is not a candidate for new product work, and we should not fund adoption of it. What we should fund is roughly one sprint of engineering to put a stable interface in front of it, so that replacing it later is a configuration change rather than a rewrite. Treat any future upgrade as an explicit line item with a named owner, because nobody upstream will tell us when it breaks.

To engineering — the summary: Pin exactly ("6.0.0", not ^6.0), commit the lock file, and run composer audit in CI with the understanding that a CVE here has no upstream remediation — the adapter swap is the remediation. Put the package behind an application-owned NotificationDispatcher contract with two implementations: one package-backed, one backed by Illuminate\Notifications. Route dispatch through domain events → queued listeners, never controllers. Centralise the notification-type → channel map in config. Check the migration for a notifications table collision with Laravel's native database channel before running migrate. Index (notifiable_id, read_at) and (notifiable_id, created_at) from day one, and set a retention policy before the table is big enough that cleanup becomes an outage risk. Add idempotency for retried jobs (a sent_notifications ledger keyed on event ID + recipient). Keep a small number of real integration tests — one per channel — because mocked unit tests will happily pass while the package silently does nothing.

The one-line ask: Approve the adapter-contract sprint now, while the system is working, rather than discovering the need for it during an upgrade or an incident.