Better Units Laravel Package

Product Decisions This Supports

• Build vs. buy on conversion logic. Unit conversion looks like a one-line multiply until you hit temperature offsets (C↔F is not a ratio), imperial/metric rounding drift, compound units (kg·m/s², price per oz vs. per kg), and display-vs-storage precision. A small, MIT-licensed converter lets you buy that correctness instead of owning a table of magic numbers scattered across the codebase.
• The storage-model decision. The most valuable thing a converter package forces is the conversation: do we store a canonical base unit and convert at the edges, or store whatever the user typed? This package supports the former (convert on read/write, present in user's locale unit) and gives you a concrete tool to prototype it before committing schema.
• International and multi-vertical feature scoping. Relevant surfaces: marketplace listings priced/weighed in seller-local units, shipping-rate and dimensional-weight calculation, nutrition and recipe scaling, fitness/health tracking, construction and materials quoting, and any catalog that must render in both metric and imperial. Each is a discrete roadmap item this package de-risks.
• Roadmap sequencing. Because it's dependency-light and framework-agnostic, it can be adopted incrementally per feature rather than as a platform migration — useful when you want unit-awareness on one screen without a cross-team initiative.
• Risk posture on a third-party dependency. With 2 stars and 0 dependents, the product decision this drives is architectural, not just functional: adopt it behind your own interface so the vendor choice is reversible. That's a cheap insurance premium and a decision worth making explicitly now rather than during an incident.

When to Consider This Package

Consider it when:

• You have real, recurring multi-unit requirements across regions or verticals — not one hardcoded factor.
• You want a narrow, MIT-licensed, framework-agnostic converter rather than a heavyweight measurement framework, and are comfortable reading ~a few hundred lines of source before trusting it.
• Your team can wrap it behind a domain-owned contract (e.g. a UnitConverter interface bound in a Laravel service provider you write yourself — this package ships no Laravel integration).
• You're prototyping whether unit-awareness belongs in the domain model at all, and want a low-commitment spike.

Look elsewhere when:

• You need maintenance SLAs, a broad unit registry, or a large community to lean on — the adoption signals here (stars, dependents, recency) don't support that yet.
• You need locale-aware formatting, significant figures/uncertainty, or currency conversion. Currency is not a unit problem — rates are dynamic and belong to a rates service.
• Your requirement is genuinely one or two fixed factors. Hardcode them; a dependency is overhead.
• Due diligence before adopting either way: verify test coverage and CI, last commit date and supported PHP versions, the actual unit coverage list, handling of temperature offsets and compound units, and rounding/precision behavior. If any of these are thin, vendor or fork it rather than pull it from Packagist.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) library for converting units of measurement. The business case isn't the library — it's the class of bugs it prevents: wrong shipping weights, mis-rendered international listings, and pricing shown per-ounce when the customer expects per-100g. Those are refunds, support tickets, and blocked market expansion. Cost is near zero and the risk is contained because we'd hide it behind our own interface and can swap it out. Recommendation: a 1–2 day spike on a single low-risk surface, then a go/no-go.

To engineering: Framework-agnostic PHP converter — no service provider, no Laravel coupling, so we bind it ourselves and keep domain code free of vendor types. Treat it as an implementation detail of our own UnitConverter contract; store canonical base units, convert at the boundary. Given its early stage (minimal adoption), plan to vendor or fork and own the test suite. If the spike shows gaps in unit coverage or precision handling, we fall back to a more established library or a small in-house table — the interface makes that a swap, not a rewrite.