We thought subscription billing was hard—until we tried utility-style billing
We’ve been building a subscription billing product for a while now.
Recurring plans, upgrades, proration, invoicing — the usual stuff.
Then we started working on something different:
utility-style billing (usage-based, metered, variable invoices).
And that’s where things started to break.
What we assumed (and got wrong)
At first, we thought:
“This is just another pricing model”
“We can extend our existing billing logic”
“Usage-based = subscriptions + overages”
That assumption didn’t last long.
What actually changed
Once we got into it, utility billing had very different requirements:
-
Billing depends on raw usage data
Not plans. Not tiers.
You need accurate, continuous metering. -
Invoices are unpredictable
With subscriptions, users know what they’ll pay.
With usage-based, bills can fluctuate a lot — which creates trust issues if not handled well. -
Timing becomes tricky
When do you bill?
How often do you aggregate usage?
What happens if data is delayed?
- Overages aren’t “edge cases”
They are the pricing model.
The biggest shift
We realized this wasn’t just a feature.
It required rethinking:
How we store usage data
How pricing is calculated
How invoices are generated
How to make billing transparent to users
What we ended up doing
Instead of forcing it into our existing system, we had to:
Treat usage as a first-class input, not an add-on
Build flexible rating logic (not fixed plans)
Rethink how invoices are structured
Focus more on clarity for end users, not just accuracy
We recently rolled this into a dedicated utility billing approach.
If you’re curious, here’s what we built:
https://saaslogic.io/solutions/utilities
Curious how others are handling this
If you’re building anything usage-based:
Are you handling billing in-house or using tools?
How do you deal with delayed or inconsistent usage data?
Do your users understand their bills or do you get constant support questions?
Would love to hear how others are solving this.
This is a classic shift most billing systems underestimate — subscription logic doesn’t translate cleanly once usage becomes the primary signal.
The hardest part isn’t metering itself, it’s the trust layer around variability — users don’t mind fluctuating bills as much as they mind not being able to predict or explain them.
I’m curious — how are you thinking about surfacing ‘why this bill changed’ at the invoice level? That transparency layer feels like it makes or breaks adoption in usage-based models.
I’ve also seen some builders pair this with small, high-intent usage experiments (fixed entry, capped bursts, strong upside) to validate pricing sensitivity before scaling — surprisingly effective for reducing billing-related churn later.
Feels like that could complement what you’re building in the utilities layer. Have you explored something like that?