Tomato Menus Module Laravel Package

Product Decisions This Supports

• Navigation/menu management as a build-vs-buy call. This module covers a recurring, low-differentiation need — hierarchical menus, admin-side menu building, and menu-to-view rendering — inside Laravel/Filament applications. Buying (or adopting) here avoids funding a small internal CRUD-plus-tree workstream that rarely differentiates the product.
• Faster delivery of admin-configured IA. Product and ops teams can reshape navigation (sidebars, headers, footers, per-role menus) without engineering releases. This supports roadmap items where information architecture changes frequently — multi-tenant dashboards, CMS-lite features, role-specific portals.
• Content and localization roadmap. The v1.0.2 release is a translation-only update, which is a meaningful signal: the module is being localized and accepts outside contributions. That raises confidence for products shipping in multiple locales and supports a decision to treat i18n as a community-sustained capability rather than an internal cost center.
• Ecosystem leverage decision. If the product already runs on the TomatoPHP/Filament stack, adopting this module is an incremental dependency, not a new platform bet. If it does not, this module should not be the reason to adopt that stack — that is a platform decision, not a menu decision.
• Risk acceptance for a young package. At v1.0.x with a single recent release in this cycle, treat it as small-surface, early-stage. The right PM posture is "use it where reverse cost is low," and keep a thin abstraction over menu retrieval so a swap remains a contained change.
• Not supported by this release: no new features, no deprecations, no breaking changes, no performance claims. v1.0.2 should not move any roadmap item on its own.

When to Consider This Package

Adopt when most of the following hold:

• Filament/TomatoPHP stack in place. The integration cost is near zero and the module's conventions match the host application. Outside that ecosystem, the fit is unproven.
• Menus are configuration, not a core product surface. Admin-editable navigation with role/tenant scoping is a genuine fit. If navigation is deeply entangled with pricing, permissions, or routing logic that changes per request, write it in-house.
• Multi-language delivery matters. The translation activity in this release is an early but real indicator. If you need guaranteed, contract-level locale coverage (regulated or high-stakes UX), verify the actual translation completeness yourself rather than assuming it from a PR title.
• You can absorb early-stage churn. Pin the version, read the changelog on every bump, and wrap the public API behind a small internal service/repository so a future replacement is a one-file change.
• You need speed over long-term certainty. A working menu admin in days versus weeks is a defensible trade at v1.0.x for internal tools, MVPs, and back-office surfaces.

Look elsewhere when:

• The product spans multiple frameworks or a non-Laravel backend — the coupling cost outweighs the benefit.
• Menu behavior is a differentiator — conditional/A-B-tested/dynamic navigation belongs in your codebase, where you control the release cadence.
• You require SLA-backed support, security review artifacts, or a maintained LTS. A single-maintainer module with translation-only patch releases will not satisfy procurement or regulated-environment review.
• You cannot tolerate a dependency on a young package. No stable-major track record yet; treat 1.x here as "promising," not "proven."
• Accessibility or SEO-sensitive navigation semantics are non-negotiable and untested by the module — validate rendering output before committing.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost adoption of an existing Laravel/Filament component that lets non-engineers manage site navigation. It removes a recurring internal build task and accelerates delivery of admin-configurable menus across locales. The latest release (v1.0.2) is a translation update only — no functional or breaking changes — so the risk profile is unchanged and low. Recommended as a contained, reversible bet on back-office surfaces, not on customer-facing differentiators.

For engineering: Add the module behind a thin internal interface so menu reads/writes do not scatter through the codebase. Pin the minor version, require changelog review before bumps, and add a smoke test that asserts rendered menu output structure. This release touches translations and adds a first-time contributor (@abdelmjid-saber) — a positive community signal, but also a reminder that the project depends on a narrow contributor base; keep our abstraction layer intact so replacement stays a contained effort. Confirm locale coverage empirically rather than inferring it from the PR.

Recommendation: Adopt for internal/admin navigation on the Filament stack, at a bounded scope, with version pinning and an abstraction seam. Do not adopt as a platform decision, and do not let this release be cited as evidence of feature maturity — it is maintenance. Revisit the assessment when a release introduces functional changes, a stable-major version, or a broader contributor base.