Filament Alerts Laravel Package

Product Decisions This Supports

• Build vs. buy for in-app communications infrastructure. This package covers the unglamorous 80% of a notification system — template storage, multi-channel dispatch (database/email/FCM), queue-based delivery, and delivery logs — so the team can avoid spending a sprint or two rebuilding an admin-managed notification layer on top of Laravel's native Notifiable plumbing. The decision is framed as: buy the plumbing, build the product-specific message logic on top.
• Feature scope for "notify users" epics. Instead of a bespoke notifications table, CRUD screens, and per-channel jobs, the epic collapses into template authoring, channel selection, and a facade call. Good candidate for a phase-1 release that ships user-visible notifications early and defers segmentation, scheduling, and campaign analytics to a later phase.
• Roadmap sequencing for admin/ops tooling. Because templates, logs, and a "send notification" screen exist out of the box, ops/marketing can self-serve routine announcements without engineering involvement. That's a resourcing decision: fewer interrupt-driven engineering requests in exchange for an admin surface the team must govern.
• Channel expansion decisions. Database + email are table stakes; FCM push is available as a companion driver package. The decision to add push (and Discord, via another driver) becomes a small increment rather than a re-architecture — a cheap way to validate whether a push channel earns its maintenance cost before committing.
• Extensibility as a hedge on vendor lock-in. Custom drivers, types, actions, and user types are registered from the app's service provider, and all resource classes are swappable via config. This supports an architecture decision to treat the package as an internal seam: our domain code calls our own wrapper, the package is one implementation behind it.
• Operational governance decisions. Delivery logs support "did the user actually get told?" support conversations and incident review. The optional Settings Hub that lets SMTP credentials be edited from the GUI is a genuine decision point — convenient for ops, but it moves mail credentials into the database and out of deployment config, which needs a security sign-off.
• UI surface decisions. hideNotificationsResources() allows the admin resources to be suppressed, so the same package can back a fully custom in-product notification center without leaking a generic CRUD UI into the panel.

When to Consider This Package

Consider it when:

• The product is already a Laravel + Filament panel and users who receive notifications are panel users (staff, admins, operators) or models you can attach the provided trait to. Outside a Filament context, the value proposition mostly evaporates and you're paying for UI you won't use.
• The requirement is transactional, template-driven messaging — "tell this user this thing happened, on this channel" — not marketing automation. There's no evidence of segmentation, scheduling, drip sequences, A/B testing, or campaign analytics.
• Your team is small enough that a weekend of integration beats a month of building, and comfortable reading package source when docs run thin. The README is unusually thorough for its size, but it is still a single-maintainer README, not a documentation site.
• You can accept queue dependency as a hard operational requirement — every send runs through a worker. If your deployment doesn't reliably run queue:work, notifications will silently sit in the queue and the logs will make that look like a delivery problem.
• Vendor risk is tolerable. 83 stars and zero dependents on Packagist is the key signal here: essentially no one else is depending on this in production, so you are an early adopter, not a follower. That's fine for an internal tool, less fine for anything customer-critical with an SLA. Mitigations that make adoption defensible: MIT license (you can fork), pin the version, wrap the facade in your own service class, and budget for eventually owning the code.
• You're comfortable with the maintenance model. One author, active releases, CI badges for styling and tests, but no LTS, no support contract, no security policy visible. Treat it as "code we acquired," not "a vendor we bought."

Look elsewhere when:

• You need an enterprise-grade notification platform — deliverability management, bounce/complaint handling, provider failover, rate limiting, preference centers, unsubscribe compliance, audit trails for regulated comms. That's a dedicated ESP (or Laravel's own Notification system wired to one), not an admin-panel package.
• You need marketing/campaign features. This is not that, and stretching it there will cost more than adopting a purpose-built tool.
• Your non-Filament surfaces (mobile app, public web, partner API) are the primary notification consumers. FCM service-worker integration helps, but the management plane assumes Filament.
• Procurement requires a support contract or security review artifacts. Note the unchecked "Register Notification Templates" item in the feature list — there are still rough edges, and you'll be discovering them yourself.
• The team has no appetite for reading vendor source. With this dependency profile, that's a prerequisite, not a nice-to-have.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can ship an admin-managed user notification system — reusable message templates, email and in-app delivery, push-ready, with a full delivery history — in days instead of a multi-week build. It's an MIT-licensed package that plugs into the Filament admin panel we already run, so the cost is integration and a security review, not new headcount or a vendor contract. The trade-off is maturity: it's a small open-source project with essentially no other production users, so we should treat it as code we're adopting and be prepared to fork and maintain it. My recommendation is to adopt it behind our own abstraction layer, pilot it on internal/staff notifications first, and only extend it to customer-facing channels once it has a clean quarter of operational history.

For engineering (the asks): Integrate via the FilamentAlertsPlugin, add InteractsWithNotifications to the relevant models, and guarantee a supervised queue worker — sends are queued, and an unsupervised worker means notifications that look sent but aren't. Do not call the FilamentAlerts facade directly from domain code; put our own NotificationService in front of it so the package is replaceable. Pin the version, fork it into our VCS so we control patches, and log an ADR recording that we accepted single-maintainer risk deliberately. Register any custom drivers/types from AppServiceProvider::boot() — the extension points are clean and well-documented. Flag two items for review before rollout: the Settings Hub writes SMTP credentials to the database (needs a security sign-off or we don't enable it), and the template builder is the primary thing ops will touch, so it needs a short enablement doc rather than a support queue.