Product Decisions This Supports
- Form UX consistency for numeric input. If we standardize internal admin tooling on Filament, a stepper component gives us a consistent increment/decrement control for quantities, seat counts, retry limits, thresholds, and pagination/page-size settings, instead of every developer hand-rolling a Blade partial or a
->numeric() field with ad-hoc JS.
- Build vs. buy, resolved toward "buy cheap." The scope is small (a numeric input widget). The realistic alternative is roughly half a day of an engineer writing and testing a custom Filament field. A free MIT package with a small surface area is a defensible "adopt" if it clears a short technical spike — this is a low-stakes, reversible decision, not an architectural one.
- Roadmap signal for "polish the internal admin surface." This is the kind of component that shows up when we are investing in operator-facing tooling rather than core product. It supports a roadmap theme of "reduce bespoke form code in Filament panels," not a customer-facing feature.
- Feature-level use cases to slot into backlog items: inventory/stock adjustments, ticket or license quantity selection, tiered pricing quantities, numeric settings panels (timeouts, batch sizes, limits), and any field where click-through of small deltas beats typing.
- Vendor/dependency posture decision. Because it is a thin, single-maintainer package, adopting it is really a decision about whether we accept "small community package, forkable in an afternoon" as a category in our admin stack. This package is a good test case for that policy.
- Not a differentiator. Low adoption (13 stars) and a commodity capability mean this should never appear on a competitive or customer-value roadmap. It is an internal velocity line item.
When to Consider This Package
Consider it when:
- We are already running Filament (v3/v4 as supported by the release) and want a number field with increment/decrement affordances without writing a custom field.
- The requirement is genuinely a stepper: min, max, step, bounded numeric entry, small deltas. That is the whole product.
- The number of affected fields is small to moderate — a handful of settings or quantity inputs where the UX gain is worth a dependency.
- We are comfortable with the risk profile of a thin MIT package: one maintainer, low star count, no commercial support. Mitigate by pinning a version, reading the source (it should be short), and having a fork plan.
- We can validate it in a timeboxed spike against our actual Filament version, including accessibility (keyboard arrow keys, focus states, screen reader announcements for value changes) and mobile touch targets.
Look elsewhere (or build in-house / use native fields) when:
- We need currency formatting, thousand separators, masked input, sliders, ranges, or unit suffixes — that is a different and larger problem than a stepper, and this package will not carry it.
- The form is accessibility-critical or regulated; a low-adoption widget is not where we want to discover edge-case behavior.
- Our Filament version is pinned and incompatible, or we upgrade Filament frequently and cannot absorb a lagging community field.
- We only have one or two numeric fields — the integration and review cost exceeds the benefit;
->numeric() with min/max plus a small custom field is cheaper.
- We need support SLAs, security review artifacts, or a maintained vendor; this does not provide them.
- The team has no appetite for forking. With a package this small, the ability to vendor the code and own it is the real risk control — if we will not do that, do not adopt.
How to Pitch It (Stakeholders)
One-liner: A small, free, MIT-licensed Filament form component that turns numeric inputs into a stepper (increment/decrement with min/max/step). It is a convenience component for internal admin forms, not a product capability.
For executives: This is a low-cost, low-risk developer-experience item. It saves a modest amount of build time on internal tooling forms and contributes nothing to revenue or differentiation directly. The decision is small and reversible: the code is MIT and short enough to fork, so the downside is bounded to a few hours if we walk away. Recommendation: adopt behind a short technical spike, pin the version, and keep a fallback to a custom field.
For engineering: Evaluate against our Filament version in a one-day spike. Confirm min/max/step behavior, keyboard and screen-reader accessibility, Livewire state handling, and mobile touch targets. Read the source — the surface should be tiny. Pin the version, and if it becomes load-bearing, vendor/fork it rather than depending on a single-maintainer package. If the spike is anything other than clean, build the field ourselves; the delta is small.
Decision framing: Approve the spike, not the dependency. Adoption is contingent on the spike passing and on a documented fallback. Treat it as "borrowed code we could own," not "a vendor we rely on."