.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Authentication platforms use MAU-based pricing because usage and cost scale with the number of active end-users rather than requests or features. MAUs map cleanly to customer value (more active users = more value), are predictable for finance teams, and align with how product, GTM, and security leaders think about growth—making MAU a simple, outcome-based metric for pricing, free tiers, and upgrade paths.
Modern identity tools like Clerk have made MAU-based authentication pricing the default for developer-first auth. If you’re building or scaling a SaaS product, understanding how MAU-based pricing works—and how it rolls into your own margins and pricing—is now table stakes.
Overview: How Modern Authentication Platforms Price (and Where MAU Fits)
Authentication and identity platforms handle signup, login, user management, and session security so you don’t have to build them in-house. Think of them as the “identity layer” of your product: they manage who your users are, how they authenticate, and what they can access.
Across the market, you’ll see a few recurring auth SaaS pricing models:
- MAU-based pricing – billed per monthly active user; most common for modern, developer-first tools (e.g., Clerk-style pricing).
- Monthly login or session-based pricing – charges based on number of logins or sessions.
- API call-based pricing – charges per thousand or million requests.
- Flat tiers – fixed price for a bundle of features and some soft usage limits.
- Enterprise contracts – custom pricing for large orgs with complex security and compliance requirements.
Among these, MAU is now the dominant axis for authentication pricing, especially in products targeting startups and product teams. It’s straightforward: how many distinct users authenticated in a given month?
What Is MAU-Based Pricing in Authentication?
In the context of auth, MAU (Monthly Active User) usually means:
A unique end-user account that successfully authenticates (or is otherwise considered “active”) at least once in a billing month.
Each provider’s definition can vary, but typically:
Counted as MAU
A user who logs in once or many times in the month = 1 MAU
A user with multiple devices or sessions = still 1 MAU
A user who signs up and authenticates once that month
Common edge cases
Bots / spam accounts – some platforms offer detection or filtering; others count them like any other user.
Service accounts / machine users – may be excluded or priced differently.
Test / staging users – often free or discounted if used in a non-production environment.
Dormant users – if they don’t log in this month, they typically don’t count toward MAU.
In a typical MAU-based pricing model:
- You select a tier that includes up to X MAUs.
- If you exceed that number, you either:
- Pay overages on a per-MAU basis, or
- Are automatically or manually upgraded to the next tier.
- At higher scales, you negotiate enterprise contracts, often with volume discounts, additional features, or custom SLAs.
For planning and finance, the simple rule is:
More active users = higher auth platform cost.
Why Authentication Platforms Prefer MAU Over Other Metrics
There are clear reasons identity tool pricing has converged on MAU.
1. Value alignment
Authentication platforms protect identities, not just requests. The business value of auth is:
- Securing each user’s account and sessions
- Managing their credentials and permissions
- Providing compliance and auditability
Charging per API call or per login doesn’t map directly to that value. A single, highly privileged admin who logs in rarely could be more critical (and more costly to compromise) than a casual user who logs in daily.
MAU tracks value better: if your product grows from 5,000 to 50,000 active users, the value of secure identity management clearly increases, and so does your auth platform cost.
2. Predictability for finance
Finance teams care about forecastable, controllable cost lines.
With MAU-based pricing, you can:
- Model auth spend as a function of user growth (which you’re already modeling).
- Tie it into CAC/LTV and unit economics.
- Run “what if” scenarios:
- 5k → 10k MAUs next quarter
- 10k → 25k MAUs in 12 months
By contrast:
- API or request-based pricing is sensitive to traffic spikes, feature usage, or even DDOS attempts.
- Login-based pricing can be distorted by heavy users and usage patterns.
3. Simplicity for developers
Developers integrating an auth SDK want a clear mental model:
“Our cost is tied to how many real users we have.”
This beats having to monitor and optimize request counts or sessions. It encourages product teams to focus on adoption and retention, not micromanage auth usage.
4. Vendor economics
For auth providers, costs are closely correlated with number of users and identities stored, not raw traffic:
- More user records = more storage, indexing, and backups
- More accounts = more password resets, MFA enrollments, support tickets
- Higher user counts amplify security and compliance overhead
MAU is a reasonable proxy for vendor cost as well as customer value. That alignment is why it has become the standard authentication pricing metric.
Inside a Typical MAU Pricing Grid (Using Clerk-Style Tiers as an Example)
While exact Clerk pricing changes over time, most modern auth platforms follow a similar tiering structure based on MAU:
- Free tier
- Covers a meaningful number of MAUs for early-stage products (often enough to launch and get early traction).
- Includes core auth features: email/password, social logins, basic user management.
- Startup / Pro tier
- Designed for teams that have found early PMF and are scaling.
- Higher MAU cap, with per-MAU overage or step ups.
- Adds features like advanced MFA, improved rate limits, and more environments.
- Growth / Business tier
- Suited for products with significant user bases or multiple apps.
- Higher MAU bands, better SLAs, more compliance features, and more granular roles/permissions.
- Enterprise tier
- Custom MAU pricing with volume discounts.
- Adds SSO (SAML, OIDC), advanced audit logs, data residency controls, dedicated support, and security certifications.
On top of MAU, there are often add-ons:
- SSO / Enterprise auth – SAML, SCIM, just-in-time provisioning
- Security & compliance – advanced logs, longer retention, custom policies
- Support & reliability – higher SLAs, priority support, dedicated CSM
- Regions & data residency – hosting in specific jurisdictions
The pattern: MAU is the base metric, and enterprise-grade features stack on top, often with separate line items or minimum contract sizes.
How Free Tiers Work for Auth Platforms (and Why They’re Generous)
Clerk’s free tier—and similar offers from other vendors—are intentionally generous. This is strategic:
- Developer adoption – make it a no-brainer to choose a managed auth solution early.
- Product-led growth – win mindshare at MVP/beta stage and grow with the product.
- Land and expand – once auth is integrated, switching is painful, so lifetime value can justify free early usage.
But “free” still has constraints. Typical free tier limits include:
- MAU cap – enough for early users and beta testing, but not for large-scale production.
- Branding – provider’s logo or small branding might be present.
- Environments – limited to a couple of environments (e.g., dev + one production).
- Support – community or email support only, no guaranteed response times.
- Rate limits – sufficient for small apps, but not for high-traffic launches or spikes.
- Feature set – core auth only; no enterprise SSO, advanced policies, or long-term audit logs.
For founders, the key question is: Is the free tier enough for my current stage?
MVP / pre-launch
Usually yes. You want to ship fast, validate demand, and avoid auth as a distraction.
Free tier lets you build and test without adding real cost.
Private beta / early launch
Still usually covered, but monitor MAUs as you invite more users.
Plan for a paid tier once you cross early traction thresholds.
Public launch / scaling
Expect to move onto paid tiers as you pass several thousand MAUs.
Bake auth cost into your pricing models early to avoid surprises.
Estimating Your Authentication Cost Using MAU
Here’s a simple way to estimate your auth platform cost using MAU-based pricing.
Step 1: Estimate your current MAUs
- Count distinct users who log in at least once in a month.
- If you’re pre-launch, estimate:
- MVP / closed beta: a few hundred to low thousands.
- Seed-stage with traction: 1k–10k MAUs.
- Growth-stage: 10k–100k+ MAUs.
Step 2: Apply growth assumptions
Example:
- You’re at 5,000 MAUs today.
- You expect 10% month-over-month growth.
In 12 months, 5,000 MAUs at 10% MoM becomes roughly 15,700 MAUs.
You’ll likely move from a startup tier into a growth or business tier.
Step 3: Map to tiers
Look at the vendor’s pricing grid (e.g., Clerk-style):
- Free tier → up to X MAUs
- Startup tier → up to Y MAUs
- Growth tier → up to Z MAUs
Then ask:
- Where am I now?
- Where will I be in 6–12 months?
- What’s the blended cost per MAU likely to look like?
Step 4: Consider seasonality and bursts
MAU metrics naturally smooth out short-term spikes:
- A user who logs in 1 time vs 30 times this month = 1 MAU.
- Traffic spikes that don’t increase unique users don’t blow up your bill.
But consider:
- Seasonal events – if you onboard many new users in a short time (e.g., a big launch), MAUs will jump.
- Churn and inactivity – inactive users typically drop out of the MAU count, which can lower cost over time.
Numeric examples
- Seed-stage SaaS
- 5,000 MAUs, on a paid tier that effectively averages $0.01–$0.03 per MAU.
- Monthly auth cost: $50–$150.
- If your average customer revenue is $200/month and you have 100 accounts, auth is a tiny fraction of revenue.
- Growth-stage SaaS
- 50,000 MAUs, on a higher tier or enterprise contract, maybe at an effective $0.005–$0.02 per MAU (volume discounts often kick in).
- Monthly auth cost: $250–$1,000.
- If you’re generating $300k+/month in ARR from those users, auth is still a small but important line item.
The goal isn’t pinpoint precision—it’s order-of-magnitude clarity so you can design your own SaaS pricing with those costs in mind.
Trade-Offs: MAU-Based Pricing vs Alternatives (Seats, Requests, Flat Rate)
MAU is not perfect. It’s just the least bad option for most identity tools. Here’s how it compares.
MAU vs request-based pricing
Pros of MAU vs requests:
- Easier to forecast and reason about.
- Aligns with end-user adoption, not traffic noise.
- Less prone to abuse from bots or misconfigured clients.
Cons:
- If your product has a large base of very low-value users (e.g., freemium mobile app), MAU costs may feel high relative to revenue.
MAU vs seat-based pricing
“Seat-based” (internal user count) works well for B2B SaaS selling into companies, but:
- Auth platforms serve your customers’ users, not just your internal seats.
- MAU-based authentication pricing scales with your total user base, which is exactly what you’re monetizing.
Seat-based auth pricing might look attractive, but it often fails to capture value for consumer-heavy or large B2B platforms.
MAU vs flat-rate subscriptions
Flat-rate auth pricing (e.g., “$X/month unlimited users”) is rare at scale:
- It’s attractive early, but it quickly breaks vendor economics.
- Vendors that do offer it often cap usage or reserve it for very small-scale apps.
When MAU can be painful—and what to do
MAU-based models can be challenging if:
- You run a freemium or consumer app with millions of unpaid users and a small % of paid.
- Your ARPU is low, so per-MAU infra and auth costs bite into margins.
Mitigation strategies:
- Negotiate custom contracts at scale (tiered or blended MAU prices).
- Segment traffic – offload anonymous or unauthenticated usage (e.g., read-only content) to other systems.
- Focus authentication on higher-intent actions – not every interaction needs an authenticated session.
How MAU-Based Auth Pricing Impacts Your Own SaaS Pricing Strategy
Your authentication pricing model should feed directly into your own unit economics.
Step 1: Treat auth as a variable cost per MAU
If your effective auth cost is $0.01 per MAU, and the average account has 20 MAUs, that’s:
- $0.20 per account per month in auth cost.
If you charge $200/account/month, auth is 0.1% of revenue for that customer—trivially small.
At higher scales:
- Suppose you pay $0.02 per MAU, and a large customer has 10,000 MAUs.
- That’s $200/month in auth cost for that account.
If that customer pays you $10,000/month, auth is 2% of that account’s revenue. Still reasonable in most B2B SaaS margin targets.
Step 2: Check against your gross margin targets
Most SaaS businesses aim for 70–80%+ gross margins. Infra + third-party services (including auth) are a large chunk of COGS.
- Define a guardrail: e.g., auth + core infra ≤ 15–25% of revenue.
- As MAU grows, monitor whether your per-MAU revenue is staying ahead of per-MAU auth + infra costs.
If you see auth costs hitting uncomfortable levels:
- Revisit your pricing (e.g., minimums, per-seat pricing, usage-based components).
- Explore volume discounts or enterprise deals with your auth vendor.
Step 3: Build vs buy: evaluating Clerk-style MAU pricing
Use this checklist when deciding whether MAU-based auth pricing is acceptable vs building in-house:
- Time-to-market – How much revenue will you delay by building auth instead of shipping your core product?
- Security risk – Do you have in-house expertise to manage MFA, session security, OAuth, and compliance?
- Total cost of ownership – Developer salaries + maintenance vs predictable MAU-based fees.
- Strategic focus – Is auth a differentiator, or just table stakes?
In most cases, MAU-based auth pricing is cheaper and safer than building, as long as you factor it properly into your own pricing.
Key Questions to Ask When Choosing an MAU-Priced Auth Platform
To avoid surprises, go deep on the details of identity tool pricing before you commit. Ask vendors (Clerk included):
- MAU definition and counting
- How exactly do you define a monthly active user?
- Do test, staging, bots, and service accounts count as MAUs?
- How do you handle soft-deleted or suspended users?
- Free tier limits
- What are the MAU limits by environment (dev, staging, production)?
- Which features are excluded from the free tier?
- Are there rate limits or branding requirements?
- Overages and tier transitions
- What happens if we exceed our MAU cap in a month?
- Are overages charged per MAU, or do we get auto-upgraded to the next tier?
- Is there billing lag or grace periods for sudden spikes?
- Enterprise path and volume discounts
- At what MAU level do you offer custom / enterprise contracts?
- How do discounts scale with MAUs?
- Are SSO, SCIM, and other enterprise features included or add-ons?
- Data residency, compliance, and cost
- Do specific regions or compliance features impact pricing?
- Are audit logs, longer retention, and advanced security paid features?
- How are SLAs and support priced at higher tiers?
- Billing transparency
- Can we see per-MAU and per-tenant breakdowns?
- Do you provide alerts as we approach MAU thresholds?
- Is there a sandbox for cost modeling before making changes?
The goal is to ensure your identity tool’s MAU pricing model scales linearly and predictably with your business—not in surprise jumps.
Download our MAU Pricing Checklist to model your auth costs and align them with your SaaS pricing and margins.