Hi HN, I’m Gabriel, VP of DevRel at [Permit.io](<a href="http://permit.io/" rel="nofollow">http://permit.io/</a>). We just launched a major overhaul of our pricing, and, while working on this, I’ve encountered challenges I thought were unique to our SaaS.<p>The more effort I put into this, the more I felt like balancing operational costs and providing customers with predictable pricing is something other SaaS companies probably encounter as well.<p>We’ve had a lot of startups reach out to us to help them implement fine-grained authorization, and, as an authorization SaaS, this created some pricing problems for us.<p>It would be easiest for us to charge clients based on the number of authorization API calls we have to process, as each call directly represents a quantifiable cost in server and infrastructure resources. That’s the way most authorization providers do it.<p>The thing is, authorization calls add up quickly and unpredictably. Even a single API call from a user may require multiple authorization checks. This means potentially large, unexpected expenses for our clients.<p>That’s why we initially designed our pricing model around Monthly Active Users (MAU) to offer a predictable cost structure.<p>Basing pricing MAU, however, created a problem for us as a SaaS provider, as it doesn’t account for the variability in authorization usage that occurs within different applications.<p>Some companies may have a small number of users, but those can trigger a very high volume of authorization calls, meaning significant operational costs on our end.<p>To address usage unpredictability, we just introduced a quota on the number of resources and rules clients can define in our system, as well as a new startup tier.<p>By setting these quotas, we can now manage our operational costs more effectively, especially when it comes to caching rules and handling the volume of API calls.<p>This approach allows us to offer a Monthly Active User (MAU) pricing structure at a rate significantly lower than any other authorization-as-a-service provider.<p>I’m now sure this problem isn’t a challenge that’s unique to us. Have you encountered anything similar? I’d love to know how you solved it and what you think of this solution.