Tomato Notifications Module Laravel Package

Product Decisions This Supports

• Build vs. buy for in-app notifications. This module provides a Filament/Tomato Admin UI layer over Laravel's native notification system (database notifications, read/unread state, per-user feeds). It replaces a scoped-but-non-trivial build: notification list views, mark-as-read actions, filters, and admin-side send/broadcast screens.
• Roadmap sequencing. If a "notification center," admin announcement/broadcast tool, or per-user activity inbox is on the roadmap, this can compress that work from a multi-sprint build to an integration task — freeing the team to spend the cycle on differentiation instead of CRUD UI.
• Feature scoping. Because it sits on top of Laravel's Notifiable / DatabaseNotification primitives rather than replacing them, it supports a phased plan: ship in-app notifications now, add email/SMS/push channels later via standard Laravel channels without re-architecting.
• Admin/ops tooling decisions. Supports whether ops teams get self-serve messaging capability, or whether every notification stays a code change. That is a support-load and time-to-communicate decision, not just a technical one.
• Vendor and lock-in posture. Adoption is low-risk and reversible: the module is a UI convenience over framework primitives, so the exit cost is mostly re-implementing screens, not migrating data or contracts. This makes it a reasonable bet even under ecosystem uncertainty.
• Ecosystem bet. Adopting it also implies alignment with the TomatoPHP/Filament stack. That is a platform decision worth making explicitly rather than by accident.

When to Consider This Package

Consider it when:

• You are already running Tomato Admin or Filament v3+ and want a drop-in notification inbox without building screens.
• Your notification needs are in-app-first: per-user feeds, unread badges, admin broadcast, read state.
• You want to stay on Laravel-native semantics (notifications table, markAsRead, standard channels) so future channel work is additive.
• You have a small team and the opportunity cost of building notification UI exceeds the cost of adopting and reviewing a community module.
• You can absorb single-maintainer / community-ecosystem risk — pin the version, review the diff, and keep the ability to fork.

Look elsewhere when:

• You are not on Filament/Tomato Admin — most of the value is the admin UI, and you would be pulling in a dependency for little return.
• You need multi-channel orchestration, delivery guarantees, digest scheduling, or complex preference matrices — a dedicated service (Knock, Courier, Novu) or a purpose-built internal service is a better fit.
• You need enterprise support, SLAs, or documented deprecation policy — this ecosystem does not typically offer that.
• You require strict supply-chain review — release notes for v1.0.2 are empty (changelog link only), so provenance and change intent must be established by reading the diff yourself, not from the release.
• Your frontend is Inertia/Livewire but not Filament — you would be adopting the framework half without the UI half.

Adoption gate: confirm the package's supported Filament and Laravel version range against your stack, and review the v1.0.1→v1.0.2 diff manually before bumping. A patch release with no notes is not a red flag on its own, but it does mean the changelog cannot be your diligence.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-cost accelerator for a capability every product eventually needs — telling users what happened. It gives us an in-app notification inbox and an admin screen to send announcements, built on Laravel's own notification system rather than a paid third-party service. That means no new vendor contract, no per-message fees, and no lock-in: if we outgrow it, we keep the data and replace only the screens. The trade-off is that it comes from a community ecosystem rather than a vendor with a support contract, so we would pin the version and review updates before applying them. Recommendation: adopt as an accelerator for in-app notifications, not as our long-term multi-channel strategy.

For engineering (talking points):

• What it is: a Filament/Tomato Admin module wrapping Laravel's native notification system — database notifications, read state, and admin send screens. Not a notification-delivery platform.
• Integration surface: migrations for the notifications table, Filament resources/pages, and standard Notifiable usage. Coupling to our domain is minimal and mostly reversible.
• What we must own: channel strategy (mail/SMS/push), templating and localization, retry/failure handling, and delivery observability — none of which this package is intended to solve.
• Release hygiene: v1.0.2 shipped with an empty changelog (compare link only). Read the diff before merging; pin the version in composer.json and treat upgrades as reviewed changes, not routine patches.
• Risk posture: single-maintainer project. Mitigate with version pinning, a fork-if-needed plan, and keeping our notification logic in our own classes so the module stays a replaceable UI layer.
• Decision requested: approve adopting it for the in-app notification MVP, with a follow-up review at the point we need multi-channel delivery or user-level notification preferences — that is the signal to build or buy something more substantial.