Master Product Laravel Package

Product Decisions This Supports

• Catalog model: simple products vs. variant products. The core decision this module informs is whether your catalog needs a parent/child (master → variant) structure at all. If you sell one SKU per listing, you don't. If a single merchandising unit ("Tee — Crew Neck") carries size/color combinations that are individually priced, stocked, imaged, and fulfilled, the master-product pattern is the data model that makes that possible without duplicating product content on every SKU.
• Where content lives vs. where commerce lives. Master products typically hold shared marketing content (title, description, brand, category, properties) while variants hold the buyable attributes (SKU, price, stock, barcode, dimensions). That's a content-ops decision as much as a technical one: it dictates who edits what in the admin, and how much duplication your merchandising team tolerates.
• Roadmap sequencing for variant-dependent features. Variant-level pricing, per-variant inventory, variant image switching on the PDP, variant-aware tax/shipping rules, and feed/export mapping all sit downstream of this model. Choosing it early avoids a painful catalog migration later; choosing it late means those features are blocked.
• Build vs. buy on catalog modeling. Adopting it is a vote for Vanilo's opinionated product schema rather than hand-rolling parent/child relations on top of a plain products table. That's a maintenance-burden trade: less bespoke code, more coupling to the framework's release cadence.
• Scope check on "configurable product" ambitions. It supports a bounded variant model, not a full CPQ/BOM engine. If the roadmap includes kits, bundles, or option matrices with rules, treat this as a partial answer and plan the gap explicitly.

When to Consider This Package

Consider it when: you're already committed to Vanilo (or actively evaluating it against Lunar, Bagisto, Aimeos, or a custom Laravel build); your catalog genuinely has multi-axis variants that need independent price and stock; and you want the parent/child relation to come from the framework rather than your own migrations, so that future Vanilo modules and admin tooling can assume it.

Look elsewhere when: you're not on Vanilo — this module is a component, not a standalone product, and has no meaningful independent adoption to de-risk it (2 stars, 0 dependents; it ships inside the Vanilo framework metapackage, so those numbers understate usage inside the ecosystem but tell you nothing about standalone support). Also look elsewhere if you need marketplace multi-vendor catalogs, bundle/BOM or configurable-with-rules products, or a mature admin UI and API out of the box — this module provides the schema and models, not the operational surface around them.

Diligence before adopting: pin to the Vanilo core version you're on and verify the module's status against that release — the master-product concept has moved around across Vanilo majors, and an archived or merged module changes your upgrade path. Confirm per-variant behavior for search indexing, tax, shipping, and any ERP/PIM sync you depend on; those integrations are yours to build, and they're where the real cost sits.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed catalog module inside the Vanilo framework that lets one product listing carry multiple buyable variants without duplicating content per SKU. It's cheap to adopt and removes a class of bespoke schema work — but it's not a differentiator, and it doesn't come with an admin experience or integrations. Frame the decision as "which e-commerce foundation are we standardizing on," not "should we add this package."

To engineering: Treat it as an internal building block of Vanilo, not a third-party dependency. Low external usage means the support path is the framework's own release notes, so budget for version pinning, a catalog migration plan, and the integration work it doesn't cover — variant-aware search, tax/shipping, feeds, and admin UX. The upside is a conventional Eloquent parent/child model you don't have to design, defend, or migrate into later.