Deep-dive guide
Auth MAU Cost Simulator: Per-User Login Pricing vs Self-Hosted Auth
Executive industry analysis
Authentication is one of the few parts of a product that every user touches and almost no user values. Hosted providers charge per monthly active user because that metric scales with their own costs, and for a young product it feels fair: the first ten thousand users are often free and the next ones cost cents. The risk is that the price grows with sign-ins, while your revenue grows only with the small share of users who pay. A consumer app, a freemium tool or a marketplace can add users faster than it adds income, and the authentication bill follows the first curve, not the second.
The structure of the problem is a mismatch between a cost driver and a revenue driver. Cost is billed on every active person, including free users, trial accounts, bots and abandoned sessions. Revenue arrives only from payers, typically a low single-digit percentage of the base. The ratio between the two, auth cost per paying user, is the number to watch. When it creeps from a few cents to a few dollars, the vendor is quietly taking a slice of every plan, and the plan price that made sense at ten thousand users no longer works at three hundred thousand.
The domino model follows the money through five steps. Active users, plus the bot accounts you are billed for, set the billable count. That count and the SMS volume set the auth cost per payer. Spread over revenue, it becomes the auth load. After hosting, support and engineering, what remains is the contribution margin, and fixed costs decide whether the month ends in profit. A small rise in bot sign-ups or in the share of users on text-message verification can push the second box from amber to red long before the last one changes.
The iceberg shows what the invoice hides. Above the waterline sit the provider bill for real users and the general hosting costs. Below it are bot and fake sign-ups that count as active users, SMS codes billed per message, login and lockout tickets that your support team answers, and engineering hours spent keeping the integration alive. Self-hosting removes the per-user fee but moves the same items onto your payroll, so the honest comparison is total cost over time. Use the simulator to find the user count where the lines cross.
Formula and methodology blueprint
The model works per month. Billable users are active users plus a fixed share of bot accounts. The vendor charges its price on every billable user above a free tier of ten thousand. Revenue is active users times the paying share times revenue per payer. From revenue the model subtracts hosting and support at a fixed share, the vendor invoice, SMS codes, lockout tickets, engineering hours at a loaded rate, and a fixed monthly cost.
- Billable users
- B = MAU × (1 + bot share)
- Bots and fake sign-ups that are counted as active and billed like real users.
- Vendor invoice
- A = max(0, B − 10,000) × price per MAU
- The provider fee above the free tier, before any add-ons.
- SMS and support
- S = MAU × MFA share × 2 × SMS price + MAU × 0.4% × ticket cost
- Text-message codes plus the cost of answering login and lockout tickets.
- Auth cost per payer
- (A + SMS) ÷ (MAU × paying share)
- How much authentication each paying customer has to cover each month.
- Net profit
- Net = revenue − hosting − A − SMS − support − engineering − fixed
- The monthly result. The breaking point is where this reaches zero.
Cascading elasticity
The paying share and revenue per payer are the most elastic inputs because they multiply the whole revenue line. The price per extra MAU is next: at high volume each cent per user is a large number. Engineering hours and SMS share are smaller but steady, and they are the easiest to reduce. Active users cut both ways: more users raise the invoice, but they raise revenue faster as long as the paying share holds.
Three real-world case studies
Bootstrapped starter
A small app inside the free tier
A young product has twenty thousand active users, a healthy six percent paying and a modest invoice because most of the base sits inside the free allowance. Engineering time is small. Load it to see how comfortable hosted authentication is early on, and how little the vendor fee matters at this size.
Scaling mid-market
A growing platform with strong conversion
A platform with three hundred thousand active users converts three and a half percent and charges a higher price per plan. The vendor invoice is large in absolute terms, yet well covered by revenue. Load it to see why per-user pricing is fine when payers carry the base, and where self-hosting would start to matter.
Black-swan crisis
A viral free app with few payers
A free tool goes viral and reaches three hundred fifty thousand users, but under one percent pay. SMS verification is switched on for half of them, bots join the count and the vendor moves the account to a higher tier. Load it to see authentication cost overtake revenue within a single month.
Industry benchmark matrix
| Metric | Danger zone | Industry average | Top 10% elite |
|---|---|---|---|
| Auth cost as share of revenue | Above 20% | 5–12% | Below 4% |
| Auth cost per paying user | Above $3.50 per month | $0.50–$1.50 | Below $0.40 |
| Paying share of active users | Below 1% | 2–5% | Above 8% |
| Bot and fake accounts among sign-ups | Above 15% | 3–8% | Below 2% |
| Engineering hours on auth per month | Above 60 | 10–25 | Below 8 |
Variables and levers
Monthly active users
Distinct people who sign in or hold a session in the month. This is the number the vendor bills on.
Lever: Prune dormant accounts and define an active user the way your vendor does, so you do not pay for sessions nobody uses.
Paying share of users
Share of monthly active users who are on a paid plan. Free users cost auth money but bring no revenue.
Lever: Improve activation and upgrade prompts, because every free user who never pays still has an authentication bill.
Revenue per paying user
Average monthly revenue from each paying user, after discounts.
Lever: Raise prices or move heavy users to a higher tier so revenue per payer keeps pace with per-user costs.
Price per extra MAU
What the provider charges per active user above the free tier. Many plans have steeper steps at higher volumes.
Lever: Negotiate a committed-volume tier or compare vendors, because the per-user price is the largest lever once you pass the free tier.
Users on SMS multi-factor
Share of active users who receive a one-time code by text message each month.
Lever: Offer authenticator apps and passkeys first and keep SMS as a fallback, since every text message is a direct cost.
Engineering hours on auth
Hours per month spent on integration upkeep, migrations, session bugs and security reviews.
Lever: Standardise on one login flow and delete custom code, because every extra hour of upkeep is a hidden salary line.
How to use this simulator
- 1Enter last month's active users, paying share and revenue per payer from your analytics.
- 2Set the price per extra user from your vendor invoice and estimate the SMS and bot shares.
- 3Read the five boxes and note which one turns amber or red first.
- 4Press Find my breaking point to see how far users or price can move before profit reaches zero.
- 5Compare hosted and self-hosted authentication over 24 months, including the migration cost.
Mistakes to avoid
- Comparing sticker prices instead of totals. A self-hosted option looks free until patching, on-call duty and security reviews are counted at your engineers' hourly cost.
- Treating every active user as equal. A million free sessions can cost more in authentication than a hundred thousand paying customers earn.
- Ignoring bots. Fake sign-ups and credential-stuffing attempts are billed like real users and can inflate the invoice by double digits.
- Planning for today's volume only. A pricing step that looks fine at fifty thousand users can change the whole picture at five hundred thousand.
Frequently asked questions
Is per-MAU pricing a bad deal?
Not by itself. It is cheap while your base is small or most users pay. It becomes expensive when you have many free or inactive users, so model your paying share before you commit to a plan.
When does self-hosting authentication win?
Usually at high user counts with a low paying share, and only if you can spare the engineering time. Run both scenarios here and look at the 24-month comparison, including the migration cost.
Why are bot sign-ups part of the model?
Providers usually count any account that signs in during the month as active. Fake accounts are billed like real ones, so bot protection can pay for itself.
Are SMS codes really a big cost?
They are small per message but multiply by users and months. Authenticator apps and passkeys remove most of that cost and are generally safer than text messages.
How do I find the breaking point?
Press Find my breaking point. The tool pushes each input toward its worse end and reports the value at which monthly profit reaches zero.
How accurate is this?
It is an educational model with stated assumptions, not financial or security advice. Replace the inputs with your own invoice and usage figures and check current vendor pricing.
This is an educational planning model with stated assumptions. It is not financial, tax or legal advice. Replace the inputs with your own figures and verify important decisions with a qualified professional.