Nova Multiple Dashboard Laravel Package

Product Decisions This Supports

• Validating demand for segmented dashboards. The package exists because Laravel Nova (versions 1–3) shipped a single dashboard. A community plugin with any traction is a cheap, real-world signal that admins want per-team, per-role, or per-client views. Treat it as evidence for a roadmap item, not as the roadmap item itself.
• Build vs. buy vs. wait. This is a textbook "wait" case: the vendor absorbed the capability natively in Nova 4 (nova:dashboard scaffolding plus dashboard-level cards and authorization). The decision it informs is: for gaps in a paid platform you already license, default to wait/upgrade unless the gap blocks revenue, and never let a deprecated third-party plugin become load-bearing.
• Upgrade and migration sequencing. If the app is pinned to Nova 1–3 and depends on this package, upgrading Nova is a prerequisite for the next dashboard feature — that's a dependency to size and schedule, not a detail for engineering to discover mid-sprint.
• Persona segmentation as table stakes. "Different users see different dashboards" is a baseline expectation for internal admin tooling, not a differentiator. This affects how you scope dashboards in discovery (per-persona, not one-size-fits-all) and how you price/position any customer-facing admin offering.
• Design reference for a first-party spec. The package's model — named dashboards, per-dashboard card sets, menu registration, access control — is a reasonable starting spec for your own implementation. Read the code as a requirements document.
• Vendor risk register. Adds a line item to the "unmaintained dependencies" list (last release 2019-05-31, archived, no security patch path). Useful input for a dependency policy: no new production dependencies from archived repos.

When to Consider This Package

Consider it only as a short-term bridge:

• The application runs Nova 1.x–3.x and a Nova upgrade is blocked by other work this quarter.
• There is a concrete, near-term need for multiple dashboards (e.g., a client-facing admin or distinct ops/support/exec views) and no budget to build it in-house.
• MIT license and a small code surface make it forkable and vendorable, and your team accepts ownership of that fork.
• You can pin the dependency, audit PHP/Laravel compatibility, and commit to a removal date.

Look elsewhere — or do nothing — when:

• You are on Nova 4+. Native dashboards supersede this entirely; adding the package is pure liability.
• You are greenfield. Do not adopt an archived package in a new project.
• You need maintained code or security guarantees. No releases in ~6 years, archived, no CVE response path. Any security review should fail it.
• You need real analytics. If the requirement is cross-source reporting, BI-style exploration, or embedded analytics for customers, evaluate Metabase, Grafana, or a first-party reporting layer instead of stretching Nova cards.
• The need is short-lived or speculative. If nobody has asked for a second dashboard yet, don't onboard the dependency to find out.

How to Pitch It (Stakeholders)

For executives: This is a free, open-source add-on that gave older versions of our admin platform something it now includes out of the box. It has been deprecated and unmaintained since 2019, so we are not adopting it as a strategic dependency — we're using it as market evidence that different teams need different views of the same data, and as a reason to get our admin platform onto a current version. Cost to act: near zero. Cost of ignoring it: a stale admin stack and engineers rebuilding a solved problem.

For engineering: One-line summary — archived Nova 1–3 plugin that adds named, per-dashboard card sets; superseded by Nova 4's native dashboards. Recommended posture: (1) if we're still on Nova ≤3 and a dashboard requirement lands, vendor a fork with pinned versions and no upstream expectation; (2) otherwise, put the Nova upgrade on the roadmap and use this repo's approach as the spec; (3) add it to the dependency-policy example list for "archived repos require a documented exception and an owner." We should also confirm whether anything in the current codebase already pulls it in transitively.