Product Decisions This Supports
- Build vs. buy for push delivery. This package represents the "thin in-house wrapper" option in the classic build/buy/partner decision: one Laravel facade over FCM and APNs instead of a paid engagement platform (Braze, OneSignal, Airship) or a full Firebase SDK integration. It gives you a concrete cost anchor for the "build" branch — a few hundred lines and an afternoon versus a vendor contract.
- Scope and phasing for a notification feature. Use it to sketch the smallest viable slice of a roadmap item: device token registration, per-platform payloads, and a send call. That's enough to ship transactional push (order updates, alerts, auth-adjacent notices) without committing to a messaging platform's data model.
- Abstraction-layer justification. Because the package itself is a wrapper, it makes the case for owning the interface (
NotificationChannel / PushTransport contracts) while treating the delivery provider as swappable. The PM decision isn't "adopt this package"; it's "commit to a seam so this package — or any vendor — can be replaced without touching product code."
- Platform deprecation triage. The GCM support is a live reminder that push transports rotate (GCM → FCM legacy → FCM HTTP v1). Any roadmap item that touches push should carry an explicit maintenance line item, not be treated as a one-time build.
- Reference spec / spike material. With MIT licensing and a narrow surface area, it's usable as a starting scaffold or as a read-through for estimating an in-house implementation — useful when engineering needs a size estimate before you commit to a quarter.
- Vendor negotiation leverage. A credible "we can do this ourselves in a sprint" option materially changes pricing conversations with messaging vendors for low-complexity transactional use cases. Do not present it as a production-grade alternative — present it as the floor of the range.
When to Consider This Package
Consider it when all of the following hold:
- You already run a Laravel application and want push to live inside that codebase rather than as a separate service.
- Volume is low to moderate and the product needs transactional/campaign push only — no in-app messaging, no journey orchestration, no delivery analytics dashboards.
- You need both Android and iOS behind one call site and want to avoid maintaining two SDK integrations.
- Your team is willing to fork and own it: pin it, read the source, add tests, and track upstream FCM/APNs API changes yourselves.
- Engineering has capacity to add a transport abstraction on top, so a future migration is a swap, not a rewrite.
Look elsewhere when any of these apply:
- Zero-maintenance is a requirement. Last release was March 2023, there are no dependents and no stars, meaning essentially no community vetting, no issue triage, and no evidence of production use at scale. That is a supply-chain and bus-factor risk you are accepting, not a maturity signal.
- You need FCM HTTP v1 and modern APNs token-based auth confirmed. The presence of GCM (shut down by Google in 2019) in the stated feature set means you must verify the actual implementation against current APIs before trusting the description. Budget a spike day for this alone.
- You need rich media, localization, scheduling, A/B testing, delivery receipts, or per-user rate limiting. Those are platform features, not wrapper features.
- Compliance matters (health, finance, minors) — vendor SLAs, DPAs, and audit trails are the reason to buy rather than wrap.
- You're not on a compatible Laravel/PHP version, or you can't accept an unmaintained dependency in
composer.json. Prefer a maintained alternative or vendoring the code with attribution.
Net: treat this as a scaffold and an estimate, not a dependency you add and forget.
How to Pitch It (Stakeholders)
For executives (one paragraph): Push notifications are a small, well-understood feature, and we have a credible low-cost path to ship them inside our existing Laravel application rather than signing a messaging-platform contract. The specific open-source package we evaluated is a useful blueprint — MIT-licensed, narrow in scope, covering both iOS and Android — but it is effectively unmaintained, so my recommendation is not to depend on it directly. Instead, we take it as a starting point, own the code, and put a thin abstraction in front of the delivery provider. That gets us to market this quarter at near-zero incremental cost while keeping our options open if volume grows enough to justify a vendor later. The trade-off we're accepting is a modest, ongoing maintenance line — roughly a couple of engineer-days per year to track Apple and Google API changes — which is far cheaper than a platform contract at our current scale.
For engineering (the ask): Fork or vendor the package under our own namespace; do not depend on it as-is. Verify FCM HTTP v1 and APNs token-based auth are actually implemented rather than assumed from the README. Wrap it behind our own PushTransport interface so the provider is swappable. Add tests and CI. Assume a migration to a vendor or a maintained SDK once volume or feature demands cross a threshold we define up front.
The decision, stated plainly: Approve push as an in-house build using this package as a reference and scaffold; decline it as a long-term third-party dependency. If we later need campaign tooling, analytics, or enterprise compliance, that is the trigger to buy — not a change of heart.