Decimal Input Laravel Package

Product Decisions This Supports

• Feature scoping for money and quantity inputs. This package targets a concrete, recurring slice of form work — price fields, invoice line items, tax rates, discounts, inventory quantities, and measurement inputs — so it directly informs whether those fields get built in-house or assembled from an existing component.
• Build vs. buy for a narrow capability. The realistic alternative is roughly a hundred lines of custom Blade plus a Laravel validation rule. Framing the decision that way keeps the conversation honest: this is a convenience dependency, not a platform bet, and the PM should weigh it against engineering time saved on one or two forms rather than against a full forms library.
• Roadmap input for form standardization. If multiple surfaces in the product collect decimals with inconsistent separators and rounding, this package is evidence that a shared input boundary is worth scheduling — whether or not this specific package is the vehicle.
• Risk triage for regulated or revenue-critical flows. The package sits exactly where silent errors are most expensive (locale-flipped separators, rounding drift on write). That makes it a useful forcing function for a decision the PM should be making anyway: where does decimal normalization live, and who owns it.
• Pilot candidate rather than commitment. At version 0.0.1, with a release note that contains nothing but an auto-generated changelog link, the only defensible product decision it supports today is a bounded experiment in a non-critical path.

When to Consider This Package

• Consider it for a Laravel application that needs simple, locale-aware decimal entry in Blade forms and wants PHP-side normalization and validation instead of hand-rolled JavaScript.
• Consider it for prototypes, internal admin tools, or early-stage products where a short spike is cheap, the API can change under you, and one engineer can read the source in an afternoon.
• Look elsewhere — or plan to write it yourself — if you need production-proven stability, a documented support policy, accessibility guarantees, broad locale coverage, or any frontend outside Laravel.
• Do not adopt for regulated financial systems, billing that must reconcile to the cent, or any flow where a wrong value is written silently rather than rejected. The correctness risks here fail quietly, which is the worst failure mode for money.
• Gating criteria before any wider rollout: the internal numeric representation must be confirmed non-float, a test suite must be verified against adversarial inputs ("1.234,56", "1,234.56", "1 234,56", .5, 1e3, empty, non-breaking spaces), declared PHP and Laravel constraints must match your runtime, and the maintainer must show signs of life. Absent those, the answer is no.
• Re-evaluate at 0.1.0 or on evidence of active maintenance and real release notes.

How to Pitch It (Stakeholders)

• To executives: A small, MIT-licensed Laravel package that could cut custom development on decimal and currency form fields in billing, commerce, and admin workflows — improving input accuracy and shortening delivery on a recurring class of feature. Frame it as a two-day pilot, not a platform commitment: it is at 0.0.1, single-maintainer, and the fallback is a small piece of in-house code, so the downside is bounded and the exit is cheap.
• To engineering: Treat it as a presentation-boundary utility — parse and validate at the edge, keep authoritative arithmetic in integer minor units or bcmath, and never let it become the domain's money type. Wrap it in a thin internal adapter so it can be swapped in a day, pin the exact version, and run the pilot on one form behind a flag with persistence round-trip tests against a DECIMAL(p,s) column. Before that, do the spike: read the source, run the tests, and confirm values are not held as floats — float would be disqualifying.
• The one-line ask: approve a timeboxed single-surface pilot with a pre-agreed replacement plan, and revisit the buy decision once we have either clean operation for a few weeks or a reason to walk away.