Live data from Hacker News

Show HN: Tier.run – Terraform for Stripe

github.com

1–10 of 49 posts

Show HN: Tier.run – Terraform for Stripe

#1
Hi HN, we are Jevon, Blake and Isaac, we've been working on Tier for a little while ( http://github.com/tierrun/tier )

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.

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.

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?

It's just too hard. Any change you make to the pricing model means refactoring not just the entire product, but sometimes the entire company. 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.

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. https://priceops.org

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.

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.

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.

Show HN: Tier.run – Terraform for Stripe
github.com

Re: Show HN: Tier.run – Terraform for Stripe

#2
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?

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

Re: Show HN: Tier.run – Terraform for Stripe

#3
post #2

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

Perhaps I will regret using that tagline. It's an analogy covers half the functionality.

Tier does set up and manage your stripe account based on your pricing.json config, but we go further than that with metering, feature flag style entitlement checks, and other things we plan to provide that you couldn't do as just a provider.

Re: Show HN: Tier.run – Terraform for Stripe

#4
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.

Re: Show HN: Tier.run – Terraform for Stripe

#7
(a) >> Adjusting price is the single most effective lever a business can use to achieve product/market fit,

(b) >> and there's a strong correlation price nimbleness and market success.

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.

- [1] https://wikipedia.org/wiki/Loss_aversion

______

(c) >> https://priceops.org/

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?

Re: Show HN: Tier.run – Terraform for Stripe

#8
post #3
post #2

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

Perhaps I will regret using that tagline. It's an analogy covers half the functionality. Tier does set up and manage your stripe account based on your pricing.json config, but we go further than that with metering, feature flag style entitlement checks, and other things we plan to provide that you couldn't do as just a provider.

There are terraform providers for DNS services, Database configuration, CI services and all sorts of other things. It's actually not that hard to write a something that wraps configuration state of various APIs into a terraform module.

Now, I don't really know the Stripe API besides a quick skim a few years ago, but I think that it's a fully reasonable comment and expectation that when someone says "Terraform for random API" one expects a terraform provider for that.

Re: Show HN: Tier.run – Terraform for Stripe

#9
post #4

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.

Grandparenting in old accounts is baked into the system. Plans are immutable[1] once pushed live, so if you add a new plan and put it on your signup page, new customers will use the new plan, but existing customers will keep on with the plan they signed up with. You can of course upgrade them at any time using `tier.subscribe()`

Scheduling rollouts of new pricing can be done by modifying the effective date of a `tier.subscribe()` call. So you could do something like `tier.subscribe('org:' + customerID, 'plan:whatever@123', someFutureDate)`.

For communicating it to customers, yeah, you'll probably want to tell them their price is going to change ;) It might even be good to have an email campaign where they can check out the new price and decide to upgrade/downgrade/whatever with some time to make a decision. Customers usually don't love being forced into things without notice. Tier doesn't handle this part of it for you, but it does give you the tools to make the actual subscription change pretty easily.

[1] "Mostly" immutable. You can of course go into your Stripe account and edit anything they let you. But Tier makes it easier to just add new plans and leave the old ones there.

Post reply on HN