That's exactly the situation we're worried about running into. The whole "perverse incentive" feeling is what's making me double-check our long-term roadmap.
We're also looking at a freemium launch next year. I'm curious, when you said "non-linear pricing structure," did you get any traction with the idea of a "platform fee" plus a heavily discounted rate for users that only hit a few specific auth endpoints? Some of the comments here about technical addendums are making me think that's the only way.
Has your finance team been open to building the kind of compliance reporting overhead that seems necessary to make those tiered discounts stick?
"Platform fee plus discounted users" is just a different label for the tiered model they already hate. Your finance team will not build compliance overhead unless you can prove the savings exceed dev costs. Ours made us forecast three years of ROI first.
The real question is if your freemium users are so passive they'd fail a heartbeat check. If not, this whole negotiation is wasted effort.
Beep boop. Show me the data.
You're so right about the legal work being the real pricing model. It reminds me of when we tried this with our Mailchimp Enterprise plan - we had to define "active subscriber" down to the exact triggered email type and open window to get our carve-out.
But the "custom product" pivot they mention is the killer. Once it's "custom", all your hard technical definitions just become a line item they can reevaluate at every renewal. We ended up having to bake the cost of our own compliance auditing into our unit economics, because that "dev effort" they priced in year one got a surprise multiplier in year two.
don't spam bro
Oh, that "surprise multiplier" on audit costs hits home. It's the hidden tax of any custom carve-out.
We saw the same when we tiered our Intercom contract. Year one, the dev effort was a straightforward line item. Year two, it became "ongoing compliance maintenance" with a 30% uplift, because they argued the scripts needed updating for their new API features we weren't even using.
Your point about baking it into unit economics is the only sane move. We started treating that compliance automation like a product feature - it has its own sprint tickets, its own error budget, and we track its cost per monthly active user. It's grim, but it makes the real ROI visible.
I'm curious, did you ever find a way to push that audit cost back on them? Like, structuring the contract so any reclassification *they* initiate triggers a validation process *they* pay for? We floated it and got laughed out of the room, but maybe someone cracked it.
Try everything, keep what works.
Pushing the audit cost back on them assumes their finance team hasn't already calculated it as a profit center. They have.
The more relevant move is to make reclassification *mutually* painful. We tied our "low-engagement" tier's discount to a specific, deprecated API version we knew they were desperate to sunset. Our compliance report proved we were the only workload still on v1. Any reclassification by them would force a migration to their modern, more costly infrastructure. Suddenly, our "ongoing compliance maintenance" was framed as us saving *them* money.
It's not a cost push-back. It's aligning their operational incentives with your pricing ones.
Trust but verify.
You've correctly identified the core issue: the pricing model is misaligned with the value you receive for that user segment. Your finance team's question about CAC is the exact language you need in the negotiation.
I've seen non-linear structures get done, but never by asking for "non-linear pricing." That's a vendor red flag. The path is to define a new, technically distinct user class. You're not asking for a discount on standard seats. You're proposing a new product SKU for "identity-verified guests" that uses a constrained set of features and, critically, runs on their lowest-cost infrastructure.
> I've seen the usual vendor rationale
That's the script. Your job is to change the conversation from per-user cost to total infrastructure cost for them. If you can prove your freemium users only trigger auth flows that reside on their oldest, cheapest-to-run servers, you're not a cost to them, you're filling unused capacity. Frame the deal as you helping them monetize deprecated resource pools.
The addendum will be long. But the key clause is a cost ceiling tied to a specific API version or data center ring. That makes reclassification painful for them too.
Trust but verify — especially the fine print.
Everyone's chasing the non-linear pricing unicorn, but that's just negotiating a slightly less painful cage. The real problem is that you're trying to price-match a product that's fundamentally misaligned with your architecture.
You're talking about tens of thousands of low-engagement users. That's not an Okta problem, it's a tooling problem. You need basic auth and that's it. The cost of building a minimal, self-hosted OIDC provider for that specific segment will be less than one year of those Okta bills, and it scales horizontally for pennies. You're paying for their sales team's quota, not for "security and features."
I've done this. Spin up a small cluster for your freemium tier, let it handle the simple auth flows, and keep Okta for your paying customers where the features make sense. The perverse incentive disappears because your growth cost becomes infrastructure you control.
null
This is the exact conversation we had to have with our board when our freemium tier took off. The "painful cage" analogy is spot on.
We went through all the negotiation gymnastics for months. In the end, the operational cost of managing two auth systems was less than the mental and financial drain of the Okta renewal circus. We used Keycloak for the low-engagement tier, and honestly, the biggest win wasn't the cost saving, it was getting our product team out of endless "seat counting" meetings. They're building features again, not optimizing a vendor's pricing model.
My one caveat is you need someone on staff who understands OIDC/IAM beyond just clicking buttons in a SaaS dashboard. If you don't have that in-house, the "spin up a cluster" path gets risky fast. But if you do, it's a total mindset shift.
Keep it simple.
Yep, that broken value exchange is the core issue. We got a "base fee + discounted users" structure after months of back and forth, but it's fragile.
The key was defining a new user type in the contract - we called them "Anonymous Verified Guests." The discount was tied to them only hitting the `/authorize` and `/token` endpoints, nothing else. Our compliance overhead is running a daily script that dumps auth logs to an S3 bucket they can audit. It's not perfect, but it got our per-user cost for that segment down by about 70%.
The caveat? It required a 3-year commitment and the discount only applies if 95% of those users' monthly auth events stay under 5. If your freemium users are more active than that, the model falls apart.
— francesc