Tomato Support Laravel Package

Product Decisions This Supports

First decision it forces: is this a feature or a dependency? The metadata calls it a "ticketing and support system with API for tomato admin," but the package's own documentation describes it as "the foundational support package… bundling shared helpers, base classes, and utilities that TomatoPHP applications and add-on packages rely on." Those are two different products with two different business cases. Before any roadmap conversation, one 30-minute spike (install it in a scratch app, run composer show, list the registered service providers and routes) resolves which one we're actually evaluating. Getting this wrong is how a PM ends up promising a help desk and shipping an autoload of string helpers.

Assuming it is the ticketing/admin module the repo description implies, it informs:

• Build vs. buy vs. borrow. This is the "borrow" rung between building a help desk in-house and buying seats in Zendesk/Intercom/Freshdesk. It's the right rung when support volume is low-to-moderate, the audience is internal staff or known customers, and per-seat pricing or data-residency rules make SaaS unattractive.
• Roadmap sequencing. In-admin ticketing (model, threads, statuses, assignment, notifications) is typically one to two sprints of undifferentiated work. If this package credibly delivers 70% of that, the decision is "install and configure" versus "build," and the freed capacity goes to differentiating work.
• Data ownership and procurement posture. Self-hosted ticketing keeps customer conversations in our own database under our own retention and access policy — a real line item in a security review and a legitimate differentiator for regulated or EU-resident customers.
• Platform commitment. Adoption is a vote for TomatoPHP/Filament, not just a feature choice. That should be evaluated by whoever owns our admin stack strategy, because it constrains future admin-panel hires and third-party add-on choices.

Assuming it is the foundation/helpers package the docs describe, it informs almost nothing at the product level — it becomes an engineering dependency decision (do we build on TomatoPHP's base classes or our own?), with the PM's only real interest being the resulting lock-in and the review burden it adds to every future package we adopt.

Assessment of this specific release (v1.0.3): empty changelog apart from a compare link. Low-signal patch. Semver implies no breaking changes; "implies" is not "verified." PM action: no roadmap impact, no migration, no spend, no re-litigation of the build-vs-buy call. Engineering action: diff v1.0.2...v1.0.3 before bumping and pin the version in composer.json rather than floating on ^1.0.

The signal that should actually shape the decision is not this release — it's the surrounding numbers: 0 stars, 0 dependents, one release in the visible history, last touched May 2024. Low stars and zero dependents mean effectively no peer review and no community to absorb a breaking change for us. That doesn't disqualify the package for an MVP, but it should push us toward the isolation strategy below and away from making it load-bearing.

When to Consider This Package

Consider it when most of these hold:

• We're already on Laravel + Filament, ideally the TomatoPHP admin stack — the package's value is largely inherited from that context and mostly evaporates outside it.
• Support/ticketing is adjacent to the product, not the product. It has to work; it does not have to be best-in-class.
• Volume is low to moderate (dozens to low thousands of tickets/month) handled by a small team inside the admin panel.
• We want tickets in our own database, under our own access controls and retention policy.
• We're time-boxed — an MVP, a pilot, or a v1 that must ship before support tooling earns its own budget line.
• We can absorb small-ecosystem risk: a maintainer-paced cadence, no vendor SLA, and a thin issue history.

Look elsewhere when any of these hold:

• We need omnichannel intake (email piping, inbound voice, WhatsApp, social), SLA timers with escalation, CSAT/NPS, or a knowledge base with deflection. None of that is implied by a scoped admin module, and closing the gap in-house is a product, not a task.
• Support is customer-facing at scale or revenue-critical — at that point per-seat SaaS is cheaper than the engineering time to reach parity.
• We need mature integrations: CRM sync, Jira/Linear escalation, Slack triage, warehouse analytics, SOC 2 / ISO evidence.
• Our admin is not Filament/TomatoPHP, or we're on a Laravel/Filament major the package hasn't declared support for.
• We require vendor SLAs, support contracts, or a documented security-review trail — unrealistic for a solo/small-maintainer OSS package.
• We need high-concurrency throughput and search at scale; a general-purpose ticket table becomes a database tuning project.

Adoption hygiene regardless of path — make these gates, not suggestions: confirm Laravel/PHP constraints and Filament major compatibility in composer.json; read the migrations, permission and policy surface before install; check last-commit and issue-response cadence; and because v1.0.3 ships an empty changelog, the diff review is non-optional.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: We can stand up a working support-ticket capability inside our existing admin panel using an open-source Laravel module instead of building it or buying per-seat SaaS. It keeps customer conversations in our own database, removes a multi-sprint build from the roadmap, and costs integration effort rather than a subscription. The trade-off is dependency on a small, thinly maintained open-source ecosystem: a good call for an MVP or low-to-moderate support volume, and something to revisit if support becomes revenue-critical, high-volume, or omnichannel. This release (v1.0.3) is a routine patch with no documented changes — no spend, no migration, no re-planning. One caveat: the package's metadata and its own documentation disagree about whether it's a ticketing module or a utilities library, so we're confirming that before we commit the roadmap story to anyone.

For engineering — the practical summary: Small-surface Filament/TomatoPHP package. If it's the ticketing module, it brings its own models, migrations, resources and policies into the admin panel; if it's the foundation package, it's shared helpers, base classes and a service provider we'd be building on top of. Resolve that first. Fit is conditional on our Filament major and Laravel/PHP constraints — read composer.json before committing, and don't assume the metadata is accurate. Pin to 1.0.3 exactly rather than floating on ^1.0, and review the v1.0.2...v1.0.3 diff ourselves since the changelog is empty. Budget the standard guardrails for a zero-dependent third-party package: wrap the ticket domain behind our own service interface so a future swap to a dedicated help desk never touches product code, and add smoke tests around ticket creation and reply flows so an upstream break surfaces in CI, not in production.

For the product team — what to communicate: We're choosing speed and data ownership over depth. Do not promise customers omnichannel intake, SLA guarantees, deflection metrics, or reporting depth on this foundation. Scope the first release to in-admin ticketing with clear intake, status, and assignment — the parts this package credibly delivers — and treat richer support workflows as a separate decision with its own business case and its own budget.