Filament Fcm Laravel Package

Product Decisions This Supports

• Build vs. buy, framed honestly as build-vs-build. This is a thin, MIT-licensed FCM adapter, not a messaging platform. The real decision is "absorb ~a few hundred lines of adapter code (free, but owned by us)" versus "write the same adapter ourselves." Reject the temptation to compare it to Braze/OneSignal/Airship — that's a different purchase with a different budget line. Making that reframing explicit is the single most valuable thing a PM does with this package in a review.
• Roadmap sequencing for operational alerting. It turns "get the approver / on-call engineer / support owner notified on their phone" from a platform initiative into a bounded feature with a two-week tail. For internal workflows — approval escalation, refund review, failed sync jobs, ticket assignment — mobile alerting can plausibly land this quarter instead of next year. That's a sequencing win, not a capability win; don't oversell it as the latter.
• Architecture as a product decision: one alert model, multiple surfaces. The package's real value is that "push" becomes another channel on notifications we already define in Laravel. Say this in design review: it prevents alert logic from forking between the admin panel and a mobile client, which is where notification-driven products quietly rot. The dependency is justified by maintainability, not features.
• A cheap experiment before funding a mobile companion app. The highest-leverage use is a scoped pilot: one workflow, two weeks, push to real devices, measure whether operator response time or missed-approval rate actually moves. That yields evidence for or against broader mobile investment at near-zero cost. Frame it as a hypothesis test with a kill criterion, not a v1.
• Feature-fit triage — decide the negative scope now. Strong fits: back-office alerts, per-user staff notifications, approval/escalation pings, low-volume customer notifications where the audience is already modeled as Filament users. Out of scope: campaigns, segmentation, A/B testing, drip sequences, delivery/open analytics, multi-channel orchestration. This package won't fail loudly on the weak fits — it will simply not do them, and a stakeholder will ask for them in month three. Write the "not now" list into the PRD.
• Ownership costing. Free license ≠ free feature. Budget ongoing ownership: a maintenance owner, a push-delivery health check (token pruning, per-platform error-rate alerting), and a line item on every Filament major upgrade to re-verify one end-to-end send. That's the honest total cost of ownership to put next to the build alternative.

When to Consider This Package

Consider it when:

• You are already on Filament and PHP/Laravel, with an admin panel your internal users live in daily. The plugin's value is proportional to how much of your operational surface is already in Filament.
• The audience is staff, not the public. Push to a few hundred known users whose accounts you control is squarely the sweet spot.
• The use case is transactional/operational — escalations, assignments, failures, approvals — where a deep link into the panel is a complete experience.
• You want a same-day demo. A Filament page that sends a push is the fastest way to get stakeholders to feel the feature and give real feedback.
• You can commit an engineer-week for a real integration (token registration endpoint, queue + retry, invalid-token pruning, a PushChannel seam so you're not married to the package) — not just the half-day spike to prove credentials work.
• Your platform matrix is bounded. Android is straightforward; iOS requires an APNs key and web requires VAPID, and both are where "push is broken" tickets actually live. If iOS is a first-class target, plan the credential work as a real task, not a footnote.

Look elsewhere when:

• The requirement is marketing or lifecycle messaging. No campaigns, no segmentation, no scheduling, no templates, no open-rate analytics. Reach for a dedicated platform (OneSignal, Braze, Firebase's own console at small scale) — or scope the requirement out.
• You need delivery observability as a product feature. FCM accepting a send proves nothing about delivery; this package ships no analytics, so a "did they see it" dashboard is your build.
• You're pre-Filament, or on a Filament major the package doesn't declare support for. Hard coupling means version mismatch is a hard stop, not a weekend patch.
• You need a vendor with a support contract, SLA, or multiple maintainers. This is a single-maintainer plugin with a small star count and, at assessment time, zero dependent packages — that's a signal about ecosystem validation, not code quality. If procurement requires a supported vendor, this fails on policy regardless of merit.
• You're multi-tenant and cannot ship a schema change. The token table almost certainly needs a tenant_id the package doesn't provide; you'll write your own migration and scope queries. If adding columns to a third-party table is off-limits in your org, that's a blocker.
• Push is on the critical path for revenue or safety. Regulated or high-stakes alerting with a single-maintainer adapter and no delivery guarantees deserves either a buy with support or an internal build with an on-call owner.

How to Pitch It (Stakeholders)

To executives: We can add mobile push alerts to the admin panel for effectively zero license cost, using the Firebase infrastructure we already trust, without buying a marketing/engagement suite. The proposed scope is deliberately narrow: operational alerts to internal staff — approvals, escalations, failed jobs — delivered as one more channel on notifications we already send. Recommended next step is a two-week pilot on one workflow with a stated success metric (e.g. median time-to-approve, missed-escalation count) and a kill criterion. If the pilot shows no behavior change, we stop and have spent one engineer-week, not one quarter. The risks are known and bounded: a small single-maintainer dependency we'll insulate behind our own interface, plus an ongoing ownership cost for token lifecycle and delivery monitoring — both of which we would carry with any build.

To engineering: We are not adopting a messaging platform; we're adopting a thin Filament-facing adapter for FCM HTTP v1 and wrapping it immediately behind our own PushChannel interface so it's replaceable in an hour. The real work isn't the package — it's the four things it doesn't do: an authenticated device-token registration endpoint (user binding derived from the session, never the request body), a queued send path with retry and invalid-token pruning, a tenant_id migration if we run tenancy, and per-platform delivery monitoring because FCM's 200 says nothing about APNs. Plan an engineer-week, not an afternoon. Treat the package as a demo accelerant and a head start, not the finished subsystem. We'll pin the version, fork with upstream as a remote, and add "one end-to-end push" to the Filament upgrade checklist.