The moment billing becomes a real problem
At first, it doesn't seem like one. Early users pay a flat fee, volume is manageable, and the team has more pressing things to focus on: the model, the product, acquisition.
But there comes a point where the business scales (and billing doesn't). Suddenly, every user consumes differently. Some use ten prompts a day, others a thousand. Some burn through credits in seconds, others accumulate them over weeks. The flat fee stops making sense, and the team finds itself building on the fly a system that should have been solved from the start.
Why it's different from traditional billing
In a standard subscription model, billing is predictable: same amount, same day, same customer. Easy to implement, easy to reconcile.
Usage-based billing doesn't work that way. Every consumption event 8a prompt, a token, a credit) is a billing unit. The final amount for the month depends on user behaviour, not a fixed price. That means:
- Measuring consumption in real time with precision
- Aggregating events across the billing cycle
- Managing limits, alerts and caps per plan
- Calculating the final amount correctly before charging
- Reconciling everything without errors
Each of these points seems simple on its own. Together, they form a complex engineering system that has nothing to do with "adding a quantity field to the invoice".
The problem within the problem: when the price changes with consumption
Usage-based billing is already complex on its own. But most AI products don't charge a fixed price per unit, they charge in tiers. From 0 to 100 events, one price. From 100 to 1,000, another. Beyond 1,000, another still.
This adds a layer of complexity most teams don't anticipate: the system needs to know which tier each customer is in at every point in the billing cycle, detect when they cross a threshold, and apply the correct price from that moment, not at the end of the month.
If that doesn't work correctly, the impact is direct on revenue:
- You undercharge because you apply the wrong tier for too long
- You overcharge and generate disputes with customers
- You have no real-time visibility into how much each customer will invoice that month
- Revenue forecasting becomes unpredictable
And when you try to build it internally, this is the point where the "simple events table" becomes a pricing engine with complex business logic that someone has to maintain.
What most teams do: build it internally
The instinctive decision is to build it in-house. "We already have the database, we already manage users, we'll add an events table and calculate it ourselves."
The problem is that events table becomes a billing system. And a billing system has requirements a product team doesn't anticipate: fault tolerance in event tracking, retry logic, real-time plan and upgrade management, integration with payment gateways.
Each of those requirements has a real engineering cost. And most importantly: none of them are differentiating. They don't make your AI product better or faster. They're infrastructure.
