Nova Filterable Metrics Laravel Package

Product Decisions This Supports

• Self-serve internal reporting vs. an ad-hoc request queue. The package lets an existing Nova metric card (Trend, Value, or Partition) respect the Nova filters a user has already applied — date range, region, team — instead of showing one fixed number. That turns a PM question into a measurable one: how many recurring "can you pull this for Q3 by region?" requests from ops, finance, and support are we willing to keep absorbing, and does giving people the dropdown actually reduce them?
• Build vs. buy vs. reuse for back-office dashboards. It is a $0 MIT add-on that reuses filters the team already maintains, so the incremental cost is bounded by work already done. That makes it a cheap, low-commitment demand-validation experiment before funding a BI tool, a custom reporting service, or a headcount ask — the cheapest way to learn whether sliceable metrics change viewer behavior at all.
• Roadmap placement: "polish the admin panel," not a headline initiative. The whole capability is a fluent ->filters() call on existing metric cards, rendered as native dropdowns and date pickers. It belongs in a small internal-tooling sprint theme, and it raises the ceiling on what Nova dashboards can do without a redesign or a new data model.
• Consistency as a product quality bar. Today a resource table and a metric card on the same dashboard can show different numbers for the same apparent scope. That is a trust problem, not a UX nit — unifying them behind one filter model removes the "why don't these match?" thread from the support channel.
• Prioritization input for the analytics roadmap. Adoption (or rejection) gives real usage signal — which cards get filtered, which filters get used — that informs whether self-serve analytics deserves a real line item next quarter or stays a nice-to-have.
• Explicitly not a driver for: customer-facing analytics, public or contractual reporting, pricing logic, billing, or anything with an availability commitment. Scope is internal, read-only admin tooling only.

When to Consider This Package

Consider it when:

• The product actually runs on Laravel Nova — last release (v1.3.0, 2023-03-31) targeted Nova 4. Outside Nova the package is inert; the evaluation ends there.
• There is a named dashboard where users already ask for date/region/team slicing, with Trend, Value, or Partition cards as the target.
• The team already maintains Nova filters. The entire value proposition is reuse — with no filters registered, there is nothing to attach it to and the integration cost buys nothing.
• The need is internal, read-only, and low-traffic: ops dashboards, support queues, finance rollups.
• You want a cheap demand-validation step before committing budget to BI or a reporting service.
• You are willing to treat the code as forkable and disposable, with a named internal owner and a review date.

Look elsewhere when:

• No Nova dependency — the package has no relevance.
• Maintenance continuity is a requirement. The repo is archived, last released 2023-03-31, with 24 stars and zero dependents. There is effectively no community backstop; adopting it means adopting the code.
• You need support, security triage, an SLA, or a deprecation policy. None exist for an archived single-maintainer package.
• The metrics are load-bearing for external or contractual reporting, or the admin surface is customer-facing.
• Nova now ships equivalent native metric filtering — verify against current Nova docs first; if native support covers it, the decision collapses to zero and the ticket closes.
• You are pre-Nova-4, or a Nova major upgrade is already on the near-term roadmap and nobody will own a fork through it.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed add-on that lets people filter the numbers on our internal admin dashboards — pick a date range, a region, a team — instead of reading one fixed figure. The business case is narrow but genuine: fewer ad-hoc "can you pull this?" requests, and a cheap way to learn whether self-serve analytics is worth real investment. The material caveat is that the project is archived — last shipped March 2023, no maintainer updates, no support — so treat it as an experiment, not infrastructure. Recommendation: if we use it, we adopt the code, name an owner, budget a small amount of maintenance time, and cap how many dashboards depend on it. No vendor spend, no roadmap change, and nothing external or contractual should ever rely on it.

For engineering: The scope is deliberately tiny — it adds a ->filters() call to Nova Trend, Value, and Partition metric cards and renders filters as native controls, with metric filters kept independent from resource filters. Before committing:

1. Confirm the current Nova release doesn't already do this natively. If it does, close the ticket and use the built-in path.
2. Read the package's Composer constraints against our Nova major, PHP, and Laravel versions — the last release predates current ones.
3. Vet query behavior. Filters apply to metric queries, so confirm no unbounded scans or N+1s on our dashboards, and that filter values are validated rather than passed through. A filter that mis-applies to an aggregate produces a plausible but wrong number — the failure mode that erodes dashboard trust fastest.
4. Check canSee / authorization on cards so filtered metrics don't expose data to roles that shouldn't see it.
5. Decide ownership up front. If we adopt: pin the version, fork under our namespace, add a smoke test, and log a review date. If nobody will own it, don't adopt — an archived dependency that silently breaks on the next Nova upgrade is worse than no filtering at all.

Effort to validate is hours, not sprints: fork, wire one card to one existing filter, verify output against a known query, and compare that against the in-house cost of reimplementing ->filters() on Nova's metric API — that comparison, not "$0 vs. free," is the real decision.