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…
Billing Engines Don't Solve Pricing Problems
51–60 of 66 posts
Re: Billing Engines Don't Solve Pricing Problems
#52If 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.
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
#53Re: Billing Engines Don't Solve Pricing Problems
#54Earlier 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.
That'll be a fun config file.
Re: Billing Engines Don't Solve Pricing Problems
#55Re: Billing Engines Don't Solve Pricing Problems
#56Re: Billing Engines Don't Solve Pricing Problems
#57Earlier 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.
Unfortunately, pricing is unsexy, complex, full unknowns, no easily testable, and odd.
Re: Billing Engines Don't Solve Pricing Problems
#58To 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…
Re: Billing Engines Don't Solve Pricing Problems
#59Earlier 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.
Re: Billing Engines Don't Solve Pricing Problems
#60Concerned 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.