DEV Community

Meterbase for Meterbase

Posted on

Soft cap or hard cap? Deciding what happens when a customer hits their limit

Sooner or later, a paying customer hits the edge of their plan in the middle of something they care about. What your product does in that moment is a pricing decision, a product decision and an engineering decision at once. Most teams make it by accident, in whichever code path ran out of credits first.

Here are the options, and what each one needs underneath.

Option 1: Hard cap

The customer gets exactly what the plan includes. When it's gone, the next request is refused until the period renews or they buy more.

Good for: prepaid credits, free tiers, and products where each unit is expensive.

Watch out for: refusing work halfway through a multi-step job. If an agent run needs ten steps and the balance covers seven, a hard cap mid-run leaves the customer with a broken result. Gate the whole job up front, with a hold sized to the estimate, rather than step by step.

Option 2: Soft cap with overage

The plan includes an amount. Usage past it keeps working and is billed as overage when the period ends.

Good for: business customers who'd rather pay more than be interrupted, and products where a usage spike means things are going well.

Watch out for: surprise invoices. A soft cap without alerts is how you get an angry email from someone's finance team. You also need an exact, closed number for included usage and overage per customer per period.

Option 3: No cap

Nothing is included or limited. Everything is metered and billed afterwards.

Good for: pay-as-you-go API products sold to developers.

Watch out for: runaway scripts. With no cap, rate limits are the only thing between a bug in a customer's loop and a very large bill. Keep per-customer rate limits even when you don't cap totals.

Option 4: Mix them per meter

Real plans usually combine them: unlimited chat messages, 5,000 image generations a month with overage, and a hard cap on the most expensive thing you sell. A plan is a set of decisions, one per thing you measure.

Whatever you pick, add these two

Thresholds. Tell customers at 80%, 90% and 100%, once each per period. That turns a hard stop into a top-up, and an overage invoice into something they saw coming.

Top-ups. For hard caps, give customers a way to buy more right now. A top-up should have its own expiry, separate from the monthly allowance, so it doesn't vanish at renewal.

How this maps onto Meterbase

In Meterbase, each plan allowance is one of these, set per meter, so one plan can mix them:

  • a finite amount (hard cap)
  • a finite amount with allow_overage: true (soft cap)
  • no_cap (no cap)

Your code doesn't change between them. You still check before the work and track after. Under a soft cap, check keeps allowing past the included amount and tells you so:

{ "allowed": true, "no_cap": false, "available": 0, "allow_overage": true, "rate_limits": [] }
Enter fullscreen mode Exit fullscreen mode

Threshold crossings become webhooks, rate limits apply per customer either way, and when a period closes you read its exact usage and overage to bill from.

If you're making this decision for your own product right now, we're happy to talk it through: meterbase.tech.

Top comments (0)