Why We Stopped 'Usage-Based Pricing'. The Revenue Nightmare.

Usage-based pricing was supposed to be the future of SaaS. Every VC blog post said so. Every pricing consultant recommended it. Twilio did it. Snowflake did it. AWS pioneered it. "Align price with value! Let customers start small and grow! Capture upside automatically!" The logic was compelling.

We were a B2B SaaS tool with clear usage metrics: API calls, storage, and compute time. Perfect candidates for usage-based pricing. We'd let customers pay only for what they used, remove the friction of upfront commitment, and grow revenue automatically as they scaled.

We spent three months redesigning our billing system. We implemented real-time usage tracking, tiered pricing with volume discounts, and beautiful dashboards showing customers their consumption. We migrated existing customers to the new model (with generous grandfathering).

For the first quarter, things looked great. Some customers spent more than their old flat rate. Acquisition was easier with the "start free, pay as you grow" pitch.

Then the problems started:

Problem 1: Revenue forecasting became nearly impossible. Monthly revenue fluctuated 30-40% based on customer activity patterns we couldn't predict.

Problem 2: Customers started actively managing down their usage. They'd build caching layers, skip optional API calls, and batch processes to minimize bills. Usage management became a tax on their development time.

Problem 3: Surprise bills caused churn. A customer would have an unexpected usage spike (a bug, a misconfigured job, legitimate growth) and receive a bill 3x their normal amount. Even if we credited it back, the trust was damaged.

Problem 4: Sales cycles lengthened. Enterprise buyers wanted predictable costs. "It depends on usage" wasn't acceptable; they needed fixed budgets for procurement.

After 18 months, we reverted to flat subscription pricing with usage limits and clear overage rates. Revenue predictability returned, customer satisfaction improved, and—counterintuitively—we made more money.

Section 1: The Forecasting Nightmare—Why Finance Hates Usage Pricing

Our CFO pulled me aside six months into usage pricing: "I can't run this company if I can't predict next quarter's revenue."

She was right. With flat subscriptions, forecasting was straightforward:

• Starting MRR: $500,000
• Expected churn: 3% = ($15,000)
• Expected new sales: $40,000
• Ending MRR: $525,000
• Confidence interval: +/- 5%

With usage pricing, forecasting became guesswork:

• Starting monthly revenue: $520,000
• Expected usage change: ???
• Range of outcomes: $400,000 to $700,000
• Confidence interval: +/- 30%

What Drove the Variance

Customer activity patterns: Some months, customers ran more jobs. Other months, they went on vacation or had project pauses. We couldn't predict this.

External events: A major customer had a data center migration and paused processing for two months. Another had a viral product launch and usage 10x'd. Neither was foreseeable.

Seasonality we didn't understand: Turns out our customers had seasonal patterns that affected their usage. Q4 was high, Q1 was low. We only discovered this after 18 months—too late to plan around it.

The Downstream Effects

Revenue unpredictability cascaded everywhere:

• Hiring: We couldn't commit to new headcount because we didn't know if we'd have the revenue.
• Infrastructure: We over-provisioned (expensive) or under-provisioned (risky) because capacity planning required revenue forecasts.
• Fundraising: Investors wanted predictable growth. "Revenue depends on customer usage patterns" was not a confidence-inspiring answer.
• Sales compensation: How do you set quotas when you can't predict revenue from existing customers?

Usage-based pricing optimized for customer flexibility at the cost of business predictability. For us, that tradeoff didn't work.

Section 2: The Usage Management Tax—Customers Optimizing Against You

When every API call costs money, customers optimize to minimize API calls. This seems rational from their side. From our side, it meant customers were actively degrading their own experience to save a few dollars.

The Caching Explosion

Our API returned customer insights based on their data. With usage pricing, customers started caching everything. They'd call our API once and cache the result for 24 hours, even when fresher data would be more accurate.

Customer: "Why is my dashboard showing stale data?"

Us: "You're caching for 24 hours."

Customer: "Because your API costs money. If it was flat rate, I'd call it every hour."

They were getting a worse product experience to save money on a service they valued. We had created a perverse incentive.

The Feature Avoidance Problem

We launched a new feature that provided richer insights but required 3x the compute per call. Usage-based customers avoided it: "We can't afford the extra usage."

Flat-rate customers adopted it immediately: "Great, more value for the same price!"

Usage pricing was suppressing adoption of our best features. Customers were rationally optimizing for cost, not value.

Developer Time Wasted

Our customers' engineers were spending time building usage optimization layers: batch processors, caching systems, usage monitoring dashboards. This was time not spent building their actual products.

