Product Decisions This Supports
- Build vs. buy on extensibility infrastructure. Dynamic custom fields are a recurring "platform tax" — every B2B product eventually needs per-customer, per-record fields that don't justify a schema migration each time. This package is a candidate to buy (adopt) rather than build a bespoke EAV/JSON-column subsystem from scratch.
- Roadmap sequencing for enterprise/custom-tier features. If sales is blocking renewals on "we need our own fields on records," adopting a package is a days-not-quarters enabler, and it can be slotted ahead of larger platform work.
- Configuration-over-fork strategy. Supports a roadmap direction where customer-specific variance lives in configuration (field definitions) rather than in divergent code branches or per-tenant migrations.
- Admin/ops surface decisions. Because it ships Filament integration, it directly informs whether your internal admin can be self-serve for schema changes — a support-cost and CS-tooling decision, not just an engineering one.
- Schema-evolution cost modeling. Use it as the reference point when estimating the ongoing cost of hand-rolled custom-field implementations (migration churn, form-building, validation, display logic).
- Not a substitute for core domain modeling. This is for extensible attributes, not for relationships, workflows, or anything with query-heavy semantics. Don't let it creep into the core data model.
When to Consider This Package
Consider it when all of the following hold:
- You are on Laravel and, critically, on Filament for admin/back-office — the Filament integration is the package's main differentiator; without it you're paying for surface area you won't use.
- You need user/tenant-defined fields on a bounded set of Eloquent models (CRM records, assets, tickets, catalog items) where the field set varies by customer or plan tier.
- The custom fields are primarily captured and displayed, not used as the backbone of complex querying, sorting, or reporting joins at high volume.
- You have engineering capacity to own a fork. With zero stars and zero dependents, treat this as source code you are adopting, not a dependency you are consuming.
- Your timeline rewards speed over ecosystem maturity, and you can absorb the review cost before it touches production data.
Look elsewhere (or build) when:
- No Filament. The value proposition largely collapses; you're left with a small, unproven Eloquent helper.
- Query performance on custom fields matters. Filtering/sorting/aggregating on dynamic attributes needs an indexing and projection strategy this package won't provide — plan for a materialized-view or search-index layer alongside it, or pick a different approach entirely.
- You need ecosystem assurance. Zero dependents means no community validation, no third-party battle-testing, no guarantee of maintenance. If your org requires an actively maintained dependency with a support path, this fails procurement.
- Data-integrity guarantees are non-negotiable. Dynamic fields typically trade relational constraints for flexibility; if compliance or financial correctness requires enforced types and foreign keys, model explicitly.
- You can't vendor it. If policy forbids forking/pinning third-party code, adopting an unmaintained-looking package is a non-starter.
How to Pitch It (Stakeholders)
For executives: We have a recurring, revenue-adjacent request — customers want to define their own fields on records without waiting on our release cycle. Today that's either a bespoke build or a per-customer schema change, both of which convert one deal into permanent maintenance cost. This package is a shortcut: it gives us configurable custom fields plus the admin UI on top, in a Laravel/Filament stack we already run. It's a time-to-market play, not a platform bet — small surface area, contained to attribute storage, reversible. The honest caveat: it is essentially unproven (no adoption, no community), so I'd fund it as a spike with a fork-and-own assumption, not as a strategic dependency. Expected outcome: validate in one sprint against our real tenant model, then decide adopt-vs-build with actual evidence rather than estimates.
For engineering: The package provides dynamic custom-field definitions attached to Eloquent models, with Filament form/table integration — so the win is skipping the definition CRUD, value persistence plumbing, and admin rendering, and going straight to your domain specifics. Treat the codebase as a starting point you own: read every line, pin or vendor it, and add tests around field-definition lifecycle, validation, and value retrieval before it lands anywhere near customer data. The design questions to answer in the spike are the ones that decide the whole thing — how values are stored (rows vs. JSON column), how you index and filter on them, and how deletion/migration of a field is handled without orphaning data. If those three answers are acceptable, this saves real weeks; if not, we've spent a sprint producing a precise spec for the in-house version, which is still a good trade.