Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Tier.run – Terraform for Stripe

github.com

Post reply on HN
Print view View original

31–40 of 49 posts

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

#31

Post by jmacd »

brycelarkin wrote: post #23

How is this better than the Stripe Terraform provider? https://registry.terraform.io/providers/franckverrot/stripe/...

I like that provider and it's really useful in a lot of situations. Configuring Stripe as it is currently designed doesn't always help as much for SaaS and infrastructure billing models. We wrote here about how we map to Stripe https://www.tier.run/docs/mapping/

Even after Stripe has been set up, you then get our SDK (node available, Go shortly) which gives you things like .subscribe(), .report(), .whois() (gets stripe ids) and .limits() that you can use to tool your app. The benefit is that when you change your plans or pricing, you don't need to refactor your front end. These are the benefits of the pillars on https://priceops.org

The CLI also acts as a sidecar in your network to do things like rollups and it manages Stripe pretty gracefully (Stripe can often have rate limits or requirements that aren't always clear). It also handles metering for you via the above referenced methods.

Someone made another comment on this thread that outlines some of the benefits vs Stripe raw as well. https://news.ycombinator.com/item?id=33431567

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

#32

Post by jmacd »

swyx wrote: post #20

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: > With this, changes to your pricing model don't require changes to your application code or business processes. i would go so far as to produce a scenario or skit or whatever to use this all over your marketing materials as any g…

I love that!

I'm currently writing "PriceOps for Product Managers" and "PriceOps for Growth" as well. We hear a lot from PMs and PMMs who are eager for something that can allow them to make pricing and packaging changes safely and reliably (and often).

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

#35

Post by viggity »

If I'm thinking about pricing, I'm likely also highly interested in a nice UI/Design for my page. IMHO Your https://priceops.org/ 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.

It lookslike a cool product, good luck to you!

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

#38

Post by IsaacSchlueter »

O__________O wrote: post #18
IsaacSchlueter wrote: post #12

Earlier quoted context omitted.

> Might be wrong, but brief review of this appears to show the “thesis” of PriceOps is yield-based metered feature pricing The "thesis" of PriceOps is less "you must have metered feature pricing", and more "you should design your infrastructure so that you can learn from and adjust pricing in the future". In other words, expect that your product, customers, and landscape will change, and understand that the pricing s…

Thanks, appreciate links, clearly spent time researching topic, curious what you found of use, and will check out all the links. That said, to me feels like you’re making claims, then when confronted about them not actually addressing them. Yes, there are situations systems like this work, for example, when there’s finite volume of inventory and market is willing to pay more to gain access to that inventory as the av…

Ah, I somewhat misunderstood your previous comment, my apologies. This could certainly be clearer in documentation and the priceops.org presentation, I'll take the note on that and think about how to make it more clear.

When we say "change prices", we're not necessarily suggesting "change prices for each customer/transaction, based on demand/time/demographics/etc" in an aggressive yield management approach. In fact, doing this too aggressively in SaaS products (even being too blatant or careless with A/B testing prices and plans) can lead to customer backlash. See for example common reactions to online games selling virtual goods for different prices in different locales. I'm not saying it's never a viable tactic, but it is not a silver bullet, as you point out.

However, it is the case that:

1. Your product will change over time (you keep adding features, decide to focus on some or abandon others, etc.)

2. Your target market may change (features formerly thought of as "pro" become expected at the "basic" level, for example.)

3. Your competitors will change (new entrants to the space, existing players changing their offerings, thus changing customer expectations of your product.)

4. Thus, you're very unlikely to pick the "correct" price and packaging on day 1, and it's virtually impossible to predict what will be "correct" in the future.

So, being able to adjust prices without refactoring your entire application and company is really essential, as many SaaS companies learn the hard way, and as is shown in the resources I shared in my previous comment. Eventually, your prices and packaging will most likely have to change (or at least, changing them will be beneficial, even if not existentially necessary), and making that easy is very valuable.

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

#39

Post by rjzzleep »

OJFord wrote: post #29
moltar wrote: post #26

Earlier quoted context omitted.

And combine it with cdktf you can use actual code, shared consts, and have a reliable setup in a common language rather than a JSON DSL.

Use HCL and you can use actual code, shared consts, and have a reliable setup in a fit-for-purpose (declarative) language rather than a JSON DSL.

Not sure why his comment was downvoted, but I actually think his comment is accurate. HCL is pretty limited in its primitives. In my opinion cdktf's two fundamental issues are:

1. the generated HCL contains plain text passwords if you use any sort of secrets access inside of cdktf

2. because you can use any programming language for cdktf, every project will look different. But then again terragrunt and terraform also have a bunch of differences.

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

#40

Post by IsaacSchlueter »

rzzzt wrote: post #24
pqdbr wrote: post #17

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 ), bu…

It's a fairly common occurrence (I think) that when you are running a query against some store and there is nothing to filter by, you get all the results back. Now the client has to sift through the result set and find products with an empty feature list on the receiving end. The fix is to add a "no features" placeholder feature and look for it when you are trying to find plans without any features.

I don't think that's 100% accurate implementation-wise, but the gist is definitely correct. Basically, yes, owing to the way that these things have to get mapped into Stripe's objects, having a plan without any features would make it really costly to reconstruct the model later, and we wouldn't be able to create a subscription to it anyway.

You can create a plan like:

    "plan:nofeatures@0": {
      "feature:donotuse": {}
    }
and then the customer subscribed to that plan will have a single $0 item in that subscription phase. (Tier could in theory do something like this automatically if there's a plan with no features, but figured since an empty plan is likely a mistake anyway, better to just let it be explicit.)

To the parent comment, there's nothing in PriceOps that theoretically says a plan must have features, this is just an implementation detail that's somewhat unavoidable.

Post reply on HN