Why Per-Request Pricing Is Broken for Authorization

Authorization is different from most SaaS features. It's not something users interact with directly — it's infrastructure that runs on every request. That makes per-request billing a particularly bad model for authorization services.

Let me explain why, and why we chose flat-rate pricing instead.

The Math Problem

Suppose you're building a SaaS product. Your app makes one access check per API request — reasonable. You have 1,000 active users. Each user makes 100 API calls per day. That's:

1,000 users × 100 calls/day × 30 days = 3,000,000 checks/month

At Auth0 FGA's rate of ~$6/million checks, that's $18/month in authorization costs. Manageable.

Now you have a successful product launch. Users are excited. Usage triples overnight:

3,000 users × 100 calls/day × 30 days = 9,000,000 checks/month → $54/month

Your authorization bill tripled with your users. But your authorization vendor didn't do any extra work to serve those checks — DynamoDB queries are DynamoDB queries. The value you get from authorization doesn't scale with usage; the presence or absence of an authorization system is a binary business decision.

Authorization Is Infrastructure, Not a Product Feature

Consider how we price other infrastructure:

• Database hosting: You pay for storage and compute capacity, not per query.
• CDN: You pay for bandwidth and request volume, but at commodity rates — not a premium for the "feature" of caching.
• DNS: You pay a flat monthly fee. Route53 does charge per query, but at $0.40/million — not $6.
• Load balancers: Flat rate + data transfer. Not per routing decision.

Authorization, like DNS, is a lookup-and-evaluate service that runs on every request. The cost to serve one check vs. a million checks is almost entirely in infrastructure capacity, not variable per-check work.

Per-Request Billing Misaligns Incentives

When your authorization provider charges per check, you start making engineering decisions based on cost, not correctness:

• You cache access decisions locally to avoid API calls — introducing stale permission bugs.
• You batch authorization checks or skip non-critical ones — introducing security gaps.
• You avoid fine-grained permissions in favor of coarse-grained roles — defeating the purpose of RBAC.

How We Price WardenAuth

Our pricing is built around included monthly volume with a generous buffer before overage:

• Free: 50K checks/month free. For prototypes and early products.
• Startup ($29/mo): 5M checks/month. Enough for a medium-traffic SaaS.
• Scale ($99/mo): 20M included, then $5/million. Transparent overage.
• Enterprise ($499/mo): 20M included with SCIM and dedicated support.

This model means you know your authorization cost at the start of each month — within a predictable range. There are no surprise invoices from a viral week. You can check permissions as often as your architecture requires without worrying about the cost.

No Per-Tenant Pricing Either

Some authorization vendors charge per "organization" or "tenant" in your system. This is equally misaligned.

If you're building a multi-tenant B2B SaaS, your revenue grows with the number of customers. Your authorization vendor shouldn't grow at the same rate — they're storing a few KB of RBAC configuration per tenant, not doing proportionally more work.

WardenAuth has no per-tenant pricing. You can have one customer or ten thousand. The number of access checks is what drives infrastructure cost; the number of tenants is just configuration data.

The Honest Tradeoff

Flat-rate pricing benefits high-volume customers at the expense of very low-volume ones. At 50K checks per month, per-request pricing would be cheaper than our Pro tier. That's why we have a free tier that covers most early-stage products.

At scale — millions of checks per month, multiple customers, frequent API traffic — flat-rate pricing becomes dramatically cheaper, more predictable, and removes the per-check security incentive problem entirely.

We built WardenAuth on AWS Lambda and DynamoDB, so our infrastructure costs are also usage-based. But we absorb that variable cost in our margin and offer you a predictable rate. That's the business we chose to build.