With Stripe Billing, ‘build vs buy’ becomes ‘buy and still build’...

I went to an event last week and introduced Flexprice:
“We’re building a metering and billing platform for AI and Agentic companies. Think usage metering, dynamic pricing plans, and credit management..."

The response (almost on reflex):
“Isn’t Stripe already doing everything you just described?
Usage metering, pricing plans, credits…what problem are you even solving?
After all, how hard can billing be?”

At first glance, these questions seem fair.
The checkboxes look identical.
So do icebergs until you swim underneath.

Let’s take hybrid pricing (Tremont's 2025 report projects 49% adoption by 2028).

Yes, Stripe let's you create recurring and usage-based plans

But today, it doesn’t let you:
- Add multiple meters within a single plan
- Combine recurring + usage charges in a single plan

Sure, your developers can work around it by assigning multiple subscriptions to a customer.

Maybe tomorrow Stripe will let you create native hybrid plans.
But this is where the complexity starts, not where it ends.

What happens when:
- You want to update base subscription price from $10 to $15?
- Change the meter from tokens to GPU time?
- Should it apply to new users only?
- Should existing users be grandfathered?
- Can i give additional discount to existing customers?
- Can I extern the trial period to 60-days instead of 30 for an enterprise client?

This is where most teams enter the never-ending billing sprint.

Stripe Billing gives you 80% of what you need.
The remaining 20% (customization and flexibility) takes 80% of your engineering time.

Billing isn’t hard because of missing APIs.
It’s hard because of messy pricing workflows.


This post was originally shared by on Linkedin.