Permit.io's new predictable, startup-focused pricing model

Hacker News

Share card

Permit.io's new predictable, startup-focused pricing model

Hi HN, I’m Gabriel, VP of DevRel at [Permit.io]( http://permit.io/ ). 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. 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. 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. 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. 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. That’s why we initially designed our pricing model around Monthly Active Users (MAU) to offer a predictable cost structure. 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. 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. 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. 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. 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. 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.