Tomato Products Module Laravel Package

Product Decisions This Supports

• Build vs. buy for the catalog slice. The real decision this package informs is narrow but concrete: fund two to four weeks of internal work to build product CRUD, categories, pricing fields, and an admin surface — or adopt this and spend that time on differentiation. Treat it as a candidate for the commodity part of the roadmap, not the part customers pay for.
• Time-to-first-demo for back-office tooling. Because it ships as a TomatoPHP/Filament module, the practical payoff is a working product management screen early. That is useful for internal tools, prototypes, and stakeholder demos — and it de-risks the "does the admin feel right?" conversation before engineering commits to a schema.
• Roadmap scoping by exclusion. The package covers products, variations, prices, and stock fields — not pricing engines, tax, inventory reservation, cart, checkout, or promotions. If a roadmap item depends on those, this package sits upstream of the problem rather than solving it. That is a useful scoping input: it tells you the catalog layer is cheap and the commerce logic is where the estimate actually lives.
• Market coverage / i18n as a planning input. The v1.0.2 and v1.0.3 releases are translation-only. That is a signal rather than a feature: the maintainers are localizing admin labels and validation messages, which matters if you plan to operate in more than one language and don't want to hand-maintain translated back-office strings.
• Maintenance-risk posture. v1.0.x, 1 GitHub star, 0 dependents, and a last release in June 2024 put this firmly in the "adopt with an escape hatch" bucket. That feeds a genuine decision: is the catalog domain one we're willing to own a patch set for, or do we want a vendor with a support commitment?
• Explicit non-decision. A translation patch should not move a build-vs-buy conclusion. It is evidence of liveness only. Keep the decision gated on a technical spike — the cost of the spike is trivial next to discovering schema mismatches mid-build.

When to Consider This Package

Consider it when most of the following hold:

• You are already on Laravel and either running TomatoPHP or willing to adopt its module conventions. Mixing module ecosystems is where these packages get expensive, and this one assumes the surrounding stack rather than standing alone.
• Your product needs a catalog-shaped domain — products with names, descriptions, categories, custom attributes, variations, price and stock fields — and your differentiation lives downstream of the catalog (workflow, integrations, pricing logic), not in how products are stored.
• You want an admin surface quickly and are willing to accept someone else's UI opinions, then extend or reskin via published views and subclassed Filament resources.
• Multilingual admin content is a requirement and ongoing translation activity is a plus.
• You have in-house Laravel capacity to pin a version, carry a small patch set, and fork if upstream goes quiet.

Look elsewhere when:

• You need commerce-grade guarantees: inventory accuracy under concurrency, tax, multi-currency pricing rules, or an order lifecycle. This is a products module, not a commerce engine. Evaluate a dedicated platform rather than assembling one from parts.
• You require a published support policy, SLA, security disclosure process, or a maintained LTS line. v1.0.x with translation-only commits and near-zero adoption does not demonstrate that.
• Your architecture is API-first/headless with a non-Laravel admin, or you are not on Filament — this package ships no JSON API, so you would be mounting your own controllers on its models anyway.
• Your data model is atypical enough (variant matrices, BOM, subscriptions, regulated goods) that adapting a generic product schema costs more than authoring it.
• Dependency-tree or provenance review is a blocker. As one module in a large tomatophp/* monorepo, a composer update on any single module can drift the whole set.

Minimum gate before adoption: a two-day spike that (1) installs at a pinned tag into a real host app, (2) maps your actual catalog fields onto its schema and logs every gap, (3) exercises the admin UI for your top three editor workflows, and (4) produces an estimate for the gap list. Adopt only if that estimate is materially below building — and only if the exit plan is written down.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, open-source building block for the product-catalog portion of a Laravel application — the screens and data structures for managing products, variations, prices, and stock, not the storefront or the money-handling logic. The most recent release is a translation update, which tells us it is alive but adds no capability. The case for it is speed: it can compress weeks of routine back-office work into days, letting engineers spend time on the parts customers actually pay for. The case against is ownership: it is early-stage (v1.0.x), effectively single-maintainer, has essentially no adoption yet, and carries no support commitment — so we would be accepting responsibility for patching and forking it. My recommendation is a short, time-boxed technical spike to quantify fit and produce a gap list before we commit either way. The spike is cheap; discovering schema mismatches mid-build is not.

To engineering: This is a Laravel package (tomatophp/tomato-products-module) in the TomatoPHP module ecosystem, oriented around product catalog management with a Filament admin UI. v1.0.2 is translation strings only — no API, schema, or behavior changes, so there is no migration or regression risk from the bump, but also nothing to adopt for. Treat it as a candidate dependency, not an approved one:

• Pin the exact tag; do not track main. Pin the whole tomatophp/* set together, since upgrading one module can drift the rest.
• Audit the dependency tree, license, service-provider side effects, and any migrations it publishes into our schema. Confirm Filament major-version compatibility against the package composer.json before any host-app upgrade.
• Identify the seams: how we extend the product model and Filament resources without editing vendor/, and how cleanly we could extract or replace the module later. Prefer config overrides, published views, subclassed resources, and model observers.
• Deliverable from the spike: a field-by-field mapping against our real catalog, the gap/estimation list, and a one-page exit plan describing how we fork and carry it if upstream goes quiet.

If those come back clean, the pitch is straightforward: we buy the commodity catalog admin and spend our engineers on the parts customers differentiate on. If they don't, we build the schema ourselves — and we keep the option open either way.