Filter Card Laravel Package

Product Decisions This SupportsGucci

• Admin UX roadmap — "should active filter state get dashboard real estate?" This is the real product question the package forces: should region/status/date-range filters sit as a visible card users can see and change on the Nova dashboard, or stay buried in the native resource filter dropdown? For ops, support, and content teams living in the admin panel all day, surfacing filter state is a legitimate workflow win. That's a yes/no on the admin backlog, not a vendor selection exercise.
• Build vs. buy (answer: build). The package's honest value is as a reference implementation, not a dependency. It sizes the work: a filter-summary card is roughly one PHP Card subclass, a Vue component that reads/writes $route.query, and a service provider — an afternoon to a few days of in-house effort, not a sprint. The decision lands as "build internally, keep it out of composer.json."
• Platform policy input. A concrete case study for a rule worth adopting: Nova cards are thin wrappers over Nova's private, versioned frontend API, so they should be vendored and owned internally, never installed from Packagist as if they were stable libraries.
• Roadmap signal for admin customization. If the roadmap includes a heavily customized Nova (custom dashboards, role-specific landing pages, saved views), this is a datapoint that such cards are cheap to write and cheap to own — which argues against accumulating third-party Nova cards as dependencies.
• Risk register entry. A 2019-era card with zero dependents, no maintainer, no tests, and no CI is a textbook "design reference that happens to be installable." It should not appear on a live build/buy comparison matrix. Allocate a code read, nothing more.
• Defer / non-decision. Don't spend PM time on it. The signal is "this UX idea is cheap; the package is not the point."
• Adjacent decision it does not support: filter management. Per-user saved views, sharing, and permissions are out of scope. The card is a display surface riding Nova's query string with no persistence. If "my saved filter set" is on the roadmap, that is a separate scoped feature, not this package.

When to Consider This Package

Only if all of the following hold:

• You are on Laravel Nova 1.x or 2.x — the last release was February 2019, so it almost certainly targets the pre-Vue-3 card API. Assume it will not resolve or mount on Nova 4/5 until a spike proves otherwise. Read the laravel/nova and php constraints in composer.json before anything else.
• You want the idea (filters rendered as dashboard cards) and are willing to fork and vendor the code rather than adopt a Packagist dependency.
• Your team already owns its Nova install and accepts that cards break on every Nova major upgrade — the expected failure mode is a card quietly vanishing from the dashboard with no PHP error.
• The admin panel is internal-only, so an unmaintained UI component carries no customer-facing risk.
• You have verified the license permits internal forking and redistribution. A repo with no LICENSE file is all-rights-reserved by default — check during discovery, not after vendoring.
• The team will not reach for --ignore-platform-reqs as a shortcut; that "works" and is a trap that defers the failure to every fresh clone, new hire, and CI run.

Look elsewhere — or simply build it — if:

• You need maintained code. No release in over six years, no dependents, no tests, no CI, no active maintainer. Bus factor is effectively zero.
• You're on a modern Nova version — you'd rewrite the JS entrypoint and card registration anyway, at which point you've built it yourself.
• You need real filter management: multi-filter persistence, sharing across users, permissions. Native Nova filtering plus remembered filter state already covers much of that ground.
• Procurement or security requires a support owner, a CVE-response path, or a dependency review with a live upstream. None of those exist here.

Practical recommendation: a half-day spike to read the source (one PHP Card subclass, a service provider, a Vue component — fifteen minutes of reading gives you the entire surface area), then reimplement the pattern in-house against your current Nova version. Scope it as a small UI task, not a dependency onboarding.

How to Pitch It (Stakeholders)

Executives (one line): A small open-source add-on that displays Laravel Nova filters as a card on the admin dashboard. It's a useful design reference, but it has been unmaintained since 2019 and no published package depends on it — so we are not adopting it as a dependency. If we want the UX, we rebuild it internally in a fraction of a sprint.

Engineering leads: Treat this as a pattern, not a package. It shows a compact way to lift Nova filters out of the dropdown and onto a dashboard surface, coupled to metrics through the URL query string so Back/Forward and bookmarkable dashboards keep working. Expect the code to target Nova's 2019-era card API; a from-scratch implementation against our current Nova version is likely less total effort than a port and gives us ownership. Proposed action: a half-day code read, then a small ticket to implement in-house if the UX is wanted. Do not add it to composer.json — a 2019 card will likely fail Composer resolution and asset compilation (Laravel Mix vs. our Vite build), and the workarounds (--ignore-platform-reqs, patching vendor/) create maintenance debt that outlives the benefit. If we do fork, vendor it into nova-components/, namespace its query parameters to avoid collisions with native filters, and add a one-line smoke check to the Nova upgrade runbook: load the dashboard, confirm the card renders, confirm changing a filter updates a metric.

Design / product owners: The UX bet is "visible filter state beats a hidden dropdown." Validate it cheaply — put a mock on the dashboard, watch whether ops/support actually change the filter there versus continuing to use native filtering. If usage is flat, skip the build and close the ticket with evidence.