One customer estimated they'd spent 160 hours building usage management infrastructure. At their engineering cost, that's $24,000—far more than they'd saved on our bills.

But the perception was different: "I can see my XQA bill going down. I can't see the opportunity cost of my engineers' time."

We had created a hidden tax on our customers' productivity.

Section 3: The Surprise Bill Problem—Trust Destruction

The single biggest issue with usage pricing: surprise bills.

The $15,000 Bug

A customer's engineer deployed a bug that caused their batch process to retry indefinitely. It ran for a weekend before anyone noticed. Usage: 10x normal. Bill: $15,000 (normally $1,500).

The customer called us furious. "Your billing system didn't have any alerts! We had no idea this was happening!"

They were right. We added usage alerts. But the trust was gone. They churned three months later, citing "unpredictable costs" as the primary reason.

The Legitimate Growth Problem

A customer's product went viral. Their traffic 5x'd in a week. Their XQA usage scaled with their traffic. Their bill went from $3,000 to $15,000.

We called to congratulate them on their growth. They were not happy: "We can't afford this. We need to switch to a competitor with flat pricing."

They were having the best month of their company's history, and our pricing model was punishing them for it. Usage-based pricing had turned their success into our relationship failure.

The Budget Cycle Mismatch

Enterprise customers have annual budgets. They allocate $X for vendor Y. If vendor Y's bills vary month-to-month, the customer has a problem:

• Over budget: They get flagged by finance. Someone has to explain. It looks bad.
• Under budget: The "savings" get reallocated. Next year's budget gets cut. Nobody thanks you for coming in under.

Enterprise buyers wanted predictable bills that matched their budgets. "Your usage was lower this month" was not a benefit—it was a budget management headache.

Our enterprise sales team started offering "committed spend" deals—essentially converting back to flat pricing with usage credits. The workaround became the default.

Section 4: Our Current Model—Predictable with Clear Boundaries

We replaced usage-based pricing with a tiered subscription model:

The Structure

• Starter: $299/month - Up to 100k API calls, 50GB storage
• Growth: $799/month - Up to 500k API calls, 250GB storage
• Enterprise: $2,499/month - Up to 2M API calls, 1TB storage
• Overage: Clear per-unit rates if you exceed limits (rarely triggered)

Why This Works Better

1. Predictable revenue: We can forecast accurately. We know what each customer pays each month.

2. No usage anxiety: Customers use what they need without watching a meter. They use features freely.

3. Clear upgrade path: When customers approach limits, they upgrade tiers. This is a positive conversation ("you're growing!") not a negative one ("your bill surprised you").

4. Enterprise-friendly: Fixed monthly cost fits procurement and budgeting.

Handling the Edge Cases

Some customers genuinely have variable usage. For them, we offer:

• Committed spend: "Commit to $20k/year, use as needed, credit rolls over." Enterprise buyers love this—it's a budget line item with flexibility.
• Usage alerts: Proactive notifications at 50%, 75%, 90% of limits. No surprises.
• Grace overages: First overage each quarter is free. Accidents happen; we don't punish them.

When Usage Pricing Can Work

We're not saying usage pricing is always wrong. It works for:

• Infrastructure (AWS, GCP): Customers expect variable infrastructure costs. It's understood.
• Volume-based businesses: Email sending (Sendgrid), SMS (Twilio) where usage directly correlates with customer revenue.
• Very low friction products: Where customers have no expectation of budget predictability (consumer-ish).
• True commodities: Where price is the primary differentiator and customers actively shop.

For B2B SaaS where the relationship matters, where budgets are fixed, where customers want to focus on their work rather than managing our bills—flat pricing wins.

Conclusion: Align with Customer Psychology, Not Just Value

"Align price with value" sounds right. But it ignores psychology.

Customers don't want to pay for exactly what they use. They want to pay a predictable amount and use whatever they need. The peace of mind of a fixed bill is itself valuable.

Usage-based pricing creates anxiety. Every API call has a cost. Every feature use is a decision. The mental overhead accumulates. Customers resent it, even if the bills are "fair."

Flat pricing creates freedom. Use what you need. Don't think about the meter. Focus on your work. The product feels like a tool, not a taxi.

For 18 months, we optimized for theoretical "value alignment." When we switched to customer psychology alignment—predictability, peace of mind, no surprises—everything improved: revenue, retention, satisfaction, and sales cycles.

Don't follow pricing trends because famous companies use them. Understand your customers' psychology and design pricing that matches how they want to buy, not how you want to charge.

Customers don't pay for value. They pay for peace of mind. Price accordingly.