Open source changed how we build infrastructure. Operating systems, containers, orchestration tools, and observability frameworks are open by default. The application layer, especially billing, hasn't caught up.
That shift is happening. More services like billing, analytics, and authorization are being rebuilt with openness and flexibility in mind. Billing is one of the most overdue.
Billing Is Not Just Another Integration
Many teams treat billing as something to wire up at the end. But billing shapes how you package, price, and sell. Once it's in place, it becomes foundational.
It determines how fast you can iterate on pricing, how complex your deals can be, and how closely product and revenue stay aligned.
For example, your product catalog will evolve with your business:
| Stage | Challenges | Source of Truth For Product Catalog |
|---|---|---|
| Early users | Sending manual invoices and payment links to customers with variable pricing | Payment Provider |
| Launching self-service | Self-service subscription with unified plans across customers | Code and Billing provider |
| Scaling to 250 customers | Historical versions of self-service pricing and custom sales deals | Conditional code and Billing Provider |
| Upsells to enterprise contracts | Self-service + enterprise deals with Salesforce CPQ, invoicing, commitments | Code, Billing Provider, and CRM |
As your company grows, you have now gone through many stages of functional requirements. There will be many customers with different pricing models, and your product catalog is spread all over the place: in your code, billing platform and Salesforce.
Where Closed Billing Falls Short
1. Billing logic spreads across your stack
In the early stages, you might hardcode Stripe APIs. Then usage-based pricing gets added. Then CPQ. Eventually, you're managing pricing logic across your billing provider, backend, and CRM.
You chase alignment between Stripe, product code, and Salesforce. Custom logic piles up. No one knows where the source of truth is.
2. Migration becomes a massive project
Billing gets tightly integrated. Switching vendors becomes painful. When platforms raise prices or hide features behind higher tiers, you're stuck.
Open-source systems give you control. You can inspect the code, change it, extend it. You can move on if the vendor no longer fits.
3. Innovation slows down
Billing connects directly to revenue. Any change to pricing, packaging, or deal structure affects engineering. If your system is rigid, your business is too.
At Netflix, I saw this firsthand with foundational technologies. We built Falcor internally to orchestrate APIs. Over time, open alternatives like GraphQL proved more adaptable. Migrating was hard but necessary. Closed systems age faster while building tools around it and hiring for it is expensive.
Billing Is Infrastructure
Usage-based pricing and hybrid models are now common. Billing isn't an afterthought. It touches product, go-to-market, and revenue. Modern pricing models involve infrastructure challenges like metering and credit models.
It belongs in the same category as your cloud provider or database. You should own it, customize it, and understand how it works.
That's why we've built OpenMeter. It's a usage-based billing platform that's open by default. Metering, product catalog, and invoicing are all open source. It integrates with Stripe and other payment providers but doesn't depend on them.
We've seen what happens when teams outgrow their billing systems:
- Pricing changes stall
- New models aren't supported
- Growth plans hit technical ceilings
- Payment processor fees skyrocket
You wouldn't lock in your infrastructure. Why lock in your revenue stack?
Explore OpenMeter or check out the code on GitHub.
