Two years ago the typical company on Solvimon ran two pricing surfaces and now it's five.

While we added a lot of customers in that window, it's not just that we're selling to more complicated companies now, but our past customers, the ones who are just now adopting AI also went from two to five. New accounts arrive more complicated and existing accounts get more complicated, and both lines move at roughly the same rate.

It's what a business growing up with AI looks like because they previously had seats and now they're trying to grab that sweet sweet up-front credits with commits. As new AI features come from across the orgs, they too understand that because per-token would terrify the user credits have to be there. A partner wants to resell, which needs its own rate card.

And then later enterprise deal needs a minimum with overage on top.

Every one of those was the right call, because all that matters is that you earn revenue that wasn't there before. Each of these arrives one decision at a time which is the only way pricing changes ever happen (those big projects rarely succeed).

AI-led Growth (ALG) does indeed make pricing more complicated whether you plan for it or not. What you actually get to decide is whether the billing layer can absorb the next surface without turning it into a project.

So what is a pricing surface?

I'd say it's one place where money gets decided, typically a mechanism (not a price-point).

For example:

• A seat plan is a surface

• A metered API

• A credit wallet burning down at different rates per model

• A negotiated contract with a commit and an overage

• A partner rate card

They're separate because each has its own unit, its own cycle, and its own rule about what happens at the boundary and how they behave on upsells, cross-sells, etc. We often prorate seats but we accrue usage and expire credits.

Doesn't really matter how many prices you have - it really matters how many of those mechanisms have to agree with each other on one invoice to demonstrate your value to your customers.

Why does it get hard so fast?

Oh, because the surfaces interact, and the interactions are where the bugs live.

This is why most people should NOT build their own billing systems.

A customer with a seat plan, a credit wallet and a commit generates a question every cycle. Does their usage draw down credits first, or count toward the commit? If they top up mid-cycle, does that change the commit calculation? They add seats on the 12th, so does the included allowance prorate, reset, or carry?

I've written about this before because every combination needs an answer, and the answers are commercial decisions in a technical trenchcoat. Someone in the business decides. Someone in engineering encodes it. Someone in finance recognizes the revenue, which is a third opinion.

Two surfaces have one interaction but 5 have 10 at least and that's why the whole story of why billing gets bad at exactly the moment the business gets good.

Keep billing out of your events

Before any of the pricing logic, the thing that quietly decides your ceiling is what you put in a usage event.

The rule we ended up writing into our own docs is: keep billing logic out of your events. Send one event per action, with facts only. Who did it, when, what dimensions it carried. The moment you send something like {"total_api_calls_this_month": 41203} you've moved pricing into your application, and every future pricing change becomes an engineering ticket instead of a config change.

The three mistakes that cost the most, all of which we've watched happen:

• Pre-aggregating per billing period: now you have no more cost visibility

• One meter per price point instead of using meter properties: you can't restructure tiers without creating new meters and backfilling.

• Sending seat changes as +1 and −1 deltas. When one lost event on a delta model corrupts the seat count for the entire period, and you won't find out until someone disputes something big….

Do you need our metering?

Not necessarily, and it's worth saying I guess.

One of our customers meters on Metronome and bills on Solvimon. Metronome ingests their events at a volume where it's the strongest engine available, and hands us aggregated usage. We handle rate cards, wallets, subscriptions, commits and the invoice. We didn't try to talk them out of it. We support importing Billable Metrics from Metronome directly as Solvimon meters, which exists precisely because this is a reasonable thing to want.

When metering is genuinely the hard part - that makes sense. Billions of events a day against one consumption rate is a metering problem, and the billing layer is the easy half in that case.

Where it makes less sense for us is where the billing is the complex part. Most companies we work with can meter fine with our 1,000,000 TPS system.

How do you choose a metering and billing solution?

I'd look at it this way:

1. How many pricing surfaces will you have in two years?
   Not today. If the honest answer is one, you have plenty of good options and should pick on developer experience and price, where Stripe Billing is very hard to beat. If it's three or more you're choosing an architecture, and the real question is whether those surfaces share a ledger or get stitched together afterwards.

2. Where does your complexity actually live?
   Ingestion volume and rating logic are different problems with different answers. Count your events per day, then count your distinct pricing rules. Whichever number is scarier tells you which layer to optimize for. Teams buy a metering engine to solve a rating problem more often than you'd think, and then still have the rating problem.

3. What happens when you change a price?
   Make the vendor walk you through the sequence. If it involves a support ticket, a professional services engagement, or a release train, you now know how often you'll really change pricing.

For what it's worth, our answer to the third question is versioned plans.

Changing a price means creating a new plan version rather than editing the live one, so the old version keeps invoicing correctly for everyone still on it. Enterprise exceptions ride on top of that as schedule-scoped overrides: a negotiated rate for one customer copies the price onto their schedule and leaves the shared plan alone, so one deal can't drift into everyone else's invoice. Commits sit at four levels (invoice total, product total, product item total, product item volume), with discounts and markups layered on.

That's more plumbing detail than a positioning post usually carries. It's also the actual answer to "can this thing hold five surfaces," which is the question underneath the question.

What we're watching

The amount of billing and pricing surfaces moved way faster than volume originally and we weren't expecting that. We wrote about usage-based billing growing 7x in a year. Companies are adding usage next to seats, then credits next to usage, and keeping all of it.

Which means what I'm tracking now is how many models a company can run before the billing system becomes the reason they stop adding them. Every pricing surface a company can't add is revenue it decided not to go after, and that decision rarely gets recorded anywhere.