Billing that reconciles to the cent.
We build the metering and billing core most SaaS teams bolt on too late: count every unit, price it against the plan, and hand finance an invoice that ties out. This is how ours runs.
Drag it. At 62,000 calls, Starter is cheapest, and the invoice on the right rebuilds itself line by line.
Priced the way buyers actually decide.
Same usage as the slider above, priced against every tier. The math is built so the right plan wins at the right size, no bait pricing.
- 20,000 API calls
- 5 seats
- 20 GB storage
- 100,000 API calls
- 20 seats
- 100 GB storage
- 500,000 API calls
- 100 seats
- 500 GB storage
One event, all the way to a billable line.
The same path, every time. No cron doing arithmetic in the dark, no month-end spreadsheet. Each step is replayable, so a wrong number is a bug you can find, not a mystery.
Metering that can't double-count.
Every event carries its own id, and the write is an upsert on that id. A network retry, a replayed queue, a duplicate webhook: all land on the same row. That's the one property that makes the invoice trustworthy.
1// a usage event is keyed by its own id, so a retry or a2// replay lands on the same row and never bills twice3export async function meter(event) {4 await db.usage.upsert({5 where: { id: event.id }, // idempotency key6 create: {7 id: event.id,8 account: event.account,9 meter: event.meter, // api_call, seat, gb10 quantity: event.quantity,11 period: event.period,12 },13 update: {}, // seen it already, do nothing14 });15}Billing your finance team can sign off on.
Metering that can't double-count, plans that price themselves, and an invoice where every line traces back to an event. Ready the day you turn billing on.