Nova Detached Filters Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt for internal tooling: This collapses a decision that usually eats a sprint ("should we build detached filter controls into Nova?") into an afternoon's integration. It gives you a credible third option—adopt a $0 MIT dependency—before committing engineering cycles to bespoke Vue work. If the need is simply "keep our most-used filters visible," the decision is effectively closed.
• Roadmap prioritization of workflow friction: If support, ops, or finance hit the same Nova resource repeatedly and re-open a filter dropdown on every visit, this cheaply addresses repeated friction. It becomes a clean backlog item with a measurable success proxy: clicks removed per task and time-to-filtered-view.
• Admin-UX investment calls: It converts a vague "our admin panel feels clunky" complaint into a reversible, testable change (one line per promoted filter), letting you greenlight an ergonomics experiment without a design sprint or platform commitment.
• Platform strategy inputs: Because it functions only inside Laravel Nova, it informs the "stay on Nova vs. migrate the admin layer" conversation and adds a concrete line to every Nova major upgrade checklist ("re-verify detached filters").
• Scope discipline: It reinforces the boundary between internal ergonomics and customer-facing UX—keep it out of external release notes and marketing while still tracking it as an ops improvement.
• Exit-friendly experimentation: Adoption is additive and fully detachable, supporting a "try, measure, keep or remove" posture rather than a long-term bet—an easy win to bank on a quarterly plan.

When to Consider This Package

Consider adoption when:

• You already run Laravel Nova (v5, with a v4-compatible release) and the admin panel is a genuine daily-use internal product, not a rarely-opened back office.
• A small set of filters—status, owner, date range, tenant—is used constantly on high-traffic resources, and the extra click into a dropdown is real, repeated friction.
• You want a presentation-only change: no schema changes, no new endpoints, no migration effort. The package relocates filters; it does not alter filter logic.
• Your team has limited front-end/Vue capacity and would otherwise defer this improvement indefinitely.
• You can accept a single-maintainer, MIT-licensed, small-footprint dependency with modest adoption (63 stars, no listed dependents), mitigated by pinning the version, staging validation, and a rollback commit.

Look elsewhere when:

• You are not on Nova—the package is inert outside that stack (Filament, plain Blade, a custom React admin).
• You need advanced filter semantics: saved filter sets, shareable/bookmarkable filter state, multi-filter logic, or custom filter UIs. This package moves filters; it does not extend what they do.
• You require vendor SLAs, deep security review, or long-term support guarantees—a solo maintainer with zero listed dependents does not meet that bar.
• The filtering surface is customer-facing—always-visible filters are an internal-ergonomics pattern, not a public UX pattern.
• Your admin panel is low-traffic—the friction saved will not repay even the small integration and review cost.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed add-on for our existing Laravel Nova admin panel. It moves the filters our ops and support teams use every day out of a dropdown and onto the page as always-visible controls, cutting a repeated click out of high-frequency workflows. Cost is a few hours of engineering plus review—no license fee, no vendor contract, no lock-in. If it doesn't help, we delete one dependency line. The main caveat is that it's a niche, single-maintainer package with modest adoption, so we treat it as a low-risk experiment: pin the version, validate on staging, measure clicks-saved on one resource, then expand or revert.

For engineering: An additive Nova package that renders selected filters as detached, always-visible UI instead of children of the filter dropdown. MIT-licensed, last released February 2025 (with a Nova 5 compatibility fix), tiny code surface, presentation-layer only—no schema or API impact. It integrates per-resource via a trait or base-class change plus a composer require; the service provider is auto-discovered. Concerns to weigh: one maintainer, low star count, and no listed dependents (normal for Nova plugins, but still a signal), plus exposure to Nova's fast-moving internal filter components on every major upgrade. Mitigations: pin the package and an explicit Nova constraint together, test URL/filter state across pagination, sorting, bookmark/share, and reset, check for conflicts with other toolbar-modifying packages, and be ready to fork—the footprint is small enough that forking is a realistic fallback. Suggested rollout: timeboxed spike, pilot on one high-traffic resource, measure filter usage and time-to-task, then expand to 2–3 resources or roll back.