Prices Laravel Package

Technical Evaluation

Architecture fit

• mibo/prices presents as a conventional Laravel package (Composer-installed, service-provider registered, config-publishable) targeting price/currency handling. That shape fits cleanly into a Laravel monolith or modular monolith where pricing is a domain concern rather than a cross-cutting utility.
• The critical unknown is where it sits on the value-object spectrum. If it supplies immutable Price/Money objects with a cast for Eloquent attributes, it is a genuine architectural improvement over float columns and ad-hoc formatting helpers. If it is a thin set of Blade helpers and accessors, it is cosmetic and will not survive contact with tax, discount, or multi-currency requirements.
• Given the opportunity: 8.69 signal alongside a 0.3 composite score, the most defensible reading is: real gap in the Laravel pricing/money niche, but this package is not yet the thing that fills it.

Integration feasibility

• Mechanically trivial: composer require mibo/prices, auto-discovery, publish config. A developer can have it running in an afternoon.
• Commercially non-trivial: 0 stars, 0 dependents, and a single namespace/repo mismatch (mibo/prices hosted at 4513/prices) means there is no observable production usage anywhere. We would be the first adopter, and effectively the QA function.
• MIT license is permissive and removes legal friction — but it also means no vendor obligation, no support contract, and no roadmap influence.

Technical risk

• Financial correctness risk (high). Price handling fails silently. Float storage, banker's-vs-half-up rounding, currency exponent assumptions (JPY=0, KWD=3), and tax-inclusive vs exclusive semantics are the failure classes that reach customers and auditors. Without a visible test suite covering these, we cannot assume correctness.
• Bus factor risk (high). Effectively one maintainer, no dependents, no issue history to mine. Any Laravel or PHP minor-version bump can strand us.
• API stability risk (medium-high). Pre-1.0 packages with zero consumers routinely rename or restructure core types.
• Supply-chain risk (low-medium). Small dependency surface is good; unmaintained transitive dependencies are the usual vector — audit composer.lock before committing.

Key questions

1. Does it store minor units as integers, or decimals/floats? What does the Eloquent cast do on write?
2. Does it wrap moneyphp/money or brick/money, or reimplement arithmetic? Reimplementation is a red flag.
3. Which Laravel and PHP versions are in composer.json constraints, and is there a CI matrix?
4. Scope: storage/formatting only, or does it model price lists, tiers, tax rates, and currency conversion?
5. Is there a test suite, and does it cover rounding boundaries and multi-currency?
6. What is the relationship between the mibo namespace and the 4513 GitHub owner — fork, rename, or personal project?
7. Any published release history, changelog, or tagged versions?

Integration Approach

Stack fit

• Fits any Laravel application with a catalog, subscription, or invoice surface. Poor fit for a polyglot stack where pricing logic must be shared with a non-PHP service — a value-object package does not travel across language boundaries, so the canonical price model would still need to be an API contract or database convention.
• Confirm PHP version alignment before anything else. A package pinned to an older Laravel major is a non-starter regardless of feature quality.

Migration path

• Do not wire it directly into models or Blade templates. Introduce an internal PricingService / MoneyFormatter interface in our own namespace and make mibo/prices one implementation behind it.
• This adapter boundary costs roughly a day and buys us the ability to swap to brick/money or moneyphp/money — both mature, widely adopted, and audited by thousands of dependents — without touching call sites.
• For existing data: map current decimal(10,2) columns to whichever representation the package expects in a migration-with-backfill, not an in-place type change. Run both representations in parallel for one release cycle and reconcile.

Compatibility

• Verify database column types against the package's cast expectations; a mismatch here produces rounding drift that only surfaces in production totals.
• Check JSON/API serialization — if prices are exposed to clients, the package's cast may change the wire format and break consumers.
• Confirm behavior under Laravel's queue and Octane workers if pricing is computed in background jobs (state leakage in static caches is a known class of bug in smaller packages).

Sequencing

1. Source review and dependency audit (1–2 days) — read the code, not just the README.
2. Correctness spike against a written table of rounding and currency edge cases (2 days).
3. Build the adapter interface and implement it with the package (2–3 days).
4. Pilot on a read-only, low-blast-radius surface — catalog display or internal admin — never checkout or invoicing first.
5. Finance/product sign-off on rounding and tax semantics.
6. Expand to transactional surfaces, or replace the implementation behind the adapter if the spike disappoints.

Operational Impact

Maintenance

• Assume we own this code. Budget for vendoring or forking at adoption time rather than after an incident. A fork under our org with CI, a test suite, and pinned Laravel constraints converts an unmaintained dependency into a controllable one — and is the only way this package becomes viable for financial data.
• Track it in the dependency register with an explicit "no upstream support" flag and a scheduled quarterly review.

Support

• Community support is effectively nil: no dependents means no Stack Overflow corpus, no GitHub issue history to search, no peer experience to draw on. Internal documentation of our usage and the edge cases we validated becomes the support asset.
• Single-maintainer packages also mean response time to a security advisory is unbounded. Have a patch-and-vendor runbook ready.

Scaling

• Computational scaling is a non-issue — price arithmetic is nanoseconds. The scaling concern is correctness at scale: rounding errors compound across line items, and a one-cent drift in a per-unit price becomes material at volume.
• Operational scaling means bulk price updates and currency additions. Confirm the package handles adding a currency with a different exponent without a schema change.

Failure modes

• Silent rounding error — wrong totals discovered at reconciliation or audit. Highest severity, lowest detectability.
• Currency mismatch — arithmetic across currencies without an explicit guard.
• Abandonment — a Laravel major upgrade blocks us and no patch is coming; forces emergency fork or rewrite.
• Breaking change on minor bump — zero consumers means no backward-compatibility pressure on the maintainer.
• Mitigation for all four is the same: adapter boundary, vendored fork, and a test suite we own.

Ramp-up

• Developer ramp-up is under a day — the API surface of a Laravel price package is small and idiomatic.
• Domain ramp-up is the real cost: engineers and product must agree on rounding rules, tax-inclusive display conventions, and the minor-unit storage contract before code lands. That conversation is worth having regardless of which package we choose, and it is the actual prerequisite for adoption.

Recommendation Do not adopt as a production dependency in its current state. Run the source and correctness review as a scoped spike; if the package is a competent wrapper over a mature money library, fork it, pin it, and adopt behind an adapter. If it reimplements arithmetic or stores floats, close the evaluation and standardize on brick/money — the opportunity signal is real, but this package has not yet earned the trust that financial code requires.