Tomato Notifications Laravel Package

Product Decisions This Supports

• In-app notification center — build vs. borrow. The package delivers the three artifacts an MVP inbox actually needs: a persisted notification record with read/unread state, an admin-side composer, and a template store. That makes the decision concrete: spend 2–3 sprints building an internal messaging surface, or borrow one for a quarter, ship, and revisit once you know whether users act on in-app messages. For a first version, borrowing is defensible because the learning is the point, not the infrastructure.
• Roadmap sequencing across channels. Use this to validate the operational workflow — who writes copy, who approves, who sends, how you confirm it landed — on the cheapest channel (database/in-app) before funding email deliverability, SMS aggregation, or push infrastructure. Treat it as a channel-1 experiment harness, never as a channel strategy. Adopting it does not reduce the future work of building real multi-channel delivery.
• Template management as a product capability. If support or operations staff need to change notification copy without a deploy, that is a capability decision, not a library choice. This package makes "templates are editable by non-developers" cheap to test — and immediately forces the follow-on decisions you will otherwise defer indefinitely: variable whitelist, approval flow, locale variants, and send history.
• Back-office scope and support-cost reduction. For admin panels already on TomatoPHP/Filament, this is additive tooling for ops-composed announcements, onboarding nudges, and system alerts. It removes a recurring class of "can you change this message?" tickets from the engineering backlog — a win that is easy to justify and easy to measure post-adoption.
• Localization, auditability, and consent groundwork. A centralized template model is the natural seam for locale variants, send logs, opt-out/consent controls, and retention policy. Adopting it now shapes those decisions early; skipping it means retrofitting copy out of application code later, at higher cost.
• Dependency ownership posture. With a single maintainer, minimal adoption, and a mid-2024 last release, the real decision is about carrying a dependency, not adding a feature. That is a roadmap-level answer about whether the team has appetite for an owned-but-forked component versus a fully managed vendor — and it should be recorded as such, not buried in a backlog ticket.

When to Consider This Package

Consider adoption when:

• You are already on Laravel, and preferably the TomatoPHP/Filament admin stack, so this is additive rather than a heavy transitive dependency for a small feature.
• The immediate need is in-app/database notifications with admin-editable templates — not transactional email at volume, not SMS, not campaign tooling.
• The target surface is an internal tool, back-office app, or early MVP where speed to a learnable version beats vendor maturity.
• Non-developers need to change notification copy, and you are prepared to own the operating model around that — who may edit, what variables exist, how changes are reviewed.
• You can fund a 1–2 day spike and name an internal owner before committing, and you accept that forking under MIT is a realistic fallback.
• You will adopt pin-and-review upgrades as policy: exact version pin, composer why-not against Laravel/Filament constraints, and a review gate on every bump.
• You want to validate engagement with in-app messaging before funding multi-channel infrastructure.

Look elsewhere when:

• You need production-grade multi-channel delivery — deliverability, retries, provider failover, queue hardening, per-channel rate limiting. Laravel core plus a managed provider is the better answer.
• You require an SLA, security disclosure process, or active maintenance. One star, zero dependents, and a mid-2024 release mean you would be the first integration test, and your escalation path is reading the source.
• Your stack is not Laravel/TomatoPHP, or you cannot accept coupling to Filament admin conventions — the dependency tree is disproportionate to a template table plus a resolver.
• You need segmentation, experimentation, analytics, or automation. This is a composer and an inbox, not a campaign platform.
• Compliance or security obligations demand SSO, granular permissions, retention controls, and audit trails.
• Templating lets non-developers author content and you cannot verify that rendering uses restricted variable substitution rather than Blade or eval — that silently converts template-edit permission into code-execution permission and reframes the GUI selling point as a security review item.
• Your product depends on guaranteed delivery correctness — transactional or regulated messages — where a silently swallowed channel failure is unacceptable.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, MIT-licensed Laravel add-on that gives us an in-app notification inbox plus an admin screen for sending templated messages — a surface teams typically spend two to three sprints building. It can shorten the path to an MVP for internal messaging and eliminate a recurring class of "please change this copy" engineering tickets. The trade-off is maturity, not capability: minimal adoption, a single maintainer, and no recent release mean we should treat it as an accelerator we own, not a platform we depend on. Recommendation: fund a short spike, approve it for internal and MVP use only, and attach an explicit maintenance budget and a named owner. The MIT license means forking is legally clean, so our downside is bounded to engineering time rather than lock-in.

To engineering: It is Laravel-native and layers onto an existing TomatoPHP/Filament panel — a notification template model, a Filament CRUD resource, and a channel over Laravel's native Notification system. Laravel core handles delivery, queuing, and localization, so judge the buy decision against the narrow scope: template storage, resolution, and substitution. The spike must answer five questions — does it install against our pinned Laravel/Filament versions, does the renderer use restricted substitution or Blade::render/eval, are missing variables caught at save time, are rendered subjects and bodies snapshotted into the queued job or resolved at execution time, and do channel failures reach error tracking. Wrap it behind internal TemplateResolver/TemplateRenderer interfaces, pin the version exactly, add it to dependency review in CI, and migrate notification types one at a time behind a flag. If it fails the spike, the fallback is 150–250 lines in-house on the same data model.

Commitment to make: A 1–2 day spike on a throwaway branch, sending one templated notification end-to-end through a queued job including a deliberate missing-variable case. Adopt for internal/MVP notification centers if it passes; avoid for customer-facing, high-stakes, or multi-channel messaging unless we are ready to fork and own it. Conditions of adoption: a named internal owner, a pinned version, a short internal README documenting resolver behavior, variable validation, and the upgrade procedure, and a standing allowance of 1–3 engineer-days per quarter for maintenance.