Gmv Bundle Laravel Package

Product Decisions This Supports

• Build-vs-buy for commerce analytics: This bundle remains best framed as a reference implementation of GMV (Gross Merchandise Value) reporting inside Sylius, not a mature product dependency. It helps a PM decide whether to (a) fork and own a thin internal reporting bundle, (b) buy a dedicated BI/analytics tool, or (c) defer the capability entirely until order volume justifies it.
• Sylius version strategy: v1.1.0 adds Sylius 2.3 compatibility. That is a roadmap-relevant data point: if your platform is on Sylius 2.x, the bundle is no longer immediately stale, and a short evaluation is cheap. If you are still on 1.x, this release does nothing for you — check the constraint before spending anyone's time.
• Roadmap sequencing for seller/marketplace metrics: If your roadmap includes vendor dashboards, channel-level revenue splits, or marketplace take-rate reporting, GMV is the canonical top-line metric. This package can inform the data model and admin surface you would need before committing engineering to a custom build.
• Prioritizing which metrics ship first: Use it to pressure-test scope — GMV alone is a vanity metric unless paired with net revenue, refunds, AOV, and channel attribution. The bundle's limited surface is evidence that a "reporting epic" needs more than one bundle to be decision-useful.
• Internal tooling vs. customer-facing features: GMV reporting is typically an internal/ops concern early on. This package supports the decision to keep it as an admin-only, non-SLA capability rather than exposing it to merchants or buyers.
• Spike scoping and estimation: For teams already on Sylius 2.x, spending 1–3 days evaluating this bundle is a cheap way to estimate the real cost of an in-house reporting module before writing a spec.
• Not a differentiator: Still zero stars and zero dependents — no community validation. It should not appear on a competitive-feature list or a customer-facing roadmap slide.

When to Consider This Package

Consider it when:

• You are already running Sylius 2.3+ and need a quick starting point for GMV or order-value aggregation in the admin panel. The v1.1.0 version bump makes this the first release worth evaluating if you are on the current Sylius major.
• You want a read-only reference for how Sylius bundles structure services, entities, and admin routes — useful for onboarding engineers or scaffolding your own bundle.
• You are doing a time-boxed spike and can accept throwing the code away afterward.
• Your reporting needs are single-channel and simple (sum of completed order totals), with no multi-currency, refund, tax, or B2B nuance.

Look elsewhere — or build in-house — when:

• You need production support, SLAs, or a predictable release cadence. v1.1.0 is a single dependency-bump PR from a first-time contributor; that is a positive maintenance signal, not a support commitment. With 0 stars and 0 dependents there is still no community safety net.
• You are on Sylius 1.x. This release explicitly targets 2.3; compatibility with older majors is not established by it.
• You require multi-currency normalization, refunds/chargebacks, tax-exclusive GMV, or channel attribution — expect to write this yourself. Nothing in v1.1.0 changes this gap.
• You need warehouse/BI integration (dbt, BigQuery, Metabase, Looker). A dedicated ELT pipeline is the better buy; a PHP bundle is the wrong layer for analytics at scale.
• You are not on Sylius — the value drops to near zero; the concepts transfer, the code does not.
• You need license/security review rigor: MIT is permissive and fine, but an unmaintained dependency in a payment-adjacent path is an audit finding waiting to happen. The 2.3 bump reduces, but does not eliminate, that concern.

How to Pitch It (Stakeholders)

For executives: Sylius has published a small, MIT-licensed GMV reporting bundle and recently shipped v1.1.0, which adds Sylius 2.3 compatibility. It is still not a vendor product — no user base, no support commitment — but it is a useful, low-cost reference for how we would surface top-line marketplace revenue inside our existing Sylius admin, and it is now current with the Sylius major we would build against. Recommendation: fund a short evaluation (days, not weeks) to inform a build-vs-buy decision on commerce analytics; do not treat it as a production dependency or a customer-facing feature.

For engineering: Treat sylius/gmv-bundle as a scaffold, not a library. v1.1.0 is a single Sylius 2.3 upgrade PR from a new contributor — useful because it confirms the codebase compiles against the current major, not because it signals anything about feature depth. Fork or vendor it, pin the commit, and expect to own all of it — currency handling, refund netting, and query performance at scale are almost certainly ours to solve. If we adopt any of it, isolate it behind an internal reporting interface so we can swap in a real analytics backend later without touching admin controllers.

Bottom line: High learning value, low adoption value. The 2.3 update keeps it evaluable rather than stale, which slightly strengthens the case for a cheap spike — it does not de-risk a launch.