> Iterating this on a pricing.json file feels easier.
Agreed. :)
> if we decide to do something like giving the user the possibility of choosing between a monthly or a yearly subscription (with a variable quantity, because we charge per seat). That would imply a code refactor. Would tier.run help us with that????
Currently, plans that are similar but with different billing intervals can best be expressed as two plans like: `plan:pro:annual@0` and `plan:pro:monthly@0`. We're very open to feedback on this approach though.
> Do I set up which features belong to every plan on the pricing.json file, and then consume your SDK on the frontend to only show the tier to a certain category of paying user?
This is correct, limits (if any) are defined in the pricing.json using tiers. These limits may be reported to a browser session via a backend that proxies the limits from the sidecar back out.
> I also saw you want to build your product as an Auth0 action. Would that be used for this use case?
It seems possible. How do you envision the Auth0 action behaving with Tier?
I think this makes sense because switching between them can be done very easily, just change the string from `plan:pro:annual@0` to `plan:pro:monthly@0`. As long as I can write some client side code that allows me to change if the end user is getting access to `plan:pro:annual@0` or `plan:pro:monthly@0` based on what they select on a UI.
> It seems possible. How do you envision the Auth0 action behaving with Tier?
Sorry, I'm not familiar with Auth0 actions. It was just an open-ended question because I saw someone proposed this on your Slack group.
With our current architecture (a very simple one) a simple thing such as iterating on the price of our product requires changing an env var on Vercel. Not complicated, but feels cumbersome for changing a price. Iterating this on a pricing.json file feels easier.
Things get more complex if we decide to do something like giving the user the possibility of choosing between a monthly or a yearly subscription (with a variable quantity, because we charge per seat). That would imply a code refactor.
Would tier.run help us with that????
Really excited about feature flags as well. How would this work exactly? Do I set up which features belong to every plan on the pricing.json file, and then consume your SDK on the frontend to only show the tier to a certain category of paying user?
We currently handle that by querying a SQL table of paying users, and if the email address of the authed user belongs to the table, we show the feature, else not.
I also saw you want to build your product as an Auth0 action. Would that be used for this use case?
Anways, congrats on the launch!!