Front Bundle Laravel Package

Product Decisions This Supports

• Storefront strategy: hosted vs. self-built front end. This bundle is effectively a reference front-office implementation for the Wizaplace marketplace platform (Symfony-based, despite the Laravel framing in the request). Its main product value is as a proof point that a decoupled/custom storefront against a marketplace API is feasible — not as a dependency you adopt wholesale.
• Build vs. buy on the commerce front-end layer. If the roadmap item is "custom storefront experience" (merchandising control, brand differentiation, B2B-specific flows), this package lets you estimate the surface area of that build: catalog, search, cart, checkout, account. Use it to size the effort, not to shortcut it.
• Vendor lock-in / exit planning. For teams already on Wizaplace, evaluating this bundle is a concrete way to assess how portable the front end is if you ever migrate off the platform. Conversely, adopting it deepens coupling to a vendor API that is not publicly documented as stable.
• Tech radar / dependency due diligence. With 2 stars, 0 dependents, and no release since January 2022, this scores as unmaintained and unproven. That is itself a decision input: it should be classified as "assess/avoid" rather than "adopt/trial," and it should not enter a security-reviewed dependency baseline.
• Roadmap sequencing for platform teams. If a migration or replatform is on the 2–4 quarter horizon, this package is a research artifact for a discovery spike, not a delivery dependency. It does not justify a roadmap line item on its own.

When to Consider This Package

Consider it only when all of the following hold:

• You are an existing Wizaplace customer with API access and a genuine need to replace or extend their hosted front office.
• You are comfortable forking and owning the code: expect to pin PHP/Symfony versions, patch security issues yourself, and absorb breaking changes in the upstream API with no vendor support path.
• You want a pattern/reference — routing, API client wiring, storefront composition — rather than a maintained library with an upgrade path.
• You have budgeted a discovery spike (1–2 weeks) to confirm the code still runs on your current PHP/Symfony baseline before any commitment.

Look elsewhere when:

• You are not on Wizaplace. The bundle is vendor-specific and offers near-zero transferable value.
• You need an SLA, security patching, or community support — none exist here (0 dependents, last release 2022-01-19).
• You are Laravel-first. This is a Symfony bundle; adopting it means introducing a second framework paradigm into the stack. If Laravel is a constraint, evaluate headless commerce APIs with a Next.js/Nuxt front end, or Laravel commerce packages, instead.
• You need a modern headless storefront — a greenfield build on a documented commerce API (or Sylius if you want a PHP-native, actively maintained option) will be cheaper over a 2–3 year horizon than reviving an abandoned bundle.
• Compliance or security review is a gate. An unmaintained dependency with no CVE response process will fail most reviews on its own.

How to Pitch It (Stakeholders)

For executives: This is a small, vendor-specific Symfony bundle for building a marketplace storefront on Wizaplace. It is not a strategic dependency and not a buy signal. Last release was January 2022, it has effectively no community (2 GitHub stars, no downstream dependents), and there is no support or security-patching commitment. We should treat it as reference material for a discovery exercise, not as a platform component. Recommendation: do not adopt; if we are a Wizaplace customer and custom storefront is on the roadmap, fund a short evaluation spike with the explicit assumption that we fork and own the code — and compare that total cost of ownership against a headless build on a documented commerce API before committing.

For engineering: Expect Symfony, not Laravel. Assume you own the code from day one: dependency pinning, CVE response, and API drift are our problem. The upside is a worked example of the storefront integration surface (catalog, search, cart, checkout) that shortens estimation for a custom front-end effort. The downside is that anything built on it inherits an unmaintained foundation — so scope the spike to learning the integration contract, and decide on a maintained runtime before writing production code.