Properties Laravel Package

Product Decisions This Supports

• Catalog data modeling (build vs. buy): Decides whether product attributes (color, size, material, voltage, compatibility) are stored as structured, filterable properties versus unstructured text blobs. Structured properties are the prerequisite for faceted search, comparison tables, and merchandising rules—so this package is really a decision about whether the catalog is queryable or just readable.
• Search & discovery roadmap: Faceted filtering and product comparison are among the highest-ROI features in a commerce roadmap. This module supplies the attribute layer those features sit on, so it directly gates whether "filter by X" is a Q1 or Q4 deliverable.
• Admin/merchandising ownership: Property definitions are typically editable by non-engineers. Choosing a package that exposes properties as first-class, admin-manageable entities shifts ongoing catalog taxonomy work from engineering tickets to operations—a recurring cost decision, not a one-time one.
• Ecosystem and lock-in strategy: This is a component of Vanilo, not a general-purpose package. Adopting it is a statement that the product is (or will be) a Vanilo application. That's a platform commitment that belongs in architecture review, not a pull request.
• Roadmap risk register: With 11 stars and zero known dependents, this is effectively single-maintainer, in-house-adjacent software. The PM decision is less "is this good?" and more "what is our exposure if it goes quiet, and do we have the appetite to own it?"
• Variant-level vs. product-level attributes: Whether properties attach at SPU or SKU level determines the data model for size/color matrices, B2B tiered pricing, and configurable products. Settling this early avoids a painful migration later.

When to Consider This Package

Consider it when:

• You are already building on Vanilo or Laravel + a Vanilo-based stack. This is the dominant criterion; standalone adoption of a nested module is rarely rational.
• Your catalog needs moderate, operator-managed attribute faceting—dozens to low hundreds of property types, not millions of EAV rows.
• You want Eloquent-native, migration-friendly property storage that your existing Laravel team can read and extend without learning a new domain model.
• You need properties to be admin-configurable rather than hardcoded columns, and you'd otherwise build that CRUD layer yourself.
• Your team is comfortable owning a small dependency—pinning versions, reading source, contributing fixes.

Look elsewhere when:

• You are not on Vanilo. The integration cost savings evaporate, and you inherit a dependency without its surrounding context.
• You need PIM-grade capability—localized attribute values, inheritance across channel/catalog hierarchies, governance workflows, digital asset linkage. Evaluate Akeneo, Pimcore, or a dedicated PIM instead.
• You need high-throughput faceted search. The property store is not a search index; plan on Meilisearch, OpenSearch, or Algolia regardless of where attributes live, and treat this package as source-of-truth only.
• You require commercial support, SLA, or a security responsiveness commitment. Low adoption is a proxy for low bus factor.
• You need standalone, framework-agnostic attribute handling—spatie/laravel-tags, a hand-rolled EAV schema, or JSON columns with generated indexes may be simpler and better supported.
• Your attribute taxonomy is highly volatile or user-generated, where schema-driven approaches churn and document storage wins.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed building block that lets us store product attributes as structured data instead of free text. That's what makes "filter by size/color/spec" and product comparison possible—features customers expect and that measurably lift conversion. Cost is effectively zero in licensing and modest in integration, provided we're already on the Vanilo stack. The honest caveat: it's a low-adoption, single-maintainer component with no commercial backing. The recommendation is to adopt it only as part of a Vanilo commitment, pin the version, and budget a few days of engineering time to vendor or fork it if upstream stalls. It is not a strategic bet; it is a tactical accelerator with a known, bounded risk.

For engineering: This is the Vanilo properties module—Eloquent models for property types and values, with polymorphic assignment to products and variants. It fits Laravel conventions cleanly: migrations, config publishing, no exotic runtime requirements. If we're on Vanilo, integration is a composer require plus configuration; if we're not, we're paying for a dependency we can't fully use. Two things to validate before committing: (1) the property-to-product relationship granularity, since it constrains our variant matrix design; (2) whether we can comfortably own this code, because eleven stars and zero dependents means we are likely to be the ones fixing edge cases. Recommend a time-boxed spike—half a day to model our real catalog in it—before it enters the architecture.

For product/ops stakeholders: Once wired in, non-technical staff can define new product attributes and assign values without engineering involvement. That shortens the loop between "merchandising wants to filter by X" and "customers can filter by X" from a sprint to an afternoon.