Product Decisions This Supports
- Multi-currency and regional pricing roadmap. v2.0.0 changes the default currency to EUR, which tells you the package now assumes a European-first baseline. That is a product-level default, not just a code detail: it decides what a fresh install shows a customer before anyone configures anything. If your revenue base is USD or GBP, that decision now has to be made explicitly rather than inherited.
- Build vs buy for money handling. Currency formatting, rounding, and default-currency configuration are commodity logic. This is a buy/adopt decision unless you have exotic requirements (multi-tax-jurisdiction rounding, FX hedging, settlement reconciliation), in which case it is a component inside a larger build.
- Upgrade sequencing on the roadmap. v2.0.0 is a breaking release on two axes at once — configuration file format (PHP config to YAML) and default currency (to EUR). That is a scheduled migration item with a maintenance window, not a patch bump. It belongs in the same planning conversation as any pricing, checkout, or invoicing work.
- Configuration ownership and operability. Moving config to YAML is a departure from Laravel convention. It affects who can edit pricing configuration (developers only, or ops/finance too), how config is reviewed in pull requests, and whether
config:cache and environment-variable overrides still behave as the team expects. Those are process decisions the PM should surface before engineering discovers them mid-sprint.
- Concrete use cases in scope: SaaS pricing pages, invoice and receipt rendering, checkout totals, multi-region catalogs, marketplace payouts — anywhere a default currency silently shapes what the customer sees.
When to Consider This Package
Consider adopting when:
- Your Laravel application already needs currency-aware pricing or display formatting and you would otherwise hand-roll it.
- A European or EUR-primary market is your default, or you are willing to override a EUR default in configuration from day one.
- You can absorb a major-version config migration on a known timeline, and someone owns the config files in version control.
- Your team is comfortable reviewing YAML configuration alongside PHP, and your deployment pipeline has been checked against the new format.
Look elsewhere or defer when:
- You are mid-quarter on pricing or billing work and cannot take a breaking config change. Pinning to v1.x is the lower-risk call; budget the v2 migration as its own ticket.
- Your configuration is managed by non-developers, lives in environment variables or a secret manager, or must be auditable for compliance reasons. A YAML file in the repo may not satisfy that, and the format change makes the audit story worse before it makes it better.
- Your currency needs are genuinely trivial — a single currency, static prices, no conversion. A handful of helpers will cost less than a dependency plus an upgrade cycle.
- You need FX rate feeds, tax calculation, or payment orchestration. Those are separate concerns; do not let a currency-formatting package get scoped into solving them.
- You require strict backward compatibility guarantees across minor and major versions.
Migration risk to verify before committing: confirm whether the currency change reinterprets stored amounts or only changes display and defaults, and confirm that config caching still works under YAML. The quiet failure mode here is showing or charging EUR where USD was intended.
How to Pitch It (Stakeholders)
For executives: This is a small, well-scoped dependency that handles currency configuration and formatting, and it has just shipped a breaking major version. Two things changed: how it is configured, and what currency it assumes by default. The cost is a one-time migration ticket measured in days, not a rewrite. The reason to act deliberately rather than automatically is that the default currency change is silent — if we upgrade without an explicit configuration and a test, we risk displaying European pricing to customers who expect dollars. Recommendation: approve a bounded migration with regression tests on every surface that shows a price, and do not upgrade until those tests exist.
For engineering: Two breaking changes to plan around. Config files move from PHP to YAML, so we need to check publishing, config:cache behaviour, and any environment overrides before deploying. The default currency moves to EUR, so any surface relying on the implicit default needs an explicit setting plus an assertion. Add tests that pin currency on pricing pages, invoices, and checkout totals before the upgrade lands, and verify nothing persisted is reinterpreted as EUR.
The ask: a short, scheduled migration with clear test coverage, not an opportunistic dependency bump.