Custom Fields Laravel Package

Product Decisions This Supports

• Customer-specific extensibility without forks. A custom-fields layer lets accounts add attributes to core records (leads, products, orders, contacts) through configuration rather than a bespoke branch per customer. That converts a recurring services cost into a one-time platform investment — the core product decision is whether extensibility is a platform capability or a professional-services line item.
• Enterprise/vertical deal unblocking. Most mid-market ERP/CRM deals stall on "we need three fields on the customer record that you don't have." A generic custom-field mechanism is the cheapest credible answer, and it directly affects win rate in verticals where your default schema is 80% right.
• Roadmap sequencing: schema flexibility vs. depth. Choosing this package is a bet that breadth of configurability matters more this quarter than deepening native modules. It buys time before you commit to per-vertical data models, and it creates an exit ramp if a vertical later graduates to first-class entities.
• Build vs. buy (vs. vendor-in). At this scope the real comparison isn't "build vs. buy," it's "build vs. adopt-and-own." A small MIT package is effectively source you inherit; the decision hinges on whether the storage and validation model matches your multi-tenant and reporting requirements, not on license cost.
• Onboarding and admin-UX decisions. Custom fields imply an admin surface (field builder, type picker, required/validation rules, per-tenant scoping). Adopting the package settles the data model question but forces product decisions on who configures fields (internal ops vs. customer admin), what types are exposed, and whether custom fields appear in list views, filters, exports, and the API.
• Reporting and integration scope. Once customers can add fields, they expect those fields in exports, filters, webhooks, and the API. Plan for that surface area explicitly — it's the hidden cost that determines whether the feature delights or generates tickets.

When to Consider This Package

Adopt when most of these hold:

• You are already on Laravel, and ideally within the AureusERP/Filament ecosystem — the package's value is highest when its conventions match your admin stack, and lowest when you'd be bridging two idioms.
• You need tenant- or account-level field extensibility fast, with a small team and a near-term customer commitment that depends on it.
• Your custom-field read patterns are low-to-moderate volume (form display, detail pages, exports). Verify the storage strategy — JSON column vs. EAV — and confirm you can index and filter the fields that matter before promising "filter by custom field" to a customer.
• You are willing to own the code: read it, fork it, pin it, and treat upstream as a convenience rather than a dependency. Ten stars and a single maintainer mean bus factor, not a support contract.
• You can accept basic type coverage (text, number, date, select, boolean) and defer relational or computed fields.

Look elsewhere when:

• Custom fields would become query-critical — heavy filtering, sorting, aggregation, or reporting across thousands of tenant-defined attributes. That's a job for a purpose-built EAV/JSON query layer or a document store, not a thin admin-oriented package.
• You need compliance-grade auditability (field-level history, retention, e-discovery) or regulated data handling with vendor accountability.
• You require an SLA, security review artifacts, or a maintained release cadence — a 10-star package cannot supply them, and a future release date is a weak proxy for a support commitment.
• You are not on Laravel/Filament, or your admin layer is bespoke and would need significant glue.
• The package's assumptions about multi-tenancy and migrations conflict with yours. Confirm how it creates/alters storage and whether changes are reversible and safe under load; a custom-field feature that requires a schema migration per field is a different (worse) product than one that doesn't.
• The data must be portable and stable across vendors — you'd rather define your own schema than inherit someone else's.

Minimum evaluation gate before committing: a one-week spike that adds fields to two real entities, exercises validation and required-field behavior, verifies filtering/export performance at realistic tenant data volume, and includes a code read for migration safety, test coverage, and dependency footprint.

How to Pitch It (Stakeholders)

For executives — one paragraph. This is a small, permissively licensed (MIT) component that lets customers add their own fields to our records without engineering work per account. It is the cheapest way to stop losing mid-market and vertical deals on "your schema doesn't fit us," and it shifts configuration effort from our services team to the customer's admin. The cost is not license fees — it's the engineering time to integrate, plus the ongoing ownership of a lightly adopted open-source component that we should assume we maintain ourselves. Recommendation: fund a one-week spike against a live customer requirement, then decide; treat it as a time-to-market lever, not a long-term platform bet.

For engineering — the short version. Laravel package, MIT, small surface area, single maintainer, ~10 stars. Assume no upstream support: fork, pin the version, and review the storage model (JSON vs. EAV) and migration approach before it touches production data. We own performance under filtering, validation semantics, tenant scoping, and the propagation of custom fields into exports, APIs, and filters. Integration is days, not weeks — but budget for the read-path work, because that's where the real effort sits.