Nova Custom Dashboard Card Laravel Package

Product Decisions This Supports

• Pricing the "custom dashboard" ask before it becomes a vendor evaluation. The package is a working proof that a composite Nova card — one tile that nests existing metric cards into a labelled panel ("Sales", "Support") — is one to two developer days of work. That converts a vague stakeholder request into an engineering estimate, so we can defer a Metabase/Looker/Tableau conversation with evidence instead of opinion.
• Build vs. buy for internal admin tooling. It anchors the "hand-roll" side of the line. If composite panels satisfy roughly 80% of reported dashboard demand, we push BI license spend and vendor management out by a quarter or more. If demand immediately turns to ad-hoc queries, cross-source joins, or scheduled exports, we've learned cheaply that it's a real BI need and this is the wrong tool.
• Roadmap sequencing for the admin experience. It establishes the ceiling and floor of what Nova renders natively before we commit to a bespoke admin home screen — useful for pressure-testing per-persona requests: exec summary panels (revenue, churn, active tenants), support/ops overviews (queue depth, SLA breaches), per-tenant landing pages, and config-driven per-team dashboards where adding a metric is a config line, not a deploy.
• Separating a one-off screen from a platform capability. The package answers "can we do this at all?" It does not answer "should every team build their own?" That distinction decides whether custom dashboards become a shared internal card library with conventions (audience grouping, width rules, canSee() gating) or a divergent-pattern problem we inherit in a year.
• Scoping risk and ownership up front. Because it is archived, unmaintained, Vue 2-only, and has zero dependents, adopting it forces explicit decisions we would otherwise discover late: named internal owner, feature flag, rollback path to native Nova cards, and a place on the platform-upgrade checklist.
• Surfacing data-governance questions early. Anything passed to the card becomes JSON in the page, and card-level authorization is ours to implement, not the package's. That makes dashboard work a forcing function for scoping queries by tenant/role — a product and compliance decision, not just an engineering one.

When to Consider This Package

Treat it as a reference implementation to read, not a dependency to install, and only when all of these hold:

• We need a composite/nested dashboard card and want a working starting point rather than a blank file.
• We are on a legacy Nova 1.x/2.x install, or deliberately pinned to a Nova version contemporary with 2018.
• Someone can spend a day auditing the PHP/Vue for compatibility and vendoring it under MIT terms.
• We accept outright ownership: it is archived, last released August 2018, 87 stars, zero dependents — no Nova 4/5 fix, no PHP 8.x fix, no security patch, ever.
• We have a named owner, a feature flag, and a documented rollback to native Nova cards before it ships.

Look elsewhere, or build in-house, when:

• We are on Nova 3 or later. API drift makes archived code a liability, and Nova 4+ ships native multiple dashboards (Nova::dashboards()) solving the same problem with supported code.
• We need a security response path, Laravel upgrade support, or any vendor SLA — none exist.
• The requirement is genuinely BI: ad-hoc queries, cross-source joins, scheduled exports. Different buy decision entirely.
• The dashboard must be permission-scoped at the card level across tenants. There is no permission model here; the cards surface operational and customer data.
• We want a reusable capability across teams. Distributing forks of an archived card institutionalizes inconsistency; standardize on one internal card library instead.

Rule of thumb: adopt only as a contained, owned, legacy-only accelerator — never as a new strategic dependency.

How to Pitch It (Stakeholders)

To executives: There is an open-source MIT Laravel Nova card that arranges existing metric cards into custom admin dashboard layouts — grouping six metrics into one labelled "Sales" or "Support" panel rather than a flat grid of tiles. It costs nothing to learn from and gives us a credible price for the recurring "custom dashboard" request: roughly one to two developer days of internal work, no license, no vendor contract. The package itself was last updated in 2018, is officially archived, and has zero downstream users, so we treat it as a design blueprint rather than a production dependency. That framing also gives us a defensible reason to defer a BI tool purchase until internal demand outgrows what Nova can render — a decision we revisit with data, not by default.

To engineering: This is a pattern, not a platform bet. Read the card class and the Vue wrapper, then build a first-party card inside our own codebase rather than installing a 2018 package on a Nova version it was never written for. The highest-leverage use is a full-width wrapper that hosts real child Nova cards, so each nested metric keeps its own data fetching and width(); the PHP side should pass computed, cached scalars — not queries, not models — into the Vue layer. Three things will bite us and should be in the ticket: component-name mismatches render blank with no error, widths must sum to 12, and the whole cards() payload runs on every dashboard load, so caching is mandatory. We own authorization: canSee() on the wrapper hides the panel but does not re-evaluate nested cards, so gate and tenant-scope at the point we build the child array. Ship behind a flag with a fallback to native Nova cards, pin the version if we vendor it, and name an owner. If a second team wants this, they get the shared card library — not their own fork.