Novu Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy on notification infrastructure. This package forces the central decision into the open: do we keep channel routing, templating, retries, digests, and user preferences inside our Laravel app, or push them to Novu as a service? The SDK is the cheap integration surface that lets us prototype that answer instead of debating it.
• Roadmap sequencing for channel expansion. Adding SMS, push, chat, or an in-app inbox usually means re-architecting "what happened" into "where it goes." Novu's workflow model makes channel expansion largely configuration, so a PM can sequence channels by customer demand rather than by engineering cost.
• Consistency across multiple Laravel apps/services. If we run more than one PHP service, a shared notification layer prevents each team from re-implementing preferences, unsubscribe, quiet hours, and retry logic slightly differently.
• In-app notification center as a feature bet. An inbox done well (read state, real-time delivery, pagination, preference UI) is a recurring roadmap item with a deceptively high cost. This is the backend hook for a hosted inbox component.
• Owning vs. renting the "hidden 80%." Digests, batching, delays, and per-user channel preferences are where notification projects overrun. This decision determines whether we staff that or pay for it.
• Vendor evaluation with a real exit ramp. The package is thin and MIT-licensed, so a time-boxed spike is cheap and reversible — useful when we need evidence, not opinion, before committing.

When to Consider This Package

Evaluate when:

• You need three or more delivery channels, or expect to within two quarters, and don't want to build preference management, digests, and retries in-house.
• Notification logic is already leaking across controllers, jobs, and queues and you want a single declarative trigger point.
• An in-app inbox is on the roadmap and you'd rather not build feed infrastructure.
• You're comfortable calling Novu's REST API and treating this SDK as a convenience wrapper.

Look elsewhere or treat with strong caution when:

• The package is archived (last release 2024-04-09, 12 stars, 0 dependents, no maintainer activity). It is not a maintained dependency — do not put it on a critical path expecting security patches or Laravel-version compatibility. Treat it as reference code: fork it under MIT, or skip it and call the Novu API directly via Http::withToken(). The wrapper is small; the API is the product.
• Your need is single-channel transactional email — Laravel's built-in Notifications and Mail plus a provider is cheaper and actively maintained.
• You require vendor SLA, security response commitments, or data residency guarantees — evaluate Novu the platform directly, not through an abandoned SDK.
• Your team has no appetite to own a forked abstraction layer, or compliance forbids sending recipient data and notification content to a third party.
• You need deep framework-native integration (Eloquent observers, queue events) that an unmaintained wrapper won't keep in sync with Laravel releases.

How to Pitch It (Stakeholders)

To executives: Novu is a buy-not-build option for notification infrastructure — the plumbing behind email, SMS, push, in-app, and chat. Building that in-house typically costs a quarter or more of engineering time, then keeps costing every time we add a channel, a digest, or a per-user preference. The Laravel SDK would let our PHP services plug in quickly, and it's MIT-licensed, so there's no code-level lock-in. The caveat matters: the SDK itself is archived and effectively unmaintained (12 stars, no dependents, last release April 2024). So the recommendation is a low-cost spike against Novu's API — not adoption of this package as a long-term dependency. Worst case we spend a few days and learn whether Novu fits our use cases; best case we remove a multi-quarter build from the roadmap and reclaim engineering capacity for differentiators.

To engineering: it's a thin Laravel wrapper over Novu's REST API — subscribers, triggers, topics, preferences. MIT, no runtime surprises, but archived, so we'd either fork it or drop it and call the API directly with Laravel's HTTP client. Integration risk is low either way; the real evaluation is whether Novu's workflow and preference model matches how we actually notify users.