Statamic Cargo Laravel Package

Product Decisions This Supports

• Build vs. buy for commerce: Cargo is a first-party-style e-commerce addon for Statamic, so the real decision it informs is "extend our existing Statamic site with native commerce" vs. "replatform onto Shopify/Medusa/custom Laravel." This release is evidence for the maintenance health half of that decision, not the feature-set half.
• Roadmap sequencing: v1.15.1 is pure defect remediation in the money-adjacent paths — stock event dispatch for variants, tax class validation, and variant tax class resolution. That signals the product surface (variants, stock, tax) is stable enough that the maintainer is polishing edge cases rather than shipping new modules. Plan roadmap bets on top of a maturing core, not a shifting one.
• Operational risk / launch readiness: If your launch depends on per-variant inventory accuracy or tax correctness on variants, these three fixes are directly load-bearing. Pre-1.15.1, a variant of a product without a tax class could return an unexpected class (mis-taxed orders), and stock events could fire against the parent product rather than the variant (oversell/drift). Validate that your catalog's tax-class configuration matches the new "empty is valid, no class means no class" semantics before go-live.
• Use-case fit: Confirms fitness for small-to-mid catalogs with variants and physical/digital goods sold through a Statamic front end — the classic "content-led brand that also sells" scenario. Nothing here expands scope into marketplaces, multi-warehouse fulfilment, or complex jurisdictional tax.
• Vendor dependency posture: A single external contributor (DanielDarrenJones) authored all three fixes alongside the maintainer, with Dependabot handling CI hygiene. Useful input for the "bus factor / support contract" line item in any vendor risk register.

When to Consider This Package

Consider adopting when:

• Your site is already on Statamic (v4/v5) and Laravel, and content editors own the catalog — Cargo keeps products as native entries rather than a bolt-on admin.
• Catalog complexity is modest: simple products plus variants, stock counts at product and variant level, a handful of tax classes, standard shipping.
• You want to own checkout, tax, and fulfilment logic in your own codebase rather than pay platform fees or fight an app ecosystem.
• Your team is comfortable reading Laravel source and writing tests around commerce flows — you'll want regression coverage for stock events and tax resolution specifically.
• You can absorb patch-level upgrades on a normal cadence; v1.15.1 is a non-breaking patch with no migration or config changes.

Look elsewhere when:

• You need multi-currency, multi-region tax engines, or automated tax filing — Cargo's tax classes are configuration, not compliance.
• You need a mature app/integration ecosystem (ERP, 3PL, POS, subscriptions at scale), or you want commerce hosted and vendor-supported with an SLA.
• Catalog is large or merchandising-heavy (thousands of SKUs, complex promotions, B2B tiered pricing) — you'd be building much of that yourself.
• You're not on Statamic. The value proposition is the native integration; standalone, it's a thinner proposition than dedicated commerce packages.
• You need predictable release transparency around breaking changes — pin versions and read changelogs; treat the changelog as your upgrade gate.

How to Pitch It (Stakeholders)

To executives: Cargo lets us sell directly from the Statamic site we already run, so commerce becomes an extension of existing infrastructure instead of a replatform, a second CMS, or a monthly platform fee. The v1.15.1 release is a maintenance patch — no new features, no breaking changes, nothing to migrate — and it specifically hardens two things that cost real money when wrong: per-variant stock accuracy and correct tax treatment on variants. Read it as a signal that the core is stabilising and that the maintainer is fixing correctness bugs in revenue paths promptly. The trade-off to accept knowingly: this is a small-team, self-supported package, so we carry the operational responsibility for upgrades and testing rather than outsourcing it to a vendor.

To engineering: Low-risk upgrade — patch release, no migrations, no deprecations, no API changes. Three behavioural fixes worth regression-testing after you bump: stock events now check the variant's stock when dispatching for variants (verify no double-decrement and that listeners receive the right subject), an empty tax class field now passes validation (previously a save-blocker; check any form or import that relied on the old strictness), and variants of products without a tax class now return no tax class rather than an inherited/fallback one (audit any pricing, invoice, or reporting code that assumed a non-null tax class). CI dependency bumps are housekeeping. Recommended posture: pin the version, add or extend feature tests around variant stock and tax resolution, and keep a changelog watch for the first minor that introduces breaking changes.