Nova Currency Vat Field Laravel Package

Product Decisions This Supports

• Build vs. buy on the form layer. This package owns input rendering and input behavior in a Laravel app — the small, unglamorous work our engineers otherwise re-implement per project. That makes it a candidate to standardize on for internal tools and admin surfaces, rather than maintaining bespoke Blade/Livewire field components.
• Removing recurring UX defects from our backlog. Release 3.1.1 disables scroll-wheel changing input values. That is a classic source of accidental data entry (a user scrolls a long form, the page scrolls, a focused field silently increments). Sourcing this fix from the dependency instead of our roadmap is exactly the kind of trade a PM should be making — it converts a recurring "we should fix that someday" item into a version bump.
• Data-integrity decisions. Inputs that mutate on scroll create silent, hard-to-reproduce bad records. A dependency that treats this as a correctness issue (not just polish) is aligned with our data-quality goals for anything where users enter numbers — pricing, quantities, thresholds, settings.
• Upgrade cadence policy. The 3.1.1 change is a patch-level behavior change: no migrations, no API changes, no deprecations. It supports a "ride along with routine dependency bumps" policy for the 3.1.x line, with a targeted QA check rather than a full regression cycle.
• Scoping what we still own. This package decides how fields behave; it does not decide our validation rules, conditional logic, approval flows, or domain-specific form semantics. Useful for setting a clear boundary in sprint planning: rendering and input mechanics come from the dependency, business rules stay ours.

When to Consider This Package

• Form-heavy Laravel applications — internal admin panels, back-office tooling, data-entry workflows — where engineers are repeatedly hand-rolling input behavior and validation display.
• Server-rendered or Livewire/Blade architectures rather than SPA front ends with an existing JavaScript design system; adopting a PHP-side form layer alongside React/Vue components usually creates two competing sources of truth.
• Teams that want correctness wins (scroll handling, focus behavior, predictable field semantics) without owning the maintenance.
• Look elsewhere when: forms are a small or peripheral part of the product; the front end is already a mature JS component library; or we require formal accessibility audit, security review, or vendor support that an open-source dependency cannot commit to.
• Caveat on this assessment: the only evidence available is the 3.1.1 changelog. Before committing, we need a proper package evaluation — maintenance activity and release cadence, Laravel/PHP version support window, test coverage, open security advisories, license, and how actively breaking changes are handled. A single patch note is enough to justify a spike, not an adoption decision.

How to Pitch It (Stakeholders)

• For executives: a low-cost, low-risk dependency that absorbs small-but-recurring UX and data-entry defects instead of consuming our engineering capacity. The 3.1.1 release is a clean illustration — it stops users from accidentally changing values by scrolling, a known source of bad data and support tickets, without us writing or maintaining that code.
• For engineering: patch release, no breaking changes, no migrations, no required code changes beyond a routine version bump. The one thing to note is that it is a behavior change — scroll no longer modifies input values — so QA should spot-check dense numeric entry screens where a user may have previously relied on scroll-to-set. Treat 3.1.x as a safe bump.
• Recommendation: approve the 3.1.1 upgrade now as routine maintenance; treat formal adoption of the package as an open build-vs-buy item pending a full evaluation, since we have not yet completed one.