Hi HN, we are Jevon, Blake and Isaac, we've been working on Tier for a little while ( <a href="http://github.com/tierrun/tier" rel="nofollow">http://github.com/tierrun/tier</a> )<p>Tier is "Terraform for Stripe" but it goes further and gives you feature flag style access checks, and allows you to count/report usage which can be used for metered billing.<p>When we started Tier, we knew that there was something interesting in the SaaS pricing and packaging space. Adjusting price is the single most effective lever a business can use to achieve product/market fit, and there's a strong correlation price nimbleness and market success.<p>In spite of overwhelming evidence of this, most startups pick the price for their product once and then never change it, opting instead to invest in less effective levers like CAC, sales efficiency, "virality", churn, etc. Why?<p>It's just too hard. Any change you make to the pricing model means refactoring not just the entire product, but sometimes the entire <i>company</i>. The path of least resistance leads to a place where there's no single source of truth, and changes anywhere require changes everywhere.After over 50 or so customer conversations and user research chats, this represents our third or fourth implementation (depending on how you count them), and our conception of how best to solve it has been refined and adjusted along the way.<p>The concept of "PriceOps" came out of those conversations, looking at where mature companies end up after several expensive rounds of iterating on how they implement their prices for flexibility and order. <a href="https://priceops.org" rel="nofollow">https://priceops.org</a><p>What we're releasing now is an open source tool you can use to set up your Stripe system that keeps everything organized around a single source of truth. With this, changes to your pricing model don't require changes to your application code or business processes.<p>As a bonus, I think it's actually easier to integrate with than integrating with Stripe the "normal" way. Use the identifiers for your customers and features that you already have. Define plans and subscribe customers to them. No ever-growing pile of object ids to manage.<p>If you are just starting to think about adding pricing to your product, or if you've built something custom but would like something less maintenance intensive, then please give Tier a try and we'd love your feedback.
I'm not in that problem domain in order to know: why make "like terraform, but for stripe" when you could have made "terraform-provider-stripe" and then been _actual_ terraform for stripe?<p>Because the recipes still look like they're targeting a very technical user, which was my mental model for why one would build a whole new DSL
How is this better than the Stripe Terraform provider? <a href="https://registry.terraform.io/providers/franckverrot/stripe/latest" rel="nofollow">https://registry.terraform.io/providers/franckverrot/stripe/...</a>
This looks very cool! Stripe is very hard in 2022. We just integrated such for our VS Code extension.<p>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.<p>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.<p>Would tier.run help us with that????<p>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?<p>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.<p>I also saw you want to build your product as an Auth0 action. Would that be used for this use case?<p>Anways, congrats on the launch!!
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).<p>Two things that come to mind:<p>- 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.<p>- 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.<p>[0]: <a href="https://www.osohq.com/" rel="nofollow">https://www.osohq.com/</a>
(a) >> Adjusting price is the single most effective lever a business can use to achieve product/market fit,<p>(b) >> and there's a strong correlation price nimbleness and market success.<p>Would it be possible to expand on and/or provide additional sources for each of these claims, since while I get that given all other aspects being equal that price is frequently a defining factor, but my understanding is that even then loss aversion [1] means it’s economically a bad strategy to a market.<p>- [1] <a href="https://wikipedia.org/wiki/Loss_aversion" rel="nofollow">https://wikipedia.org/wiki/Loss_aversion</a><p>______<p>(c) >> <a href="https://priceops.org/" rel="nofollow">https://priceops.org/</a><p>Might be wrong, but brief review of this appears to show the “thesis” of PriceOps is yield-based metered feature pricing, but again not seeing any research to backup this approach and/or measure of fitness of this approach to a given situation. Do you have an related research to link to?
This is pretty cool! Do you have ways for elegantly handling grandfathering old customer plans, scheduled rollouts of new pricing, etc? I think more than testing/changing the value of the $tier_2_price variable is how you communicate and/or apply it to existing customers.
If I'm thinking about pricing, I'm likely also highly interested in a nice UI/Design for my page. IMHO Your <a href="https://priceops.org/" rel="nofollow">https://priceops.org/</a> needs some major design TLC. Personally, when I see a gray background, or a especially a serif font on a web page trying to sell me something I'll be pretty skeptical. It doesn't need to be wizz-bang amazing, but something cleaner is in order. I'd just grab something from one of the many bootstrap css template stores that are out there. The tier.run site looks a million times better.<p>It lookslike a cool product, good luck to you!
From the Pricing JSON page, on the 'Why Each Plan Must Have At Least One Feature' question, it says:<p>> Without this restriction, it would be significantly more expensive to fetch your pricing model from Stripe's data.<p>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 <a href="https://priceops.org/4-entitlement" rel="nofollow">https://priceops.org/4-entitlement</a>), but that's not the reasoning laid out here, is it?
congrats guys, i've been interested in UBB for a while and i think an "as code" type of approach makes a ton of sense (and maybe can build a low code layer on top). this is the killer line:<p>> With this, changes to your pricing model don't require changes to your application code or business processes.<p>i would go so far as to produce a scenario or skit or whatever to use this all over your marketing materials as any growth PM or founder would immediately understand this one
Very interesting. I‘m not very knowledgeable in the payment space, unfortunately. Do you think there is a way to abstract the concepts over multiple, pluggable payment providers (other than Stripe) in the future?
We don't have SaaS apps but having something like that for in-app purchases that will deploy over App Store, Google Play and PayPal at once would be appreciated. Just a suggestion.
Has Stripe gotten complex enough that there is again room in the market for a simple "one line of code" product to accept credit cards on your website?
Small heads-up: The "Read docs" button on your website isn't clickable directly after page load (only after scrolling down, when it moves to the header).
very cool!<p>Since you’re well within the power user category, any feedback on how to make the Stripe APIs better? Either for customers’ uses or for your own. I hear you on the object ids :)<p>Happy to hear here or maddox@stripe.com
not sure why this needs to be a product... stripe already facilitates price versioning. shouldn't be too hard to sync with my app.
my app is tiny right now so I'm doing it by hand but building a little sync command wouldn't take me more than a day.