Filament Notifier Laravel Package

Product Decisions This Supports

• Build vs. buy for the notification layer. The package is effectively a "buy-with-source" option: MIT-licensed scaffolding for channel fan-out (Email/SMS/Slack/Discord/Push), template CRUD with {{variable}} interpolation, scheduling, and event-to-template mapping. It moves the decision from "do we build a notification service?" to "do we adopt and fork this scaffold?" — a materially smaller commitment.
• Roadmap sequencing for a notification preference center. The built-in REST API (/api/notifier/preferences, /available, per-event GET/PUT) plus an admin-controlled allow_override flag lets you ship user-controlled channel opt-in/opt-out as a v1 feature rather than a later roadmap item. This is often the single most expensive piece of a notification system to build correctly (event catalog + channel matrix + auth + admin governance).
• Feature scoping: templates vs. code-defined notifications. Laravel's native notifications put message copy in PHP classes, which forces a deploy for every wording change. This package decouples copy from code via DB-backed templates and a Filament resource — a direct answer to "who owns notification copy, marketing or engineering?" If the answer is "marketing/ops," this supports that operating model.
• Observability investment decision. Open/click tracking, a 30-day time-series chart, channel-performance comparison, and a live rate-limit status widget give you a post-launch feedback loop. This supports deciding whether analytics on notifications is a v1 need or a later optimization — if you adopt it, analytics is nearly free; if you build in-house, it is typically deferred indefinitely.
• Deliverability and abuse-control posture. Per-minute/hour/day rate limiting enforced pre-send is a compliance and cost-control lever. Product-relevant for any app where a retry loop or a buggy event listener could otherwise blast a user base or burn SMS budget.
• Channel expansion as a config change, not a project. Adding Slack or Discord is config/notifier.php plus env vars; a ChannelDriverInterface exists for anything custom. This supports committing to "we'll add channels when customers ask" without pre-allocating engineering capacity.
• Use cases it fits: internal/admin tooling on Filament where operators manage templates and inspect engagement; B2B SaaS back-offices with a small user base and heterogeneous channel needs; MVPs that need an ops-visible notification console within a sprint rather than a quarter.

When to Consider This Package

Adopt when:

• Your application is already on FilamentPHP + Laravel — the entire value proposition (admin resources, dashboard widgets, settings pages) is Filament-only. Off Filament, you inherit the database tables and services but lose most of the product.
• You need an operator-facing notification console (create templates, map events, see opens/clicks) more than you need raw throughput or deliverability guarantees.
• You are comfortable owning the code: fork it, pin the version, and treat upstream as a reference implementation rather than a dependency you rely on for fixes.
• Volume is moderate and non-critical — transactional/app notifications where a missed send is a nuisance, not a contractual or financial event.
• You want a head start on the preference center and template model, which are the parts most teams underestimate.

Look elsewhere when:

• Adoption risk is unacceptable. 36 stars, 0 dependents, and a single-maintainer profile mean no bus factor, no community triage, and no security-response process. For anything in a regulated, high-volume, or revenue-critical path, that is disqualifying on its own.
• You need real deliverability engineering — bounce/complaint handling, dedicated IPs, suppression lists, DKIM/SPF guidance, provider failover. This package delegates sending to whatever mailer/webhook you configure; it does not manage reputation.
• You need durable delivery semantics — guaranteed retries with backoff, idempotency/deduplication, dead-letter handling, per-tenant isolation. The README does not evidence these; assume you build them.
• You are not on Filament — evaluate Laravel's first-party notifications plus community channel packages, or a dedicated notification infrastructure vendor (Knock, Courier, Novu) for preference management and workflow orchestration across services.
• You need multi-tenant / multi-brand scoping as a first-class concept, or an event catalog owned by product rather than by config files.
• You require vendor support or an SLA — there is none to buy here.

Diligence checklist before committing: confirm queue integration and retry behavior for each driver; verify how the tracking pixel and click-rewrite interact with your sending domain and link-wrapping policy (tracking pixels are a known spam-score and privacy-review trigger, and GDPR/CAN-SPAM exposure sits with you, not the package); confirm the retention_days cleanup command is scheduled; test the PUT /preferences/{eventKey} path against your auth guard rather than the package's assumptions.

How to Pitch It (Stakeholders)

To executives — one paragraph: This is an MIT-licensed, Filament-native notification console that would otherwise cost us roughly one to two engineer-months to build: multi-channel delivery, editable templates with variables, scheduled and event-triggered sends, a user-facing preference API, open/click analytics, and rate limiting. It lets us ship a credible notification experience — including the preference center customers and compliance reviewers ask for — in weeks instead of a quarter, at zero license cost. The trade-off is maintenance: it is a small, single-maintainer open-source project, so we are buying a head start, not a vendor relationship. We should adopt it for admin-facing and non-critical notifications, pin and fork the version we ship, and keep high-volume or revenue-critical sending on a path we control. Recommendation: pilot it in one product area, measure, then decide on broader adoption.

To engineering — the framing: Treat this as a forkable scaffold, not a dependency. It gives us a working data model (channels, events, templates, notifications, preferences), a Filament admin surface, a preference REST API, and tracking endpoints — all the tedious, low-differentiation parts. What it does not give us is production hardening: verify queue integration, retry/backoff, idempotency, and failure isolation before we trust it with anything important. Plan to vendor it, add our own tests around the send path, and treat upstream commits as reference material. If we are not on Filament, the ROI collapses — do not adopt it as a generic Laravel notification layer.

What we are explicitly not buying: an SLA, a security-response process, deliverability management, or a community to lean on. Make that trade-off visible in the decision record rather than discovering it during an incident.