Product Decisions This Supports
- Usage-based and hybrid pricing models. v0.19.0 adds an operator-facing path to report a tenant's per-period usage. Combined with a quota/limit concept already implied by the
quota namespace, this moves the package from pure enforcement ("block at limit") to metering ("show what was consumed, by whom, in which period"). That is the prerequisite for usage-based tiers, overage billing, and credit systems.
- Build vs. buy on metering. Period-scoped usage aggregation is deceptively expensive to build correctly: period boundaries and timezones, reset/rollover semantics, idempotent event ingestion, backfill and correction, and per-tenant read performance. A package that ships this as a first-class primitive is a credible argument to buy/adopt rather than build in-house.
- Roadmap sequencing. Because reporting now exists alongside enforcement, the natural next increments are: tenant-facing usage dashboards, threshold notifications (e.g. 80% of quota), overage/dunning hooks, and plan/entitlement assignment. Treat reporting as the gateway feature that unlocks the whole monetization surface — plan for it in the roadmap rather than treating it as a standalone.
- In-product expansion motions. Per-period usage data is what powers upsell prompts ("you've used 92% of your quota — upgrade"), fair-use policy enforcement, and support conversations. This is a customer-facing capability, not just an internal ops tool, so it belongs in the product spec, not only the platform backlog.
- Operator/back-office tooling. The framing "let an operator report" suggests an internal control-plane use case: support and finance staff reconciling disputes, granting credits, or auditing consumption without engineering involvement. That is a distinct buyer from the end-tenant dashboard and should be scoped separately.
When to Consider This Package
Consider it when:
- You are building a B2B/multi-tenant SaaS on Laravel and need per-period limits (API calls, seats, storage, credits, generations) with the ability to report consumption, not merely reject requests at the cap.
- You want metering to live in your own database and domain model, rather than pushed into a third-party billing provider's event stream — i.e. you need the quota state to be queryable and joinable to your own tenant/account tables.
- You are Laravel-native and value a package that follows framework conventions (service provider, config, migrations, Eloquent) over a standalone service with an SDK.
- You are pre-revenue or pre-GA on pricing and can absorb API churn in exchange for not building metering from zero.
Look elsewhere when:
- You need billing, invoicing, proration, tax, and dunning. This package reports and enforces usage; it is not a billing system. Pair it with Stripe/Laravel Cashier or Lago rather than expecting it to close the loop.
- You need 1.x API stability. At v0.19.0 this is pre-1.0: per semver, minor releases may contain breaking changes. If you cannot pin and schedule upgrades, that is a real cost.
- You have high-volume, low-latency ingestion (millions of events/hour, sub-10ms hot-path checks). Purpose-built meters (OpenMeter, Lago, Metronome) or a Redis-backed counter layer will outperform an Eloquent-centric approach; you may still use this package for the entitlement/reporting layer and delegate counting.
- You need a managed SaaS with an SLA and vendor support. This is community OSS with a small contributor base.
- Your quotas are trivial — a single hard-coded counter per tenant does not justify the dependency.
Adoption criteria to verify before committing: that the reporting API is read-only and safe to call from request paths; that period semantics (timezone, reset, partial periods) are configurable and documented; and that reported usage and enforced usage are derived from the same source of truth. The release note alone does not confirm these — review the PR and the surrounding quota code before treating this as production-ready.
How to Pitch It (Stakeholders)
For executives: We are evaluating a Laravel package that gives us quota enforcement plus per-tenant, per-period usage reporting. The reporting piece is the commercially interesting one — it is what lets us show customers what they have consumed, prompt them to upgrade at the right moment, and eventually bill for overages. Building this ourselves means owning period boundaries, resets, and reconciliation logic, which is a multi-sprint effort with a long tail of correctness bugs. The trade-off is maturity: the package is at v0.19.0, pre-1.0, so we should expect occasional breaking changes and budget for upgrade work. Recommendation: adopt behind a thin internal interface, pilot on one plan tier, and revisit once it reaches 1.0 or we outgrow it.
For engineering: This is a Laravel-native quota package adding an operator-facing usage-reporting endpoint for tenant consumption within a billing period. It is early-stage (0.x, active development — v0.18 to v0.19 within recent history), so the integration principle is isolate, don't scatter: put all calls behind our own UsageMeter/Entitlements interface, pin the exact version in composer.json, and keep our domain code unaware of the package's types. Confirm before adoption: whether reporting queries are safe on the hot path or need a cached/materialized layer; whether period/timezone resets are configurable; and whether the reported number and the enforced number share one source of truth. It does not replace billing — plan on Stripe/Lago alongside it. Net: a reasonable accelerator for metering, contingent on us owning the abstraction boundary.