Product Decisions This Supports
- Build vs. buy for back-office financial UI. This is a small, single-purpose Laravel Nova field that edits and displays monetary values (integer minor units + currency code) powered by
moneyphp/money. The decision it informs is not "which money library" but "do we lean on Nova plus a community field for pricing, invoices, refunds, and payouts, or fund custom admin screens?" Adopting it is a hours-not-weeks call that unblocks a finance-ops workflow.
- Multi-currency as a roadmap item. If multi-currency pricing, international expansion, or marketplace payouts are on the roadmap, an admin that reliably displays amount and currency removes a recurring source of operator error. The package is a cheap enabler for that direction — not the strategic decision itself.
- Feature scoping for finance-adjacent surfaces. Use cases where it shows up: subscription plan pricing, order/refund totals, ledger and payout review, invoice line items, promotional credits. If a proposed feature implies "support will read and adjust money values in Nova," this package is in scope. If it implies customer-facing or API-facing price display, it is not.
- Sequencing of admin tooling. Adopting it defers the alternative of shipping a raw numeric input (error-prone: currency-less amounts, wrong minor units) or writing a custom Nova field (~100–200 lines plus tests, roughly half a day). Either path is small; the decision is which to schedule.
- Dependency posture. With 73 stars, low differentiation signal (opportunity ~37.6), and no visible dependents, the strategic call is to treat it as a tactical, swappable utility — pin the version, wrap it in our own field class, and keep a custom-field fallback ready. It should not appear on any architecture diagram.
When to Consider This Package
Adopt it when all of the following hold:
- You already run Laravel Nova in production and are not evaluating an admin-panel migration.
- Your domain layer already models money with a currency (e.g.,
moneyphp/money, integer minor units + ISO code), so the field is a presentation/input concern only.
- The requirement is admin-side display and editing, where the correctness bar is "operators don't fat-finger amounts or drop the currency" — not FX conversion, rounding-policy enforcement, or tax computation.
- You have verified Nova major-version compatibility against your installed version; a single-maintainer field is the most likely thing to break on a Nova upgrade.
- You can absorb abandonment: the fallback (a custom Nova field) is under a day of work for a competent Laravel engineer.
Look elsewhere or build in-house when:
- You are not on Nova, or Nova's license cost and upgrade cadence aren't justified — evaluate money handling at the domain layer instead, not a field.
- You need anything beyond display/edit: currency conversion, historical FX rates, rounding/allocation rules, multi-currency aggregation, or formatted exports. These belong in domain services, not a field.
- You need vendor support, an SLA, security review paperwork, or a maintained release cadence — this package won't survive procurement scrutiny.
- Your persistence model is unsettled. A field won't fix a schema storing money as floats or dropping the currency code; settle storage (minor units + currency) first.
- You need customer-facing or API-facing money rendering — out of scope by definition.
How to Pitch It (Stakeholders)
To executives (one paragraph): We can give finance and support staff a correct, currency-aware way to view and adjust money values in our existing admin panel for effectively zero incremental spend, instead of funding a custom admin build. It's a small open-source add-on, not a platform commitment: low cost, low risk, roughly a day of engineering including review. It supports multi-currency operations if we move that direction, and we can replace it with our own component if it ever becomes a problem. Recommendation: adopt tactically, don't standardize on it, and don't put it on the architecture roadmap.
To engineering (the actual ask): Evaluate vyuldashev/nova-money-field as a thin Nova field over our existing money value object. Before wiring it up, confirm Nova version compatibility, whether it persists minor units (integer) or major units (decimal), and how it handles null, zero, negatives, and per-record currency. Pin exact versions of Nova, the package, and moneyphp/money; wrap the field in our own class so the dependency is a one-file swap; add a CI smoke test that boots a Nova resource route and asserts round-trip fidelity for amount + currency — that test is our early-warning system for Nova upgrades. Publish a one-line convention in the team wiki ("all monetary columns are integer minor units, currency stored alongside, display via the cast/field pair") and enforce it in code review. Budget half a day; if compatibility or persistence semantics don't line up cleanly, write the custom field instead — build cost is small enough that we should not spend more time evaluating than building.