Prices Combinations Laravel Package

Product Decisions This Supports

• Pricing model architecture: atomic vs. composable prices. This package forces the question of whether a price is a single stored number or a combination of parts (base price + options/modifiers). That's a foundational catalog decision — it's cheap to answer now and expensive to retrofit once orders, invoices, and reporting reference concrete price records.
• Build vs. buy for pricing math. Money handling — currency, rounding, VAT, component aggregation — is high-bug-density code that looks trivial and isn't. Adopting an extension of an existing money library is usually cheaper than owning that math, provided the dependency is sound (see next section).
• Admin tooling and merchandising autonomy. The bundled "Price property" (a form input for authoring a price) is the real PM lever: it lets catalog/ops staff create and edit prices without an engineering ticket. Every such change you can hand to ops is a recurring support-cost reduction, not a one-off feature.
• Roadmap sequencing for configurable commerce. If the roadmap includes configurable products, bundles, add-on options, quote builders, or B2B price lists with selectable terms, this is an enabler dependency — it should be scheduled before the customer-facing surface, not alongside it.
• Representative use cases: product configurators (base + selected options), bundles/kits priced from components, quote and estimate builders, subscription add-ons and seat-based tiers, and any catalog where the same price components are reused across many sellable SKUs.

When to Consider This Package

Adopt when:

• You are already on mibo/prices (or are prepared to adopt it). This is an extension, not a standalone — it inherits that package's abstractions, conventions, and lifecycle risk. Adopting it standalone means adopting two dependencies at once.
• Your domain genuinely has combinable price parts — reused components, configurable products, or option-based pricing. If every SKU has exactly one price, you don't need this.
• You are on Laravel/PHP, happy with an MIT-licensed package, and can pin the version and vendor the source so a missing release or breaking change can't block a deploy.
• The catalog is small-to-moderate and internally authored, where a form property for price entry is sufficient and you don't need approvals, audit trails, or scheduled price changes (you'd build those on top).

Look elsewhere when:

• Community validation matters to you. 0 stars and 0 dependents means no external users have stress-tested it, no Stack Overflow corpus exists, and there is no signal on maintenance cadence. Treat it as an internal-grade utility, not a vetted OSS dependency. Budget for reading the source rather than the docs.
• You need tax/currency correctness at enterprise scale. For multi-jurisdiction tax, use a tax engine (Avalara, Stripe Tax); for full commerce, use a platform (Sylius, Lunar, Shopify) rather than assembling a pricing layer from micro-packages.
• You are not on the mibo ecosystem and would be adding it solely for this. The dependency chain risk outweighs the benefit; write a small, well-tested value object instead.
• You need SLAs, security patching guarantees, or vendor support. None of that exists here.
• You need it to integrate with a specific admin stack. The "Price property" implies a particular form/UI context — verify framework and version compatibility (especially Filament/Nova majors) before it lands in a plan.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) PHP extension that unblocks configurable pricing — bundles, options, and add-on products — without us writing and maintaining money math ourselves. The strategic value isn't the package; it's the catalog flexibility it enables and the ops hours it saves by letting merchandising edit prices directly. The risk is equally small and concrete: the project has zero public adoption, so we treat it as third-party code we own the risk on — we pin the version, vendor the source, and keep it behind our own pricing interface so it's replaceable in days, not quarters. Recommendation: pilot on one configurable product line, measure ops self-service rate, then decide on broader rollout.

To engineering: Adopt only if we're already committed to mibo/prices; otherwise this doubles our dependency surface for a narrow win. Two guardrails: (1) wrap it behind our own PricingService/value-object boundary so the package never leaks into domain code, and (2) write characterization tests around rounding, currency, and component aggregation before we depend on it — that's where the bugs will be, and there's no community test corpus to lean on. Estimate the integration as "small code, meaningful diligence" — a day to wire up, longer to verify.