Menu Builder Client Bundle Laravel Package

Product Decisions This Supports

• Buy-vs-build for menu/navigation management. This package is the consumption half of a buy decision: it is a thin client for the hosted Forci Menu Builder service, which handles the authoring UI, storage, ordering, and publishing. The decision it actually informs is whether to purchase a menu-management backend so non-engineers can own navigation, or build menu CRUD into our own admin. The bundle only proves the "fetch and render" leg is cheap; it says nothing about the authoring side, so evaluate the service separately before treating this as a shortcut.
• Headless / multi-channel content roadmap. If we are moving toward one source of truth for navigation across web, app, and other surfaces, a dedicated menu service plus a client SDK is a credible pattern. This package lets us prototype that architecture in days rather than quarters — useful for de-risking the roadmap before committing budget.
• Editorial ownership and localization. Menu services exist largely so marketing and localization teams can ship nav changes without engineering tickets. Adopting one changes the roadmap conversation from "engineering ships nav" to "marketing edits nav in a UI, per locale." That operational win is the real product value to scope, and it is what justifies a vendor spend.
• Time-to-market for CMS-adjacent and campaign work. For a campaign site, microsite, or client deliverable with low-churn navigation, wiring a hosted menu API beats standing up our own tree storage, ordering, and publishing model.
• Explicitly not a decision this supports: "we have a menu component." It is a service client, not a rendering library. If the need is a maintained tree/menu component, this is the wrong tool and the decision should be scoped elsewhere.

When to Consider This Package

Consider it only when all of the following hold:

• We have committed (or are concurrently committing) to the Forci Menu Builder service as a vendor. The bundle is inert without that backend — it is a client, not a menu system. The vendor evaluation (pricing, SLA, authoring UX, API contract, export path) is the real gate, and it must happen first.
• Licensing is resolved. NOASSERTION means we cannot confirm redistribution or commercial-use terms. Until that is cleared in writing with the maintainer, this is a hard blocker for anything shipping to customers.
• The consuming app has a real integration plan. Despite the "Laravel/PHP package" catalog listing, the artifact is a Symfony bundle: no service provider, no config publishing, no Laravel container bindings. In a Laravel codebase, budget engineering time for an adapter shim and treat that as a hidden cost. Verify PHP/PSR-18 compatibility and whether it requires symfony/framework-bundle — that requirement is the tell for "reimplement instead."
• Navigation is not on the critical path unprotected. Menus render on every page, so any dependency here needs a cache plus graceful-degradation story. Confirm the client's failure behavior before it touches the primary layout.
• The feature is low-churn and non-differentiating. If navigation is static or simple, a config file or DB table is less risk for similar effort.

Look elsewhere when:

• Maturity signals matter. Zero stars, zero dependents, and a low package-health score describe a package with effectively no community scrutiny. Assume no security review, no timely patches, and possible abandonment — we become the maintainer on day one.
• We need vendor neutrality. A client for a proprietary service is a one-way door: migrating off means rewriting the integration and re-authoring all menu content in a new system.
• A generic option suffices. Established menu/tree components and mainstream CMSes solve this without tying us to a hosted API.
• Legal can't clear the license quickly. The critical path is legal, not engineering; if it stalls, the roadmap item stalls.

Recommendation: do not adopt on the strength of this repository alone. If the Forci service is strategically interesting, evaluate the service, and treat the bundle as a replaceable ~200-line HTTP client we could write ourselves in a day behind an interface we control — which also removes the license and maintenance concerns.

How to Pitch It (Stakeholders)

To executives: There is a small open-source connector for a hosted menu-management service that would let marketing and localization own site navigation without engineering tickets, and publish one menu to web and app from a single source of truth. The strategic value sits in the service, not this connector. The connector itself is currently unlicensed, unmaintained, and built for Symfony rather than our Laravel stack, so the honest ask is a short, timeboxed spike against the vendor's service — with a clear view of the exit cost (we'd rewrite the integration and re-author all menu content if we ever leave). Frame it as buying operational speed for marketing, not buying a library.

To engineering: It's a Symfony bundle wrapping an HTTP API for menu retrieval — no Laravel integration despite the catalog listing, license unspecified, zero dependents, so nobody has validated it in production. Proposal: a two-day source audit to confirm the license and classify each class as portable, replaceable, or blocking. If the client core is a thin PSR-18 HTTP layer, extract it behind a MenuRepository-style interface and bind it in a Laravel ServiceProvider; if it needs a Symfony kernel, write our own client — roughly a day's work. Either way we gate it behind a feature flag with cache-backed fallback, hard timeouts, Http::retry(), and alerts on auth failures and empty-menu anomalies, so a vendor outage never blanks our navigation. Budget the real cost as ownership plus the caching/fallback/contract-test machinery, not the package itself.