Number Plus Laravel Package

Product Decisions This Supports

• Admin tooling UX parity: Informs whether internal back-office forms (Laravel Nova panels) get a richer number input — currency masks, min/max clamping, step/increment controls, suffix/prefix units — versus shipping stock Nova number fields.
• Build vs buy for Nova field extensions: A useful reference point when deciding whether to write a custom Nova field in-house (one sprint) versus sourcing an existing package. This one is small enough that the build path is often faster than adoption.
• Roadmap scoping for internal ops features: Signals that "advanced number input" is a recurring need (pricing, inventory quantities, percentages, ratings, thresholds) across admin surfaces — worth bundling into a platform-level component rather than per-screen one-offs.
• Vendor/fork risk assessment: Its archived status is itself a decision input: it demonstrates a fork-or-internalize path for fragile, single-maintainer packages rather than a direct dependency.
• Not a customer-facing feature input: Nothing here supports consumer product surface decisions; scope it strictly to internal admin and operational tooling.

When to Consider This Package

Consider it only when all of the following hold:

• You already run Laravel Nova and have a specific number-field UX gap (masking, unit display, increment controls).
• You are prepared to vendor or fork it — the repo is archived, last released May 2023, has 1 star and 0 dependents, so there is effectively no community support, no security patching, and no compatibility guarantees with current Nova/Laravel versions.
• The scope is internal, low-blast-radius admin screens where a broken input is annoying, not revenue-impacting.
• You can test it against your exact Nova major version before committing.

Look elsewhere (or build in-house) when:

• You need maintained dependencies for compliance, SOC2, or vendor review — archived packages will fail procurement.
• You are not on Nova — the field is inert outside Nova's field API.
• You need locale-aware, currency-grade, or accessibility-certified numeric inputs; a single-maintainer, abandoned package should not carry that responsibility.
• The requirement is broad enough that a first-party or actively maintained field suite is a better fit.

How to Pitch It (Stakeholders)

To executives: This is a small, free UI component for internal admin dashboards built on Laravel Nova. It adds polish to number inputs (formats, bounds, units) but is abandoned — one maintainer, one star, no updates since 2023. Recommendation: do not adopt as a strategic dependency. If our ops team needs the capability, we treat it as a reference pattern and allocate a short engineering task to replicate it internally, which costs less than the long-term risk of an unmaintained package. Net cost: low. Net risk if adopted as-is: moderate.

To engineering: The package is a thin Nova field wrapper — likely a few hundred lines. Two viable paths: (1) fork and vendor it, pinning it in our repo with our own tests against the current Nova version; or (2) reimplement the needed behaviors as an internal Nova field, borrowing the API shape. Given zero dependents and archive status, path 2 is cleaner — it removes a supply-chain liability and gives us ownership of version compatibility. Either way, add a version-compatibility test and document it as internal-only tooling, never exposed to customers.