Nova Linkable Metrics Laravel Package

Product Decisions This Supports

• Whether the admin panel is a report or a working tool. Nova metric cards answer how many but stop short of which ones. This package turns a card into a one-click entry point to a filtered resource index, so the real decision on the table is whether dashboards should be navigable. It makes the "working tool" option cheap to trial rather than a bespoke build.
• Build vs. buy on a bounded gap. The capability is roughly a trait plus a small Vue card wrapper — on the order of half a day to a day for a Nova-fluent developer. Adopting an MIT dependency is defensible when Nova-specific engineering time is scarcer than dependency-review time. The tiebreaker: if you expect to own and maintain that card wrapper anyway, writing it in-house keeps the upgrade path in your hands.
• Feature scoping for internal tools — a reliable quick win. "Let me click the churn number and see the churned accounts" is a recurring, high-perceived-value, low-effort request from ops, support, sales, and finance. No schema changes, no migrations, no new infrastructure — purely presentational. That profile slots neatly into a sprint as a visible win.
• Discovery prompts to map before committing: support backlog → open tickets filtered by SLA breach; revenue dashboard → accounts by plan and renewal window; onboarding funnel step → users stuck at that step; ops card → failed jobs or records in a given state. If those destinations aren't filterable Nova resources, the package cannot deliver the value.
• A useful de-prioritization signal. If your metrics are decorative — executive screenshots, weekly PDF exports, read-only status walls — click-through is noise. If no stakeholder has actually asked "can I click this?", park it and revisit when the request appears.
• Roadmap framing: presentation-layer enhancement, not analytics. It adds navigation, not data, segmentation, cohorts, or history. It should never be positioned as a substitute for a real analytics investment if stakeholders want exploration, exports, or non-Nova consumers.

When to Consider This Package

Adopt when:

• You are on Laravel Nova 4.x specifically and expect to remain there through the next dashboard iteration.
• You already ship Nova metric cards in production and stakeholders are asking to drill into them.
• Your destinations resolve cleanly to Nova resource index views with filter query strings — i.e., the metric's underlying query maps to a filterable resource.
• You want the capability without owning a custom Vue card, and the team is comfortable forking a small MIT package if the maintainer goes quiet.

Validate before committing:

• Nova major-version constraint. Nova 5 exists and the package is 4.x-scoped; the card-render override is coupled to Nova's internals, so "4.x" isn't a sufficient check — verify against your exact Nova patch version. This is the single most likely reason to walk away.
• API surface. Confirm concretely what "linkable" means: fluent setter on the metric class, URL callback, filter/query-string helper, target-window control, per-user authorization. The description advertises "fluent configuration" but doesn't name the methods — read src/, which is the actual documentation.
• Authorization layering. A clickable number that 403s is worse than a plain number. Confirm you can hide the card via authorizedToSee for viewers who lack access to the destination, and that the linked index has its own authorizedToViewAny policy.
• Maintainer and adoption risk. 21 stars and 0 tracked dependents is effectively one organization's internal tool published publicly. A recent release (Sept 2025) and MIT licensing mitigate this; a fork-and-own plan is not optional. Nova packages are overwhelmingly consumed in private repos, so dependents is a weak proxy — but there's still no public battle-testing evidence.
• Operational failure modes are silent. Published Vue assets that miss the build or cache-bust incorrectly render the metric without the link — no error. Add a cheap smoke test asserting a known metric's URL resolves so a Nova bump fails CI rather than a stakeholder's trust.

Look elsewhere when:

• You need exploration, not navigation — cohort analysis, ad-hoc slicing, scheduled exports, non-Nova consumers. Go to Metabase/Looker/Power BI or commission a proper Nova tool.
• You need links across models, external systems, or role-parameterized deep links with distinct targets. You'll outgrow the package's assumptions within a sprint.
• You're not on Nova, or you're mid-migration to Nova 5 or off it entirely. Don't take a dependency whose entire premise is tied to one framework version.
• Your team is small and dependency-averse. A one-off custom card is more honest than a dependency you'll fork in month three.

How to Pitch It (Stakeholders)

To executives: Our admin dashboards currently answer "how many" but not "which ones" — a manager who sees 47 overdue accounts has to rebuild that list by hand. This package makes those numbers clickable so the list appears in one click. It's MIT-licensed, adds no infrastructure, no database changes, and no new vendor relationship, and it's small enough that we can own the code outright if we ever need to. Frame it as a quick win: it converts dashboards we've already paid for into a tool people actually use, and it's a cheap hedge against someone commissioning bespoke dashboard tooling later. The honest boundary up front: "click the number to see the list" is in scope; "let me pivot on that list" is a separate analytics decision.

To engineering: A presentation-layer dependency for Nova 4.x that lets metric cards carry a link target — typically into a Nova resource index pre-filtered by query string. No migrations, no service provider doing anything clever, no request-path cost beyond rendering an anchor. It's a few hundred lines, MIT, and additive: annotations in, composer remove plus a published-asset clear to revert, so rollback is a five-minute operation. Three asks before we ship it: pin the exact version (no floating across Nova minors), mirror the repo internally at adoption time so a fork is always available, and add a unit test asserting the generated URL for a representative metric — because the two realistic failures (link disappears after a Nova patch, route target 404s after a filter key change) are both silent at render time.