Nova Progress Field Laravel Package

Product Decisions This Supports

Feature-level: admin surface polish, not product differentiation. This package does one thing — render a numeric attribute as a horizontal progress bar inside a Laravel Nova resource. It supports decisions where the user is internal (ops, support, CS, finance) and the question is "how far along is this thing?" rather than "what should we build next?"

Concrete use cases it enables, each of which is a recurring internal-tooling request:

• Onboarding/completion tracking — customer onboarding %, profile completeness, KYC document progress.
• Capacity and quota visibility — storage used, seat utilisation, API call budget, plan-limit consumption per account.
• Delivery and pipeline health — campaign send progress, batch job completion, SLA window elapsed, ticket resolution stage.
• Scoring and risk bands — lead score, health score, risk rating rendered as a bar instead of a raw integer in Nova index views.

Build vs buy: this lands firmly in "build." The capability is a single Blade view plus a Nova Field subclass — roughly 40–80 lines of code with tests. The package is archived (last release August 2022), has 1 star, 0 dependents, and no maintainer obligation behind it. Adopting it as a dependency trades a 90-minute internal build for an unowned, unpatched artifact that will break on the next Nova major. For a PM, that is a negative-value trade: the time saved is smaller than the cost of the first compatibility incident.

Roadmap implication: treat "readable metric display in the admin panel" as a design-system decision rather than a vendor decision. If your roadmap includes more internal dashboards, standardise progress/status/metric visualisation once, in-house, and reuse it across Nova resources. This package is a useful reference implementation and spec — it tells you what props and formatting options matter (value, max, label, colour states) — but not a component to depend on.

Where it does not inform decisions: it has no bearing on customer-facing UX, pricing, retention, or any metric tied to revenue. Do not let a "we could add a progress bar" request in an admin panel consume roadmap capacity or trigger a procurement/security review cycle disproportionate to a UI primitive.

When to Consider This Package

Consider it only under a narrow, usually temporary set of conditions:

• You are already running Laravel Nova 4 and need a read-only progress indicator in an index or detail view within the same sprint.
• You want a shortcut to prototype an internal dashboard to validate that a metric display changes operator behaviour, before investing in a house component.
• You accept vendoring the source into your own codebase (copy the field class, Blade view, and assets) rather than installing it via Composer — so that you own patching and are not exposed to the archive.
• Your team has verified the license terms permit that vendoring, and a reviewer has read every line (the surface area is small enough that this is realistic).

Look elsewhere — or build — when any of the following hold:

• You are on Nova 5 or plan to upgrade; an archived 2022 field has no upgrade path and Nova major versions routinely change asset registration and field APIs.
• You need interactivity or thresholds: conditional colour bands, click-through to a filtered list, tooltips, animated transitions, multi-segment bars.
• You need accessibility guarantees (ARIA roles, screen-reader semantics) or theming that matches your design system.
• You require maintenance SLAs, security advisories, or vendor support — there is no vendor, no dependents signalling real-world use, and no release cadence.
• The metric is customer-facing or revenue-adjacent, in which case a throwaway Nova field is the wrong layer entirely.

A practical rule: if the total build is under half a day, and the package is archived, the default answer is build. Consider the package only as a time-boxed prototype accelerant.

How to Pitch It (Stakeholders)

To executives — one line: This is a tiny open-source UI widget for our internal admin panel; it is free, low-risk, and low-value, and we should not spend a vendor review on it. Recommendation: reproduce it internally in under a day and own it.

The executive framing: Nova is our internal back office, not a customer product. The progress bar is cosmetic polish that makes operational data faster to scan — a marginal efficiency gain for internal staff, not a growth lever. The package itself is abandoned (archived since 2022, effectively zero adoption), so treating it as a dependency would create a small but permanent maintenance liability for a capability we can rebuild cheaply. The correct decision is to treat the repository as a design reference and ship our own field, which costs roughly one engineer-day and eliminates upgrade risk on the next Nova release. There is no procurement, no licensing spend, and no meaningful opportunity cost.

To engineering — the ask: Review the repo (it is small) as a spec for a first-party Nova field covering: numeric value with a configurable max, percentage label, and threshold-based colour states. Implement it as an internal package with a couple of feature tests, register it once, and reuse across resources. Do not add a Composer dependency on an archived repository. Flag if any resource currently depends on it so we can migrate in the same pass.

Risk statement if we do nothing: none — the capability is optional and no current system depends on it. That absence of dependency is precisely why the build-instead-of-buy call is safe to make unilaterally.