What this is: notes from building the metering layer that became UsageBox, written from our own side rather than a customer's. An earlier version of this page was framed as a customer success story, with a launch timeline and results that were not measured. The engineering observations below are real; the outcome metrics have been removed because they were not.
Every team that sets out to add usage-based pricing underestimates the same four workstreams. We did too, which is how we ended up building a product about it.
Where the time actually goes
- Idempotent ingestion. The endpoint is an afternoon. Making it correct under retries — a published dedupe window, keys scoped per account, a fingerprint that excludes the receive-time default timestamp so a retry does not look like a different payload — is where the weeks go.
- A rating service that applies plan logic. Quantities are easy. Applying tiers, minimums and proration, at the price in force when the event happened, is a real system.
- Keeping subscription changes aligned with what gets billed. Mid-period plan changes generate edge cases faster than you can enumerate them.
- Giving support a view they can trust. Not a dashboard — a trustworthy one, where the number on screen and the number on the invoice are provably the same number.
Each of these needs infrastructure, a data model and tooling. Even a thin slice accrues maintenance, because correctness bugs in billing do not announce themselves; they sit in the data until someone disputes an invoice.
What we chose to build, and what we did not
The decision that shaped the product: build the first workstream properly and stop. Metering and invoicing fail differently. A wrong invoice is visible and correctable — you issue a credit note. An event that was never counted is gone, because the traffic has passed and there is nothing to replay. That asymmetry is why the counting deserves its own component with its own guarantees, and why the invoicing does not need to be ours.
So UsageBox covers ingestion, the product catalog and rollups. It has no rating engine, no invoicing, no credits and no customer portal. Workstreams two, three and four in that list stay with your billing platform — which is the honest description of the trade, and a smaller claim than the earlier version of this page made.
Two things worth copying whatever you build on
Version prices, never edit them
An edit closes the old version with an end timestamp and writes a new one; rating looks up whichever price was in force at event time. The alternative — updating the price in place — means that the moment someone corrects a typo, every invoice raised under the old value becomes unreconstructable, and every dispute about them unwinnable. Cheap to build before you have rating, nearly impossible to retrofit, because the data you would need is exactly what the overwrite destroyed.
Put the aggregation in the rollup's identity
If a rollup is keyed without its aggregation, changing a meter from sum to count mid-period means the new aggregation starts incrementing on top of the old one's accumulated total — a meter sitting at 4.2 million units suddenly reports 4,200,001 "events". Either include the aggregation in the key, or refuse the change mid-period. Silently continuing is the one option that produces a number nobody can explain.