Laravel Expo Notifier Laravel Package

Product Decisions This Supports

• Push notification delivery for mobile apps: This package wraps Expo's push notification service in Laravel idioms, so a PM can commit to server-driven mobile engagement (order updates, reminders, transactional alerts) without building a bespoke Expo API client.
• Build vs. buy: Strongly favors "buy/adopt" — the outbound-notification plumbing (device token storage, Expo API payloads, batching) is commodity work. Adopting shifts engineering effort toward notification content, targeting, and preference management, which is where product differentiation actually lives.
• Roadmap sequencing: Enables a "notifications MVP" milestone (single-channel transactional push) to be scheduled early and cheaply, then iterated into richer features (segmentation, scheduling, deep links) as the payload classes are extended.
• Use cases: Transactional alerts (shipping, payment, appointment), re-engagement nudges, and any Expo-managed React Native app already in the portfolio.
• Platform-agnostic reach: Because Expo fans out to iOS and Android, one integration supports both stores' push paths — a meaningful reduction in per-platform scope for a small team.

When to Consider This Package

Adopt when:

• The mobile client is React Native built on Expo (Expo push tokens, not raw APNs/FCM). Outside that, the abstraction adds no value.
• The team is Laravel/PHP-first and wants notifications to live in the same codebase as the rest of the backend rather than in a separate service.
• Needs are transactional and low-to-moderate volume — not high-frequency marketing campaigns requiring sophisticated throttling, send-time optimization, or analytics.
• Engineering is comfortable pinning versions and reading source: the 0.0.x version line signals a pre-stable API, so expect breaking changes between minor releases and budget for upgrade churn.

Look elsewhere when:

• You need rich campaign tooling (Journeys, A/B testing, segmentation, delivery analytics) — a dedicated platform (Braze, OneSignal, Airship) is the right buy.
• You require guaranteed delivery SLAs, audited compliance, or vendor support contracts — a community package with a single maintainer org is not that.
• You're on raw APNs/FCM without Expo, or on a non-Laravel stack.

How to Pitch It (Stakeholders)

To executives: This is a small, focused open-source library that lets our existing Laravel backend send push notifications to our Expo mobile app through the vendor's own delivery service. It removes weeks of custom integration work and keeps notifications inside the team and codebase we already own, with no new SaaS subscription. The main caveat is maturity: it's pre-1.0 and maintained by a single organization, so I'd recommend adopting it for transactional notifications now while keeping a paid platform as the fallback if our engagement ambitions grow beyond basic push.

To engineering: Thin, idiomatic wrapper over Expo's push API — message/payload value objects, a notification channel, and token handling that fits Laravel's notification system. Low integration cost; the trade-off is API instability at 0.0.x (this release is a single small fix to ExpoMessage), so pin the version and treat upgrades as scheduled work rather than automatic. Recommend a small abstraction boundary around sending so we can swap to a managed provider later without rewriting call sites.