Currency Laravel Package

Product Decisions This Supports

• Data-integrity risk triage: The 0.2.2 patch ("fixes decimal insertion bugs") is a correctness fix, not a feature. For a PM, this is a signal that decimal handling in this package has had real defects. Any roadmap item that depends on storing money, weights, rates, or other fixed-precision values needs this version pinned or the risk explicitly accepted.
• Build vs. buy: If the package is being evaluated as the persistence layer for decimal data, the fact that precision bugs shipped and are only now being fixed argues for either (a) adopting with rigorous test coverage around rounding/truncation, or (b) a thin in-house cast/mutator. Don't buy blind on feature lists; buy on correctness history.
• Release cadence and maturity gating: At 0.2.2 the package is pre-1.0. Treat it as "evaluation only" for anything revenue- or compliance-adjacent. Patch-only releases are a positive maintenance signal but do not establish API stability.
• Scope decisions: If the bug affects only a specific path (e.g., bulk import, seeders, casts), scope the adoption to that path and keep it out of core financial flows until a 1.0 or a documented stability guarantee appears.
• Regression coverage as an acceptance criterion: Add a PM-visible exit criterion: decimal round-trip tests (insert → read → compare) covering scale > 2, negative values, and boundary magnitudes before this package touches production data.

When to Consider This Package

Consider it when:

• You need Laravel-native decimal handling and the 0.2.2 fix directly addresses a defect you can reproduce or would have hit.
• Your use case tolerates pre-1.0 churn and you can pin versions and own the upgrade cadence.
• You have (or will build) tests asserting exact decimal precision at rest and in transit — not just "it saves without error."
• The alternative is a heavier dependency or custom code you'd maintain anyway.

Look elsewhere / defer when:

• The data is monetary, billing, tax, or regulatory. Pre-1.0 plus a recent precision defect is a poor risk profile without a documented precision contract (scale, rounding mode, storage type).
• You need guaranteed backward compatibility or a support SLA — 0.x offers neither.
• You can't inspect the fix. A one-line changelog ("fixes decimal insertion bugs") doesn't tell a PM the blast radius: which adapters, which DB drivers, whether previously written rows are now mis-stored. Get the diff before committing.
• Migration/backfill is implied. If prior versions wrote bad decimals, the package fix doesn't repair existing records; you'd own a data-remediation project.

How to Pitch It (Stakeholders)

To executives: This is a small, actively maintained Laravel package, but it's pre-1.0 and just shipped a fix for decimal data corruption. We can use it, but only with explicit precision testing and version pinning — and not, yet, on anything that touches money or regulated data. The decision isn't "adopt or not"; it's "adopt narrowly and verifiably, or wait for 1.0."

To engineering: Version 0.2.2 is a correctness patch. Before we take it: pull the diff, identify which insertion paths were broken, determine whether any data we've already written is affected, and add round-trip decimal tests at multiple scales and signs. Pin the version; assume the public API can change on any minor bump until 1.0. Recommend we hold this out of core billing flows and revisit at 1.0 or when a precision contract is documented.