Product Laravel Package

Product Decisions This Supports

• Catalog and product domain modeling as reference, not runtime dependency. Elcodi's Product component is a Symfony-based e-commerce domain model (product, variant, SKU, taxonomy, pricing concerns). For a Laravel/PHP team, its highest-value use is as a pattern library when deciding how to shape our own catalog schema — variants, product relationships, category hierarchies — before we commit to a build.
• Build-vs-buy input for the catalog core. It represents the "roll our own product domain" option in a buy-vs-build evaluation. Comparing it against modern alternatives (Spatie/Verbb-style catalog packages, Shopify/Saleor APIs, or a bespoke Laravel domain layer) forces the team to articulate what we actually need: multi-variant SKUs, localization, attributes, media, pricing rules.
• Roadmap scoping for MVP catalog features. The component's decomposition (product vs. variant vs. classification concerns) is a useful checklist for decomposing our own MVP — helping separate "must-have product model" from "later-phase merchandising."
• Architecture decision record (ADR) fuel. A concrete, citable example of a decoupled PHP e-commerce domain component that a PM can point engineering toward during design reviews, rather than an item on the dependency bill of materials.

When to Consider This Package

• Only as a reading/reference source. Consider it when your team is designing a product/catalog domain and wants a worked example of Symfony-and-Doctrine-based e-commerce modeling under MIT. Clone it, read it, cite it — do not depend on it.
• When Symfony is already your stack and you are evaluating Elcodi as a whole. Even then, evaluate the umbrella elcodi/elcodi project, not this read-only subtree split — this repo explicitly refuses pull requests.
• Look elsewhere if any of the following are true (they likely are): you are on Laravel (this is Symfony-coupled and will fight your framework), you need maintained code (last release 2015-07-14), you need community support or a security response path (3 stars, 0 dependents, no activity), you need PHP 8+ compatibility guarantees, or you require vendor accountability. For a production catalog, prefer a maintained package or a bespoke Laravel domain model.
• Do not consider it for any decision that creates a runtime, compliance, or upgrade-path dependency. The read-only notice, staleness, and near-zero adoption make it a support liability, not an asset.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed e-commerce product-modeling component from the Elcodi project. It is not a candidate for production adoption — it was last released in 2015, is published read-only with no pull-request intake, and has essentially no adoption (3 stars, 0 dependents). The recommendation is therefore narrow: use it as a free design reference to accelerate our own catalog model, and keep it off the dependency list entirely. Net cost: a few hours of engineering reading. Net benefit: faster, better-informed build-vs-buy decisions on our product catalog without licensing spend.

To engineering: Treat elcodi/product as documentation. It offers a decoupled Symfony/Doctrine view of product, variant, and classification modeling that is useful for shaping our Laravel domain layer, but it is framework-mismatched, unmaintained since 2015, and has no community. Any adoption would be a fork-and-own commitment. Recommended action: a short spike to extract patterns, record an ADR, and select a maintained or in-house path for the actual implementation. If Symfony and Elcodi ever become strategically relevant, reassess at the umbrella project level — not this subtree split.