Show HN: Tier.run – Terraform for Stripe

This looks very cool! Stripe is very hard in 2022. We just integrated such for our VS Code extension.

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!!

As a Stripe customer, I think that the principles on which Tier were built constitute best practices that could have been taught to me by Stripe docs.

For instance, the idea that plans should be treated as immutable (and versioned when changes are desired) and that we should attach application code to features (and not directly to plans), having a lawyer of abstraction that links features to plans, could have been laid out to us at the very beginning of our integration.

They seem obvious in retrospect, but one is not guaranteed to derive them on first try; the fact that they wrote https://priceops.org/4-entitlement is telling.

From the Pricing JSON page, on the 'Why Each Plan Must Have At Least One Feature' question, it says:

> Without this restriction, it would be significantly more expensive to fetch your pricing model from Stripe's data.

I didn't quite get that. I understood that application code should reference features (and not plans directly) so it becomes easier to change plan structure (via https://priceops.org/4-entitlement), but that's not the reasoning laid out here, is it?

Very interesting approach, and nice to see someone tackling that problem area! You see a hundred blog posts of "why you should experiment with your pricing", but actually doing that is often such a pain that nobody ends up doing that (and admittedly the reason why I would have shied away from such projects in the past).

Two things that come to mind:

- What are your plans like regarding the integration of entitlement checking in the service and SDK? As far as I can tell, that's still a missing piece? I really love how oso[0] has managed to separate the authorization checking from the authorization definition via their DSL and SDKs. Ever since I saw that, I was wondering if a very similar system could work for entitlement checking.

- I think where your system could provide a lot of benefit would be in help tracking usage metrics that can be harder to calculate (and with that more of a pain to use). It's already nice not having to implement a simpler "number of action N taken the last billing period" metric. However something like a "N number of active users last billing period", where you now would also have to keep track of which users you have already seen before to prevent double-counting them becomes increasingly annoying to implement.

[0]: https://www.osohq.com/