Value Widget Laravel Package

Product Decisions This Supports

• Admin/ops dashboard scope. It answers a narrow question — "can we put a single KPI number in front of the team inside Nova?" — cheaply. Useful for surfacing MRR, active accounts, open tickets, failed jobs, or queue depth on a laravel-nova-dashboard board.
• Build vs. buy (build vs. borrow). The real decision it informs is whether a one-number tile is worth engineering time. The package is a thin wrapper over Nova's dashboard widget contract; the decision is usually "reuse the pattern" rather than "take the dependency."
• Roadmap gating for a metrics/analytics layer. Shipping a handful of value tiles is a low-cost way to validate that internal stakeholders actually look at a dashboard before funding a proper BI/reporting initiative (Metabase, Looker, or a custom reporting module).
• Internal tooling prioritization. Gives a PM a credible "we can do this in a day" option for internal visibility requests, freeing roadmap capacity for customer-facing work.
• Use cases it fits: internal ops health tiles, sales pipeline counters, support backlog counts, on-call/status indicators, per-tenant usage snapshots in a multi-tenant admin.
• Use cases it does not fit: customer-facing analytics, anything time-series or charted, drill-down/segmented reporting, alerting, or any surface where a number must be auditable.

When to Consider This Package

Consider it when:

• You are already running Laravel Nova and the digital-creative/laravel-nova-dashboard package — it is a widget for that dashboard, not a standalone Nova card, so it is a hard prerequisite.
• The requirement is genuinely a single value, not a chart, sparkline, or table.
• You need it this sprint and the alternative is writing a small custom widget yourself.
• You are comfortable treating the source as vendored example code you own and can modify.

Look elsewhere (or just build it) when:

• You are not on Nova. Nova is a paid, first-party product; this package is irrelevant outside that stack, and Nova 4+ already ships native value/metric cards — which makes the build-vs-buy case for a low-adoption third-party wrapper weak.
• Maintenance risk matters. Still a single maintainer with negligible adoption. The only movement since October 2023 is v1.0.2, a one-line-style patch that fixes a reactivity bug — a good sign someone is watching the repo, but not evidence of a support commitment, a roadmap, or compatibility work against newer Nova releases. For a core admin surface, prefer Nova's built-in metrics or a 60-line in-house widget you control.
• You need more than a number — charts, deltas/trends, caching strategies, authorization scoping, localization of number formats, or multi-tenant filtering. None of that is in scope here; check maintained Nova card/widget packages or build internally.
• You need a support contract, security review, or SLA. There is none.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed add-on that lets us put key numbers — signups, revenue, backlog — on the internal admin dashboard we already run, without buying another analytics vendor. Cost is effectively zero and it does not touch the customer-facing product. A recent patch (v1.0.2) fixed a refresh bug, so the tiles now stay in sync with the dashboard — a genuine usability fix, but not a signal that this is becoming a supported product. The realistic play is unchanged: use it as a template and own the code internally, so there is no long-term vendor or maintenance exposure. Think of it as a one-day internal visibility win that also tests whether the team will actually use a metrics dashboard before we invest in a real reporting stack.

To engineering: It is a thin wrapper over a Nova dashboard widget that renders a single value. The v1.0.2 patch addresses a reactivity issue — the widget now re-renders correctly rather than going stale — which removes the main "it's subtly broken" objection if anyone trials it directly. Adoption and maintainer count are unchanged, and Nova now has native value cards, so the recommendation is still reference, don't depend: read the implementation, copy the pattern into our own widget namespace, add the formatting/caching/permission handling we actually need, and keep it behind an internal interface so we can swap the presentation layer later. If someone wants to trial the dependency directly, scope it to a non-critical internal dashboard and pin the version.