Filament Resource Picker Laravel Package

Product Decisions This Supports

• Feature delivery velocity, not new capability. This package shortens "let an admin pick a record from another resource" (assign a customer, link a parent asset, attach a template) from a custom Livewire + modal build to a form-schema call. It's a UX/engineering-velocity lever — measure it in days saved, not revenue unlocked.
• Build vs. buy (really: buy vs. vendor). The surface area is small and the license is MIT, so the honest framing is "copy the code into our repo" rather than "take a dependency." That decision is cheap to make and cheap to reverse.
• Backlog triage. Admin-panel polish items (searchable relationship pickers, bulk attach, filter-then-select) tend to sit at the bottom of a roadmap because they're unglamorous. This collapses them into same-day work, freeing roadmap capacity for customer-facing bets.
• Use-case fit: internal ops panels, multi-tenant back offices, CMS-style admin, and any data-entry flow where a native Select over thousands of records becomes unusable and a paginated, filterable modal table is the right interaction.
• Version-lock planning. Adopting it commits you to tracking Filament major releases. That's a recurring cost line to weigh against the one-time build saving.

When to Consider This Package

Consider it when:

• You're already on Filament and the requirement is genuinely "select one or many records from an existing resource," with search and filtering.
• The surface is internal-facing — the blast radius of a regression is an annoyed ops team, not a customer incident.
• Someone on the team can read the source. It's small; a spike plus a code read is a half-day, not a sprint.
• The alternative is one to two weeks of hand-rolled Livewire modal work, and you'd rather spend that on product.

Look elsewhere when:

• The surface is customer-facing or revenue-critical. Two stars, zero dependents, and a single maintainer is not ecosystem validation — it's an absence of it.
• You need SLAs, a security review program, or maintenance guarantees. MIT covers the license question; it does not cover the "who fixes this in eighteen months" question.
• Filament's native Select::make()->relationship()->searchable() or a relation manager already satisfies the requirement. For small relation sets, it usually does — check before adding a dependency.
• You can't absorb Filament upgrade churn. Every major Filament release is a potential break, and you will own the patch.

Mitigations if you proceed: vendor the code rather than requiring it in production, wrap it behind your own field factory or abstraction so it's swappable, add test coverage around the picker behavior, and pin a commit. Treat it as a head start, not a foundation.

How to Pitch It (Stakeholders)

To executives: "A small, free, MIT-licensed building block for our Filament admin panel. It removes repetitive record-selection UI work from our internal tooling backlog at near-zero cost. It is deliberately not a strategic dependency — we'd vendor the code into our own repo, so we're never blocked by an individual maintainer or a project going quiet. Worst case, we've spent a day and kept the code."

To engineering: "It gives us a resource-backed picker — a searchable, filterable modal table over any Filament resource — instead of hand-rolling Livewire modals. Read it before you install it; it's small. Plan to vendor and wrap it rather than composer require in production, pin the version, and test the paths we actually use. Be clear-eyed on the signal: two stars, zero dependents, one maintainer. That makes it a reference implementation and a time-saver, not a load-bearing dependency. And check first whether native relationship Select or a relation manager already covers the case — if it does, skip the package entirely."