Laravel Custom Fields Laravel Package

Product Decisions This Supports

• Build vs buy for dynamic metadata: This package gives you attachable, per-model custom field definitions (user-defined fields on customers, orders, projects, etc.) without building your own schema, validation, and type-management layer. The decision it supports is whether to buy (adopt this) or build a bespoke EAV-style attribute system.
• Feature scoping for user-defined forms: Adding a renderer column in v3.3.1 signals that fields can carry presentation metadata alongside their type. That lets PMs plan UI-facing features — admin-configured forms, per-field display components, tenant-specific rendering — without a schema change per feature.
• Roadmap for configurability: If your roadmap includes "let customers define their own fields" or "per-tenant customization," this package is the enabling primitive. The renderer hint moves it closer to being a full form-builder backend, not just a data store.
• Prioritization of admin tooling: Because field definitions live in the database (now including renderer info), you can ship admin screens for managing custom fields without corresponding engineering work for each new field type — good leverage for small teams.
• Use cases: CRM extensions, configurable onboarding forms, product catalogs with variable attributes, per-client data capture in SaaS, internal tooling where ops teams define fields.

When to Consider This Package

Consider adopting when:

• You need polymorphic custom fields attached to multiple Eloquent models.
• Non-engineers (ops/admin) must define or alter field sets at runtime.
• You want a small, focused dependency rather than a full CMS/form-builder.
• Your team is standard Laravel/PHP and comfortable with a community package (asseco-voice) rather than a first-party one.

Look elsewhere when:

• You need heavy type-specific behavior (complex validation, relationships, computed fields) — the renderer column is a hint, not a full rendering framework.
• You require a vendor with long-term enterprise support/SLA.
• Your custom-field needs are static and known at build time — plain migrations are simpler and cheaper.
• You need versioned/schema-migrated field definitions across tenants at scale (EAV performance concerns).

Note on v3.3.1: The change is additive (new renderer column). It should be non-breaking for existing installs, but confirm a migration is included and plan the deploy window accordingly. Verify defaults for existing rows.

How to Pitch It (Stakeholders)

For executives: This package lets us offer configurable, customer-defined data fields without building a custom system from scratch — reducing time-to-market for customization features and lowering maintenance cost. The latest release (v3.3.1) is a small, additive enhancement adding display/renderer metadata to fields, moving us toward self-serve form configuration.

For engineering: Mature-pattern Laravel package for polymorphic custom fields backed by a DB table. v3.3.1 adds a renderer column — additive, low risk; requires a migration. Adopting means one more dependency to track, but it replaces a substantial in-house build. Recommend a spike to validate migration path and confirm renderer semantics before committing to roadmap items that depend on it.