Tomato Products Laravel Package

Product Decisions This Supports

• Build vs. buy for catalog administration. The package supplies product CRUD, categories, tags, media, pricing, SKU, stock, and translatable fields as Filament resources. The decision it collapses is narrow but real: spend 2–4 engineering weeks building an internal product admin, or install one and redeploy that capacity against differentiators? When catalog administration is table stakes and not your moat, this tilts toward adopt.
• Scope boundary between "catalog admin" and "commerce engine." This is a product-data management surface — it is not order processing, tax, pricing-rules, promotions, or inventory orchestration. Adopting it forces an explicit, roadmap-level conversation: what owns product data, and what owns transactions? That boundary is a product decision, not an implementation detail.
• Time-to-first-demo / internal tooling velocity. On an existing Laravel + Filament stack, a working catalog with variation, price, and stock is a days-not-weeks deliverable. Directly useful for validating a catalog-driven hypothesis (marketplace, B2B portal, internal PIM-lite) before committing roadmap capacity.
• Variant and multi-store roadmap timing. Variants exist; multi-currency, multi-store, and per-tenant catalogs are not assumed. The PM decision is whether those are near-term requirements — if yes, this becomes a bootstrap to fork/extend, not a destination, and the roadmap must budget the extension work explicitly.
• Roadmap sequencing for downstream integrations. The package's tables become shared state the moment migrate runs. The PM decides when storefront, ERP, or PIM integrations get built and against what contract — an adapter layer up front is a scheduling decision that buys cheap replaceability later.
• Deprioritizing the internal-tools backlog. Anything on the admin backlog that is "product list, product edit, product images, categories" can be closed as satisfied, freeing capacity for customer-facing work.
• Not a decision this supports: choosing a commerce platform, defining pricing strategy, tax handling, or headless/API-first product architecture. Those need separate evaluation.

When to Consider This Package

Consider it when:

• The application is already Laravel and committed to Filament for its admin panel, ideally with the surrounding TomatoPHP core modules (users, permissions, translations, settings). The package's value is concentrated in admin UI and its assumptions about that ecosystem — outside it, most of the value evaporates.
• The need is genuinely catalog administration: create products, organize by category/tag, attach media, set price/SKU/stock, publish. Nothing transactional.
• You want to validate a catalog-driven product hypothesis quickly and accept that the schema may become shared state you manage.
• You have, or can assign, one developer who can read the package source and own upgrades. Community support means internal ownership is the real support contract.
• You can pin an exact version (1.0.18, not ^1.0) and accept a half-day-per-upgrade review cycle — necessary because releases ship with auto-generated compare links rather than human-readable changelogs.

Look elsewhere when:

• The architecture is API-first or headless. This is not a standalone domain library; it needs an adapter layer to serve a storefront and adds nothing to a non-Filament stack.
• Pricing rules, tax, promotions, inventory orchestration, or order processing are in scope. The package does not do them, and stretching it there is a rewrite disguised as configuration.
• Multi-tenancy, multi-currency, or multi-store are near-term requirements. Not assumed out of the box; global scopes and migration changes become your problem.
• You need vendor-backed support, an SLA, or a formal semver/deprecation policy. None exists here — 2 stars and 0 dependents mean you are an early adopter, with the bus-factor risk that implies.
• Large catalogs (hundreds of thousands of SKUs) are expected at launch — vendor Filament resources may have eager-loading and indexing gaps that only surface at production volume. Validate with production-shaped data before committing.
• A Filament major-version upgrade is imminent. v3→v4 transitions historically disrupt plugin packages, and your admin upgrade timeline would be partly outside your control.

Adoption guardrails if you proceed: pin the exact version; diff src/ and database/migrations/ on every bump; treat the package tables as an integration boundary; add custom fields via a companion one-to-one table rather than editing vendor migrations; and put a repository/adapter layer in front of the models so downstream consumers never bind directly to a third-party schema.

How to Pitch It (Stakeholders)

To executives — one paragraph:

We can stand up a working product catalog admin — products, categories, media, pricing, SKU, stock — in days instead of weeks by adopting an open-source (MIT), Laravel-native module rather than building it. It is a low-ceremony internal admin surface, not a commerce engine, so it does not commit us on pricing strategy, tax, or order processing. The trade-off is governance: the project is small, community-supported, and does not publish changelogs, so we must own upgrades ourselves. Mitigations are cheap — a pinned version, a thin adapter layer, and a scheduled review step — and they keep exit cost low. Recommendation: adopt as an internal accelerator for catalog administration only, with a spike to validate the schema against our real product model before we commit.

To engineering — the framing that matters:

• Installation is a solved problem (composer require, publish config/migrations, register the Filament plugin, seed permissions). The work is boundary definition, not setup.
• Two decisions must be made before the first migration runs: (1) does this package own the catalog schema, or does it bootstrap an admin surface we progressively extend? (2) do downstream systems read package tables directly, or go through our adapter? Both are cheap now and expensive to reverse.
• The recurring cost is upgrade review, not upgrades. No changelogs means pinning exact versions, diffing migrations/src/ between tags, and an admin smoke test in CI.
• Highest-likelihood risks: silent behaviour change in a patch release, and a blocked Filament major upgrade. Both are inherited from the ecosystem, not caused by us.
• Ramp-up: 1–2 days for a Filament-fluent Laravel developer; about a week for someone new to Filament — the learning cost is Filament, not this package.

What I would ask before signing off:

1. What is our supported Filament/Laravel/PHP/Livewire matrix, and is a Filament v4-compatible release planned and dated?
2. Is the product schema treated as stable public API, or may columns change in minor releases?
3. Who internally owns this package's upgrades, and what is the review cadence?
4. Are variants, multi-store, or multi-currency on our roadmap within two quarters? A "yes" on any of these converts this from adopt to bootstrap-and-extend — a materially different resourcing ask.

Bottom line for the decision log: a reasonable, low-ceremony catalog admin module with a clear stack dependency and a real governance gap around release communication. Adopt with a pinned version, an adapter layer, and a defined upgrade-review routine — not on the expectation of vendor-backed support or headless flexibility.