Dependent Filter Laravel Package

Product Decisions This Supports

• Admin/back-office filtering UX: Enables cascading filter experiences (e.g., Country → Region → City, or Category → Subcategory → SKU) inside Laravel Nova resource views. This directly affects how quickly ops, support, and sales teams can find records — a measurable productivity lever, not just polish.
• Roadmap prioritization for internal tooling: If your team already runs Laravel Nova, this represents a low-cost way to close a known UX gap without committing engineering sprints to custom filter logic. Useful when deciding whether to staff an "admin panel improvements" initiative now vs. later.
• Build vs. buy for a narrow feature: The package is small and single-purpose. A PM should frame the decision as "adopt, fork, or build in a day" rather than a strategic platform choice — the capability is table-stakes, the implementation is not strategic.
• Use cases: hierarchical taxonomy filtering, multi-tenant record filtering (Tenant → Project → Resource), locale/timezone/geography drill-downs, and any Nova resource where one filter's valid options depend on another's selection.
• Not a differentiator: This is internal-tooling plumbing. It won't move customer-facing metrics directly; it moves internal cycle time.

When to Consider This Package

Consider it when:

• You are already on Laravel Nova and the team is comfortable extending Nova's filter API.
• You need a small number of dependent filters on internal admin screens where UX correctness matters more than scale.
• You have appetite to vendor or fork the code — the package is tiny, so pinning a known-good copy into your repo is realistic if upstream goes quiet.
• You can validate Nova version compatibility yourself before adoption (test against your exact Nova release).

Look elsewhere when:

• Maintenance is a concern. Last release was February 2019 and the repo has ~26 stars — treat this as unmaintained. Compatibility with newer Nova majors is not guaranteed and should be verified, not assumed.
• You need active security patching or vendor support for a customer-facing or regulated environment.
• Your filtering needs are complex (full-text + faceted search, saved filter sets, cross-resource joins) — this package is not a search platform.
• You are not on Nova, or you are migrating off Nova — investing in a Nova-specific extension is a bet against your own roadmap.
• You need a general-purpose admin filter library with a broader maintainer base.

How to Pitch It (Stakeholders)

To executives: This is a small, single-purpose extension for our existing Laravel Nova admin panel that makes record-finding faster for internal teams through cascading filters (pick a region, then only relevant cities appear). Financial exposure is minimal — it's a few hundred lines of glue code, not a platform dependency. The trade-off: the package hasn't been updated since 2019, so I'd recommend a time-boxed spike (1–2 days) to confirm it works on our Nova version, with a fallback to a short internal build if it doesn't. Expected outcome: faster ops workflows with near-zero licensing cost.

To engineering: This is a low-surface-area dependency that solves a well-defined problem — dependent Nova filters. Recommended path: (1) verify compatibility with our current Nova version in a branch, (2) if it works, pin the version and vendor the source into our repo so we control future patches, (3) if it doesn't, the feature is straightforward to reimplement directly against Nova's filter contract. Do not plan on upstream fixes; assume we own maintenance from day one. Keep the integration isolated so removing it later is trivial.