Nova Dependent Filter Laravel Package

Product Decisions This Supports

• Admin/internal tooling roadmap prioritization. This package is a lever for back-office operator efficiency, not a customer-facing capability. It supports decisions about which admin screens get investment in lookup ergonomics — cascading Country → State → City, Category → Subcategory → SKU, Account → Project — where the value is measured in time-to-filter and reduced "wrong filter returned nothing" support tickets.

• Build vs. buy vs. borrow for a narrow Nova utility. The decision this package forces is explicit: at 3 stars, 0 dependents, and a single maintainer, it is not a vendor relationship — it is source code your team takes ownership of. Frame the comparison honestly: a reusable cascading-filter pattern across several Nova resources vs. a one-to-two-day hand-rolled Vue/Nova filter for a single screen. Buy (adopt) only when the pattern repeats; build when it doesn't.

• Feature scoping and blast-radius boundaries. It supports an explicit product decision to confine dependent filtering to internal, non-critical admin surfaces. Setting the boundary — this will not become load-bearing for revenue-, support-, or finance-critical workflows — is a PM decision, and it should be recorded before rollout, not discovered after an incident.

• Go/no-go pilot definition. It enables a concrete, cheap decision framework: one non-critical Nova resource, a named internal owner, a two-week pilot, and a defined efficiency metric (e.g., median time-to-filter on a support lookup). If the pilot doesn't move the metric, drop it and hand-roll that one screen.

• Ownership and maintenance-risk decisions. Low adoption plus a single maintainer means the PM decision is not just "adopt or not" but "who owns this at 3 a.m." It supports decisions about preemptive forking under the org account, budgeting roughly a day per Nova major upgrade to patch or replace, and naming an owner on a team roster rather than a PR description.

• Explicit non-goals. It supports documenting what you won't do: no customer-facing filter behavior, no multi-tenant authorization guarantees you can't verify, no dependency on a package whose frontend rides Nova's undocumented internals without an exit plan.

When to Consider This Package

Consider it when all of the following hold:

• The product already runs Laravel Nova — the package has no standalone mode and composer require fails resolution without laravel/nova already installed and locked.
• The need is specifically dependent/cascading filters, not general filter customization.
• Engineering can confirm in a short spike: supported Nova major (4.x vs. 5.x, Vue 2 vs. Vue 3), PHP floor, whether the option fetch is server-side per parent change or preloaded, whether it ships precompiled JS or raw .vue requiring a consumer build, URL-state behavior on reload and "Reset Filters," and whether options() respects Nova policies.
• Scope is small and inspectable — internal admin panels, back-office ops, or prototype Nova resources where a broken filter is inconvenient but not revenue-critical.
• An internal owner is named with a defined success metric and a two-week pilot on a non-critical resource.
• A thin internal wrapper is acceptable (App\Nova\Filters\DependentSelect extending the package base) so the dependency is isolated to one file and swappable.

Look elsewhere or hand-roll when:

• The product does not use Nova, or needs filter types the package doesn't handle (date ranges, belongsTo lists with custom presentation, policy-nuanced option sets).
• Only one screen needs the behavior — a custom Vue Nova filter is comparable effort with full ownership.
• You require strong multi-tenant authorization guarantees or a vendor with active maintenance and broad adoption.
• The surface is customer-facing, high-traffic, security-sensitive, or long-lived critical — unless the team formally accepts full ownership of the code.
• Nova upgrade risk is unacceptable — zero dependents is a weak ecosystem signal, Nova's frontend internals churn between majors, and upstream fixes won't land on your timeline.

How to Pitch It (Stakeholders)

Executive summary. This is a small Laravel Nova utility that enables dependent, cascading filters in admin screens — pick a country, the city list narrows instead of dumping everything. It can measurably improve operator efficiency and reduce filtering mistakes in internal tools. But with 3 stars, zero dependents, and one maintainer, it is a tactical, low-risk-only option — not a strategic platform investment. The license cost is zero; the real cost is ownership.

For engineering. Treat it as a narrow, inspectable package you are adopting as source, not as a vendor product. Isolate it behind one internal abstract base extending the package's base class — never Nova's Filter directly, which silently fails to cascade. Guard every options() against an empty parent by returning [], never the full set; that unguarded pluck() is the single most common path to a cold-start performance incident on a large index. Scope option queries through the same policies as the index query so the child filter can't enumerate records the user can't view. Register the parent filter first, always. Add nova:publish --force to the deploy pipeline — stale published assets is the classic silent failure where filters render but options never refresh. Budget roughly a day per Nova major upgrade, and fork under the org account before you need to patch.

For the business. Approve only as a scoped internal-tooling experiment: one non-critical Nova resource, a named owner, a two-week pilot, and a defined efficiency metric. Cascading filters shorten lookup workflows for support, ops, and finance — a plausible small win, not a differentiator. Do not let it leak into customer-facing or revenue-critical workflows. If the pilot doesn't move a measurable internal metric, drop it and hand-roll the filter for that specific screen.