Money Laravel Package

Product Decisions This Supports

• Feature pricing and money-handling architecture. This package models the "money as integer minor units + currency value object" pattern (100 cents, not 1.00 float). That pattern informs how we specify pricing, discounts, tax, refunds, and ledger entries in any commerce, billing, or subscription feature.
• Build vs. buy vs. borrow. The package itself is not a viable buy, but it is a useful design reference when deciding between (a) storing raw integers and floats, (b) rolling our own Money value object, or (c) adopting a maintained library like moneyphp/money or brick/money. It crystallizes the decision: value objects are a solved problem; we should not build.
• Roadmap input for multi-currency and rounding. Because the API exposes getAmount() (minor units) and getConvertedAmount() (base units), it is a concrete conversation piece for roadmap items like multi-currency pricing, currency-specific rounding rules, and display formatting.
• Debt and dependency risk framing. With a last release in 2013, zero listed dependents, NOASSERTION licensing, and an archived repo whose README states the author abandoned it, this is a clean example for justifying a standing "no unmaintained dependencies" policy and for auditing legacy code that may already require it.
• Interview/onboarding and tech-talk material. It was literally built as a PHPUnit example; a PM can use it to explain value objects, immutability, and the float-money bug class to non-finance stakeholders without a whiteboard.

When to Consider This Package

Consider it only in these narrow cases:

• As a teaching or reference artifact, not a runtime dependency — to illustrate value-object design, integer minor units, and currency-aware arithmetic in a design doc or internal talk.
• When auditing an existing legacy codebase that already depends on sebastian/money; then it is a known liability to scope for replacement rather than a candidate for new work.
• When the team is explicitly comparing money libraries and wants the canonical "don't do this" baseline against moneyphp/money and brick/money.

Look elsewhere — decisively — when:

• Any production use is intended. The author has stated the project is abandoned and was never meant for production. That is a hard stop, not a caveat.
• You need maintenance, security patches, or PHP-version compatibility. No releases since 2013; modern PHP and Composer constraints will likely bite.
• You need licensing clarity. The NOASSERTION license designation means legal review is required before any use; the effort is not worth it for a replaceable library.
• You need exchange rates, currency conversion, allocation/splitting, parsing, or formatting. moneyphp/money covers this surface and is actively maintained; brick/money is a strong alternative with arbitrary-precision decimal support.
• You are outside PHP. Use the idiomatic equivalent (e.g., Money for Java/JSR-354, dinero.js, py-moneyed, Shopify's money for Ruby) — do not port this package.

How to Pitch It (Stakeholders)

Bottom line: do not adopt this package. Adopt its idea, and use a maintained library instead.

For executives: sebastian/money is a well-known but formally abandoned PHP library — the author's own README tells users to use moneyphp/money instead. Its 726 stars reflect historical influence, not current fitness; the last release was 2013, it carries an unclear (NOASSERTION) license, and it has no listed dependents. Building on it would create a maintenance, security-patching, and legal-review burden in exchange for code we can get from an actively maintained project. Recommended decision: standardize on moneyphp/money (or brick/money if we need arbitrary-precision or multi-currency allocation), and treat sebastian/money as a design reference only.

For engineering: the value is the pattern, not the code. Represent money as an immutable value object holding an integer amount in the currency's smallest unit plus a currency code — never a float, never a bare scalar. Centralize rounding, formatting, and arithmetic in that object so pricing and billing code cannot drift. Use moneyphp/money as the implementation; add a lint or code-review rule banning floats for monetary fields. If we have legacy dependencies on sebastian/money, inventory them now and schedule migration — the surface area is small and the swap is mechanical, so it is cheap insurance rather than a project.

For product: this supports the pricing, billing, and multi-currency roadmap by giving us a concrete, agreed representation of money before those features are specified. It is a low-cost, high-leverage standards decision — one sprint of alignment now avoids a class of rounding and reconciliation bugs later.