Nova Progressbar Field Laravel Package

Product Decisions This Supports

• Admin UX polish, not product differentiation. This field renders a stored number as a horizontal bar inside a Laravel Nova back-office resource. It helps internal operators scan completion, usage, or capacity at a glance. Fund it from internal-tooling budget, never the customer-facing roadmap.
• The real decision is "do we want progress bars in the admin at all?" The package is incidental. Answer the UX question first — which metrics, which views, read-only or editable, who owns the asset pipeline — then decide whether to buy, fork, or rebuild. Starting from the package gets the sequencing backwards.
• Build vs. buy resolves to "build." Five stars, zero dependents, archived repository, last release September 2019. That is not a validated ecosystem choice, it is a reference implementation with a Composer file. The field is roughly a PHP class plus a small Vue component; a first-party rebuild is cheaper than owning an abandoned Vue 2-era dependency.
• Use cases worth a timeboxed trial: read-only completion bars on detail views, compact index-view overviews, admin dashboards paired with Nova metrics, SLA burn-down, storage utilization, onboarding status, migration progress. One field instance per metric — not a multiplexed component.
• Decisions this should not drive: adopting Laravel Nova in order to get this field; any customer-facing UI commitment; any accessibility, security, or compliance claim; any expectation of Nova 4+ support or upstream fixes.
• Success criteria a PM can actually hold engineering to: the bar renders correctly for null, zero, negative, and >max values (clamped in PHP, not CSS); no N+1 queries on index views; the field survives the next Nova upgrade; an internal owner is named in the README. If those four aren't met, the feature isn't done regardless of how it looks.

When to Consider This Package

Adopt only when all of the following hold:

• The product already runs Laravel Nova and you need a small, read-only progress indicator on an internal admin screen.
• Installed Nova, Laravel, PHP, and front-end build versions are verified compatible in a non-production instance — or you are prepared to vendor/fork the code and own it outright.
• A read-only visual is genuinely better than the alternative (Number field with ->min(0)->max(100)); if a colored number communicates the same thing, skip the field.
• The need is low-risk and internal-only: no support contract, no accessibility guarantee, no design-system requirement, no customer exposure.

Look elsewhere or build in-house when:

• You are starting a new project, or running Nova 4+ — the 2019 release targets the Nova 1.x/2.x, Vue 2, Laravel Mix era. The compiled component will not mount: expect a blank field, unknown custom element, or asset compile failure.
• You need customer-facing UI, accessibility conformance, security review, or ongoing updates.
• You need editable input behavior — use a validated Number field instead.
• You need guaranteed clamping or threshold semantics the README doesn't promise.

Practical disqualifier to check before any evaluation: run composer why-not laravel/nova and read the package's own Composer constraints. If they don't cover your Nova major version, stop — the decision is already made.

How to Pitch It (Stakeholders)

For executives: This is a minor admin-panel utility that turns a stored percentage into a readable bar for internal operators. No revenue upside, no customer-facing differentiation, no operational or scaling exposure — it is authenticated admin UI only. Its archived status, 2019 release, and near-zero adoption make it a poor long-term dependency. Approve at most a small, time-boxed prototype; expect the recommendation to land on "reimplement in-house as a tiny first-party field." The honest cost is organizational, not technical: someone must own dependency updates, asset rebuilds, and revalidation on every Nova upgrade.

For engineering: It's a thin Nova field — a PHP class passing min/max/color meta plus a small Vue 2 component that sets bar width. Integration is a Composer install, asset registration, and one line per resource. The risk-to-value ratio is poor: version incompatibility, stale compiled assets that can't be rebuilt on a Vite pipeline, no tests, no maintainer, and unclamped values overflowing the bar. The cheap mitigation is to reimplement — copy the PHP field class, write a minimal Vue component, register your own script, and own it. If we fork instead, put it in an internal namespace, preserve the license header, and never let an unmodified archived package sit in production composer.json. Either way: resolve against computed values rather than raw columns, clamp to 0–100 in PHP, guard denominators against empty collections, and add the field to the Nova upgrade regression checklist.

For the wider business: No security, scaling, or compliance exposure — this only affects the internal admin. The tradeoff is ownership: a free add-on today becomes an indefinitely owned asset tomorrow, with a small but permanent maintenance tail tied to every Nova upgrade. Treat it as a two-day internal utility with a named owner, not as a dependency decision.