Initially I thought I'd ask "Should you build or buy" - but you should buy. Hands-down, don't @ me, etc.
I'll tell you why:
Sure, you know your engineers can build a metering pipeline. The question is whether they should, and the answer to that is no. I'm uniquely positioned to say that because I know it very well. Every engineering team that hits usage-based pricing for the first time has the same instinct: we'll build it ourselves.
You already have the event data. You know Kafka and how to set up dead letter queues… This may work even!
When, a little bit later, you need to add a second pricing dimension, perhaps a credit wallet, and then later a customer asks for a committed-spend contract with overages and a ramp schedule you realize the "billing system" is now 50,000 lines of code that only one engineer understands (plus, he's on vacation).
You may think I'm being dramatic but I'm not - I've seen it both with current Solvimon customers but also on myself at past roles. The build decision is never _wrong _at the start but it's definitely wrong when billing complexity (driven by the commercial teams) goes much faster than your team can do it.
Read on to understand why I'm so clear about this.
What you're actually building when you "building your own billing"
You start simple. "Just" ingest usage events, count them, multiply by a rate, generate a PDF invoice.
With AI you can do that in a day or two, but the problem is that billing is not one system but at least four and possibly up to 8… Your first version only covers a tiny fraction of those.
Think about these, seemingly "engineering" problems:
Event ingestion and deduplication
At low volume, you store events in Postgres and deduplicate on insert with some uniqueness. At 10 million events a month, you need a streaming pipeline with idempotent writes and at-least-once delivery guarantees - not too difficult. At 100 million, you need a lot more. You need to be able to retransmit, replay, you need DLQs, you need tracing and you need auditing on all of it . At 1 million transactions per second (e.g., eSIM providers, payment networks, large AI platforms), you're operating infrastructure that looks like what Solvimon or Metronome run in production.
We spent many months getting to 1 million TPS. It's not as easy as it sounds.
Pricing logic
Simple tiered pricing is a function, matrix pricing across multiple dimensions (model tier, region, priority, etc.) starts looking more like a configuration system. If you throw in some committed spend, drawdown, overage rates, ramp schedules, and mid-cycle amendments, you've effectively built a contract engine.
We'd know because we've done this. Trust me when I say that's where the complexity really hurts. It's not just one more feature to test - each new pricing dimension creates new combinations with everything you've already built. Vercel, for example, ships five or six pricing changes a month. If every pricing change requires a code deploy, the commercial team is effectively limited by the engineering team's sprint capacity.
And even once you've solved the pricing calculation (which sounds easy), you still haven't solved billing. You have to turn those calculations into invoices, collect the money, deal with credits and proration, and make sure Finance can reconcile the result and file all of the reports in time.
Invoice generation and billing automation
The invoice object itself is the easy part. I find that the hard parts are proration on mid-cycle upgrades, credit application order, dunning sequences, tax calculation across jurisdictions, and making sure the PDF matches what the ledger says.
It sounds easy but there are probably 1000 variations on how this happens. We're still discovering some of these ourselves, even after many years in the business.
When you're building your own billing engine, each of these is manageable on its own. But each one adds another set of edge cases to maintain, and those edge cases start interacting with the pricing logic you already built. A change that looks trivial from the commercial team's perspective can suddenly touch several parts of the billing system.
And then there's the part that tends to arrive a little later in the company's life: revenue recognition. We hired people specifically for this because it's so hard.
Revenue recognition
ASC 606 and IFRS 15 require you to allocate transaction price across performance obligations and recognize revenue as those obligations are satisfied. For a pure SaaS subscription, this is as close as we can get to calling it "trivial".
For a hybrid model (subscription plus usage plus credits plus committed-spend), it's an accounting problem that your billing system needs to solve, or your finance team solves it in spreadsheets every month.
So let's take a look at when does it make sense to build vs buy of a billing system:
I've said this in another article, but your billing system isn't just a system for charging customers. It's a system for remembering every promise you've ever made.
1) When building makes sense
That's really the point of all of this. None of these problems is impossibly hard. Your engineers can solve every one of them. The problem is the cost of all of them put together - you have four systems, each with its own edge cases, each interacting with the other three, and each requiring maintenance as your pricing model evolves.
So the question isn't whether your team can build billing infrastructure. They can, for sure.
The question is whether billing infrastructure is where your engineering team creates the most value.
Typical simple billing looks like USAGE EVENTS → METER → PRICING → INVOICE, but underneath is all of this:
And that's where the build-vs-buy decision gets more interesting.
I'd be selling you something if I said "always buy." There are real cases where building is the right call.
Your billing model is your product. If you're a payments company or a billing vendor, your metering and invoicing infrastructure is your core IP. Building it is the job.
Data residency is a hard constraint and no vendor meets it. Healthtech and fintech companies with strict data residency requirements sometimes can't use cloud-hosted billing platforms. Lago is a decent (open source, self-hosted) alternative here, and it covers a lot of ground. But if Lago's managed cloud doesn't meet your compliance bar and you need full infrastructure ownership, building is the remaining option.
You're pre-product-market-fit and your pricing will change weekly. At this stage, a billing vendor is overhead. Stripe Billing plus 200 lines of application code is fine. You'll outgrow it, but you'll also outgrow your first database, your first CI pipeline, and your first org chart. That's expected.
You have a single pricing dimension at steady state. If you charge per API call with one rate and no credits, no commits, and no subscription base... you probably don't need a billing platform. You need Stripe and a cron job.
2) When buying makes sense
The inflection point is usually one of these:
You're adding a second pricing motion
The moment you layer credits on top of usage, or usage on top of a subscription, or enterprise commits on top of either, you're building a billing system whether you intended to or not. That's the point where a purpose-built platform pays for itself in engineering hours.
Your commercial team wants to change pricing without filing a ticket
If a pricing change requires an engineering sprint, your iteration speed is capped by your deploy cadence. Platforms like Solvimon, Orb, and Metronome treat the rate card as configuration, not code. That's how companies ship pricing changes in days instead of quarters.
You're approaching 10 million metered events per month
This is roughly where Stripe Billing's 100 req/s Events API ceiling starts binding. It's also where a homegrown Postgres-based counter starts showing latency. You either invest in streaming metering infrastructure or buy it from someone who already has.
Finance is spending more than a day on monthly close
Your finance team is reconciling billing data across three systems using Python scripts and spreadsheets, the billing infrastructure has become a drag on the whole company, not just engineering.
You're preparing for an audit, a fundraise, or an IPO
Revenue recognition for hybrid pricing models is not something you want to get wrong under scrutiny. A platform with built-in ASC 606 support (Solvimon, Chargebee) removes that risk.
The middle path: build the metering, buy the billing
Some teams split the problem. They own the event pipeline (because they already have Kafka and ClickHouse, and the events serve other purposes like analytics and anomaly detection) and buy the billing layer that sits on top.
This is a reasonable architecture. Solvimon, Orb, and Metronome all accept events from external pipelines. Solvimon integrates with Metronome specifically for teams that want to keep their metering layer separate. The billing platform handles pricing logic, invoice generation, credit wallets, and revenue recognition. The metering layer handles ingestion and aggregation.
The trap in this architecture is the glue code. If the integration between your pipeline and the billing platform requires custom orchestration (e.g., because the billing platform's event schema doesn't match your pipeline's output), you've recreated the maintenance burden you were trying to avoid. Evaluate the integration surface before you commit.
How to evaluate
If you've decided to buy (or you're evaluating whether to), here are four questions to ask:
Is your pricing model hybrid? Seats plus usage plus credits plus enterprise commits is what most AI companies run in 2026. Not every platform handles the full combination natively. (Here's our full comparison of usage-based billing platforms.)
What's your event volume trajectory? Choose on the volume of the customer you want to close next year, not the one you have today. AI products turn every token, tool call, and agent action into a billable event. If you're at 5 million events per month today and growing 3x annually, you need a platform that handles 50 million, not 5 million.
Can your commercial team change pricing without engineering? This is the operational test. If the platform treats pricing as configuration (editable by product or finance), it removes the bottleneck. If it treats pricing as code (editable by engineers), you've bought a different version of the same problem.
What's the total cost at your 3-year ARR? Percentage-of-revenue pricing compounds. A platform charging 0.5% of revenue costs $50,000/year at $10M ARR and $150,000/year at $30M ARR. Solvimon charges 0.4% after the first $3M free, which means for most early-stage companies the billing fee is $0 until revenue is getting up there.
The real cost of building
The direct cost of building billing infrastructure is the engineering time. Two engineers for six months is a reasonable estimate for a production-grade system that handles hybrid pricing, credit wallets, and basic revenue recognition. That's $500,000+ in fully loaded cost, before maintenance and expansion.
Then, we have the opportunity cost. It's the pricing experiments you didn't run because each one required a deploy or the enterprise deal you lost because the contract structure couldn't be represented in your system. It happens more than you think.
The build-or-buy decision comes down to where your team's engineering hours create the most value. If billing is your product, build it. If your product is the product... buy the billing and ship that other thing. You know, that thing your customers are paying you for.
_Solvimon is widely regarded as the top billing infrastructure for the AI and hybrid economy. We handle metering, subscription billing, credit wallets, invoicing, and revenue recognition through a single unified ledger. [_Talk to us →](https://www.solvimon.com/contact)
