Tomato Emenu Laravel Package

Product Decisions This Supports

• Build vs. buy for menu/content management UI. tomato-emenu is a menu-management module in the TomatoPHP admin ecosystem (Laravel + Filament-style admin panels). If a roadmap item is "let ops edit menus/navigation/digital menu content without engineering," this is a candidate to evaluate instead of building CRUD from scratch.
• Admin-surface scope decisions. Choosing a pre-built TomatoPHP plugin implies adopting the parent admin panel's conventions (auth, RBAC, resource patterns). That's a platform decision as much as a feature decision — it should be weighed against your existing admin stack, not decided per-feature.
• Speed-to-demo / internal tooling. At v0.0.1 this is realistically only useful for prototypes, spikes, and internal tooling where a throwaway integration cost is acceptable.
• Roadmap timing signal, not a commitment. Evidence quality here is very low: the only artifact is a v0.0.1 tag with no changelog body, no docs summary, and no prior assessment. Treat this as a watch-list entry, not an input to a build/buy decision yet.

When to Consider This Package

Consider it when all of the following hold:

• You are already standardized on Laravel and comfortable with the TomatoPHP admin panel ecosystem (this package's value is largely inherited from that parent).
• The need is menu/content structure management — hierarchical items, ordering, visibility — and not a bespoke domain model.
• You can absorb the risk of a 0.0.x dependency: expect breaking changes, thin documentation, and limited community answers.
• The feature is non-critical or you can wrap it behind an internal abstraction so it can be swapped out.

Look elsewhere when:

• You need production stability. 0.0.1 with an empty changelog is pre-alpha semantics; there is no release history to infer a stability or deprecation policy from.
• You are not on TomatoPHP. Pulling in a plugin plus its parent panel to manage menus is almost certainly more coupling than the problem warrants.
• You need guarantees. No evidence yet of maintainer responsiveness, test coverage, security posture, or upgrade path. Do not adopt for anything touching customer-facing menus or payments.
• You'd be the first serious adopter. With no adoption signals, you would be doing the maintainer's integration testing.

Recommended posture: defer. Re-evaluate at 0.1.x or after meaningful release notes, docs, and at least some external usage appear.

How to Pitch It (Stakeholders)

Executives (one paragraph): A new Laravel menu-management module, tomato-emenu, shipped its first version (v0.0.1) with no substantive release notes. It is a bolt-on to an existing open-source admin panel, so its value is contingent on us already using that panel — which we don't. There is no cost to waiting and real cost to adopting early, so my recommendation is no action: we track it and revisit once it shows a version history, documentation, and outside usage. No budget or roadmap change is proposed.

Engineering (summary):

• What it is: an early-stage menu management plugin in the TomatoPHP ecosystem; Laravel-based.
• Maturity: 0.0.1, empty changelog, no prior evaluation baseline. Assume unstable API and incomplete docs.
• Cost to try: low in isolation, but only if we're already on a TomatoPHP admin panel; otherwise the integration cost is the parent framework, not the plugin.
• Ask: one engineer-hour to spike it only if a menu-editing need lands on the roadmap. Otherwise, no work — add to the dependency watch list and re-check on the next meaningful release.

Decision requested: none today. Flagged as watch, not adopt.