26 July 2026
Show HN: HUME — usage metering without the billing bloat
We built a headless metering engine so pricing logic is not trapped inside your payment provider — and nobody takes a cut of your revenue.
Most “usage-based billing” products are really billing products: hosted UI, opinionated plans, and a quiet percentage of your revenue. That works until you need a weird tier, a custom classify rule, or a PSP that is not on their shortlist.
We wanted the opposite shape: metering and pricing as infrastructure, payments as a plug.
The split that matters
There are two problems that get mashed together:
- What did the customer consume, and what do we owe?
- How do we move money?
(1) is domain logic. (2) is Stripe / Adyen / whatever. If you encode (1) inside (2), every pricing change becomes a PSP migration risk. If you encode (2) inside your app, every product change becomes a finance ticket.
HUME sits on (1): tenants, users, metrics, plans, subscriptions, usage, invoices, webhooks. You keep (2) in your stack. We do not sit in the money path and we do not take revenue share.
What “headless” means here
- HTTP + StatsD for ingest (domain events when you care; UDP when you care about volume)
- Plans as data — JSON for the common case, Luau when you need programmable pricing / classify
- Event-sourced ledger per tenant (Go + Badger) so the bill is replayable, not “whatever the dashboard said last Tuesday”
- Webhooks out, so your app owns dunning, emails, and charge orchestration
You do not embed our UI in your product. You call an API. That is intentional.
Opinions we actually have
Zero revenue share. If metering is infrastructure, pricing it like a payment facilitator is a category error.
Limits ≠ alerts. Hard reject caps and soft threshold webhooks are different tools. Mixing them into one “quota” blob makes bad products.
MTU and overage should be boring. Deduped monthly tracked users, included units, tiered overage — the unglamorous stuff that breaks when you hand-roll it at 2am.
Dogfooding is allowed to be ugly. We bill HUME projects with the same engine. The interesting part is not the cleverness; it is that the API we sell is the API we run.
What this is not
Not a Stripe Billing clone. Not a tax engine. Not a CRM. Not “AI that invents your price.” If you need a full finance suite, use one — and still keep metering somewhere you control.
Try it
Docs: hume.run/docs
API: hume.run/docs/api
Happy to answer uncomfortable questions in the thread: multi-tenant isolation, StatsD semantics, Luau sandboxing, invoice lifecycle, or why we refused revenue share.