Live data from Hacker News

Billing Engines Don't Solve Pricing Problems

tier.run

51–60 of 66 posts

Re: Billing Engines Don't Solve Pricing Problems

#51

The idea of splitting off payment plans into its own abstraction is super interesting. Personally I would really like if the abstraction layer also was independent of the payments processor, currently it seems heavily dependent on Stripe. Even though I currently use Stripe I find them to be untrustworthy and don't want anything that ties me to them even further. And more generally, using a platform built on top of a…

Agreed on not becoming too dependent on Stripe. Billing (or in this case, pricing) is the last thing you want under another entity's control. There is surprisingly little in the OSS space around this, but I can recommend KillBill (no affiliation). Although it is one component that does combine billing and pricing model, they are separate abstractions within KillBill, that provide the exact benefits the article descri…

I haven't used any of these tools, but I'm starting to explore them. The other one I found was https://github.com/getlago/lago

Re: Billing Engines Don't Solve Pricing Problems

#52

If pricing your product is so complicated that you need an entire separate product to manage it, you are probably indulging some MBAs in their own make-work projects too much. Non-transparent pricing is a huge red flag to potential customers.

A previous job was working at a supermarket's online store. Supermarket's have all sorts of weird specials eg "4 pies for $5" or "a pie and a coke for $3".

We were running into problems when we had large test baskets ( $500 always, $200 sometimes ) that there would be so many combinations of specials that calculating the best way to apply them was causing CPU load and timeouts.

Fix was somebody sat down, remembered their CS classes and applied a more scalable algorithm. Problem fixed.

Re: Billing Engines Don't Solve Pricing Problems

#53
We have probably more complex pricing than what Tier seems to handle, but, it's only a handful of tables and not a significant amount of code to handle it all. I didn't think this was a terribly hard problem and a custom solution seems better for tailoring the system to your particular needs?

Re: Billing Engines Don't Solve Pricing Problems

#54

Earlier quoted context omitted.

This is a naive view but I'll let someone else elaborate

The difficulty of pricing lies on actually pricing things, there is no missing technical brick, but missing knowledge.

Did you previously get a new-customer discount on a previous order? What promotions are in effect? Are you eligible for that promotion based on your location or customer type? Are there bundle discounts that can apply? If you build an order, can we recommend eligible offers based on what is in the order already?

That'll be a fun config file.

Re: Billing Engines Don't Solve Pricing Problems

#56
I'm working on an internal pricing service that interacts with Azure. I'm not looking to use this service since I certainly would not want to create yet another external dependency, but will agree that pricing can be complex. For example, I was a bit shocked that there are over 450,000 individual things that Azure can charge you for.

Re: Billing Engines Don't Solve Pricing Problems

#57

Earlier quoted context omitted.

The difficulty of pricing lies on actually pricing things, there is no missing technical brick, but missing knowledge.

Did you previously get a new-customer discount on a previous order? What promotions are in effect? Are you eligible for that promotion based on your location or customer type? Are there bundle discounts that can apply? If you build an order, can we recommend eligible offers based on what is in the order already? That'll be a fun config file.

I am sure this doesn’t solve this though. It’s hard question to answer on individual basis, require some complex logic, and for sure some coding. You won’t be able to solve this with a “Pricing Stack”.

Unfortunately, pricing is unsexy, complex, full unknowns, no easily testable, and odd.

Re: Billing Engines Don't Solve Pricing Problems

#58

To expand, pricing engines also don't solve other product/licensing problems. At $dayjob, I work on a team that seems to have independently designed almost exactly what you've outlined in PriceOps.org (in January of 2022, right when PriceOps was being initially written), but we've also then had to use it for a year and change. The biggest thing we've learned is: > Just because you have this new "can represent and tra…

well that's not pricing engine job

Re: Billing Engines Don't Solve Pricing Problems

#59

Earlier quoted context omitted.

Did you previously get a new-customer discount on a previous order? What promotions are in effect? Are you eligible for that promotion based on your location or customer type? Are there bundle discounts that can apply? If you build an order, can we recommend eligible offers based on what is in the order already? That'll be a fun config file.

I am sure this doesn’t solve this though. It’s hard question to answer on individual basis, require some complex logic, and for sure some coding. You won’t be able to solve this with a “Pricing Stack”. Unfortunately, pricing is unsexy, complex, full unknowns, no easily testable, and odd.

That's precisely what this type of tool targets fixing.

Re: Billing Engines Don't Solve Pricing Problems

#60

Concerned about the number of lightweight marketing blog posts making it to the front page of HN. It’s like it’s part of the “marketing to devs” playbook at this point.

I noticed that that guy who posted his "I asked HN founder X and here is their top 10 responses" blog got flagged. I think that is a bridge to far in building a self brand with content marketing.
Post reply on HN