Tomato Category Module Laravel Package

Product Decisions This Supports

• Build vs. buy for taxonomy. Every content, catalog, or marketplace feature eventually needs categories, tags, and types. This package answers the "do we build it ourselves?" question with "not the plumbing, at least" — migrations, models, tree structure, and admin CRUD are pre-built. That converts a recurring 1–2 week build item into a config-and-publish task, and it is the single clearest justification for adoption.
• Roadmap acceleration on admin surfaces. If the product roadmap already commits to Filament/TomatoPHP for back-office screens, the prebuilt CRUD is free scope. The PM decision is not "is this the best taxonomy package" but "does this let us skip a sprint of admin work we'd otherwise fund?"
• Feature scope for categorization UX. Unlimited nesting plus translated labels means "multi-level categories with localization" can be committed to customers without a bespoke estimation exercise. Conversely, it caps ambition: if the roadmap calls for tag-based facets, search-driven filtering, or customer-facing category APIs, those are still net-new work — this package covers the data model and admin, not the experience.
• Prioritization input on the data migration. The technical assessment is explicit that backfill and reconciliation of existing category links is likely the bulk of the effort and is independent of the package version. That is a PM-visible line item that must be scoped and scheduled before any adoption decision is treated as cheap.
• Vendor/ecosystem bet. Adopting this module is a soft commitment to the TomatoPHP suite, which pulls in Filament and a single-vendor OSS cadence. That is a strategic dependency decision, not merely a technical one, and it belongs on a roadmap risk register.
• Portfolio signal — low. Zero stars, zero dependents, a 0.4 score, and an opportunity score of 6.59. The opportunity score says taxonomy is a real recurring need; the adoption signals say this particular implementation is unproven in the wild. Use it as evidence for building an internal taxonomy capability, not as evidence that this package is the market's answer.

When to Consider This Package

Adopt when all of the following hold:

• The application is already Laravel 10/11 on Filament v3, ideally with other TomatoPHP modules in place — the value is mostly the prebuilt admin layer, so paying for a UI you won't use is a bad trade.
• The taxonomy need is genuinely hierarchical (multi-level categories) and multilingual, matching the package's stated strengths rather than exceeding them.
• There is no existing category data of consequence, or the migration path is small enough to be a contained task rather than a project. Greenfield is the sweet spot.
• Taxonomy is not on a revenue-critical path, or the team accepts first-line triage / fork-and-patch as a pre-approved option since there is no SLA.
• One developer can own it, versions are pinned to exact patches, and the team has capacity to re-verify on every Filament major upgrade.

Look elsewhere — or build in-house — when:

• The admin layer is Nova, Backpack, or hand-rolled Blade. You would be buying a UI you discard; evaluate a leaner taxonomy package or a simple internal implementation instead.
• There is an existing categories table or enum-based taxonomy with meaningful history. The polymorphic pivot reconciliation is the expensive half and dwarfs the package's savings.
• The product needs faceted search, tag-driven filtering APIs, or customer-facing category management. Those are out of scope and would need to be funded anyway.
• The organization requires a support SLA, a security review trail, or multiple maintainers — single-vendor, small-team, 0-dependency OSS does not meet that bar.
• A single-vendor ecosystem bet is unacceptable. The exit cost (a bespoke taxonomy) is bounded but real, and it should be a conscious choice.
• Change opacity is disqualifying. An undocumented patch release is tolerable for an internal admin tool and not tolerable for anything customer-facing without a diff review gate.

Also flag the unknown-but-presumed-non-breaking v1.0.1 delta as a gating check: no upgrade should be scheduled on release notes alone.

How to Pitch It (Stakeholders)

For executives (one paragraph): Categorizing content is a requirement we will hit on multiple products, and we currently rebuild it each time. This MIT-licensed module provides the category data model and the admin screens out of the box for our Laravel/Filament stack, so it removes roughly a sprint of repetitive work per project. The trade-offs are honest: it is a small, single-vendor open-source component with no support contract and minimal public adoption, so it suits internal back-office tooling, not revenue-critical customer paths. Expected cost is a sandbox spike plus a diff review — low, and time-boxed. The variable is migrating any existing category data, which we should size before committing. Recommendation: run a short spike and pilot it on one non-critical internal surface, not a broad rollout.

For engineering: Net saving is the Filament CRUD resource plus migrations and a polymorphic categorizable pivot in the conventional Laravel shape — the schema is not novel, the admin screens are the actual value. The constraints you inherit rather than choose are the tree strategy (verify nested-set vs adjacency-list and measure subtree-move cost at 10k+ nodes), the translation approach (likely spatie/laravel-translatable, which shapes the schema and query patterns), and the Filament major-version constraint against the host app. Concrete asks before we commit: (1) inspect the v1.0.0→v1.0.1 diff — release notes are empty, so this is not optional; (2) confirm Laravel 11 / Filament v3 support via composer.json; (3) confirm migrations are additive-only and namespaced; (4) decide cascade behavior on the pivot at the FK level rather than in application code. Pin exact patch versions and plan a rollback-verified migration step separate from any general release. Budget the real effort against backfill and pivot reconciliation, and load-test at production-shaped node counts and entity fan-out — not the package install.

The one-line ask: Approve a two-to-three day spike, gated on the v1.0.1 diff review, before we put this on any roadmap.