Product Decisions This Supports
- Schema-evolution vs. schema-lock: This package sits in the "flexible per-record attributes" category — storing model properties as a JSON/property bag rather than columns. That directly informs a recurring PM decision: do we ship a rigid migration for each new field, or do we adopt a property store so customer-facing fields (custom fields, per-tenant metadata, CMS-style content blocks) can be added without schema churn?
- Build vs. buy vs. copy: The real decision this surfaces is not "adopt or not" but "which property mechanism." It should be benchmarked against
spatie/laravel-schemaless-attributes (query scopes on JSON), spatie/laravel-data (typed DTOs), spatie/laravel-settings (app-level config), plank/laravel-metable (EAV-style metadata), or a hand-rolled JSON cast + accessor. Given zero dependents, treat this one as reference implementation / candidate to vendor, not as a platform dependency.
- Feature scoping: It supports the decision to defer a full custom-fields subsystem (admin UI, validation, indexing, migration tooling) in favor of a lighter property store — a meaningful reduction in scope for an MVP or a tier-2 feature.
- Roadmap risk framing: Choosing a property bag is a one-way-ish door for query and reporting. Flag early whether product will ever need "filter/sort/aggregate by custom field," because that requirement converts a cheap JSON property store into an indexing/EAV project.
- Not supported: Anything requiring audit trails on property changes, per-tenant isolation guarantees, or DB-level constraints. Those are product requirements, not package features, and should be decided explicitly.
When to Consider This Package
Consider it only when all of the following hold:
- You want a minimal, MIT-licensed property bag on Eloquent models and are comfortable vendoring or forking the code into your app rather than depending on Packagist.
- Your use case is low-volume, read-mostly metadata (displayed properties, small config blobs, editorial extras) — not high-cardinality filtering.
- You are on a supported Laravel/PHP version and can verify compatibility in a day-long spike (test suite present, framework constraints declared).
- You have an internal owner who will accept maintenance if upstream goes quiet.
Look elsewhere — or build 50 lines yourself — when:
- Maturity signals matter. 0 stars, 0 dependents, an unverifiable maintenance cadence, and a low composite score mean no community safety net. A single
composer require here is an unpriced maintenance liability.
- You need querying, sorting, or aggregation on properties at scale; use a schemaless-attributes package with query scopes, or a proper indexed design.
- You need typed contracts (DTOs, validation, serialization) —
spatie/laravel-data is the stronger fit.
- You need auditing, versioning, or multi-tenant isolation on property values.
- You need app- or team-level settings, which is a different problem domain entirely (
spatie/laravel-settings).
How to Pitch It (Stakeholders)
To executives (one line): This is a small, MIT-licensed building block for letting records carry flexible, admin-definable attributes without database migrations — useful for shipping customizable features faster, but with essentially no community adoption, so we would own the code, not rent it.
To engineering: Propose a timeboxed (1–2 day) evaluation spike, not an adoption. Success criteria: tests pass on our Laravel/PHP versions, the API surface is small enough to fork, and it covers our accessor/casting needs. If it fails any of those, the fallback is a short internal trait over a JSON column — which is likely comparable effort and carries no third-party risk. Do not add it as a dependency in a revenue-critical path.
Recommendation: Do not adopt as a dependency today. Log it as a candidate pattern for the "flexible attributes" decision, resolve that decision on product grounds (will we ever query/filter on these fields?), and only then pick between a vendored copy, a maintained alternative, or an in-house implementation.