PriceOps? Really?
The idea that pricing and billing are separate concerns seems entirely obvious to me.
Billing Engines Don't Solve Pricing Problems
41–50 of 66 posts
Re: Billing Engines Don't Solve Pricing Problems
#42I think they abstracted the problem so away that they have no idea what they are talking about. Having a single file that contains all your plans and make both your app, marketing pages, and Stripe work from it is trivial and is just good engineering. It's not a "Pricing Engine" or a "Pricing Stack".
Re: Billing Engines Don't Solve Pricing Problems
#43The 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 describes (the ability to quickly iterate on pricing model). Stripe and co. are relegated to simply processing payments when they are due, which avoids the lockin of their value-add services. I'd love to see more in this space but honestly KillBill is the most rounded that I've found.
Re: Billing Engines Don't Solve Pricing Problems
#44If 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.
The problem is not so much complicated pricing as grandfathering existing customers every time pricing changes (generally considered a best practice to avoid pissing off your customers). Then you end up with lots of gnarly conditional logic around anything that touches billing because you have to support a bunch of different pricing/billing versions, different upgrade/downgrade paths, etc. It gets even worse if your…
I've worked on pricing. There's a lot of complexity, even with a fairly simple product. Our product was a monthly subscription with 4 different tiers. Complications included:
- Annual plans that include a discount vs paying month to month.
- Introductory pricing (and how long that lasts)
- Promo codes
- Dealing with multiple currencies
- Pricing on iOS, where you have to pick on of their "pricing tiers"Re: Billing Engines Don't Solve Pricing Problems
#45I think they abstracted the problem so away that they have no idea what they are talking about. Having a single file that contains all your plans and make both your app, marketing pages, and Stripe work from it is trivial and is just good engineering. It's not a "Pricing Engine" or a "Pricing Stack".
This is a naive view but I'll let someone else elaborate
Re: Billing Engines Don't Solve Pricing Problems
#46I think they abstracted the problem so away that they have no idea what they are talking about. Having a single file that contains all your plans and make both your app, marketing pages, and Stripe work from it is trivial and is just good engineering. It's not a "Pricing Engine" or a "Pricing Stack".
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.
Re: Billing Engines Don't Solve Pricing Problems
#47To 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 track everything system" does not mean a customer can transition from one plan to another plan without massive problems.
Big new plans that are very different from previous plans often come about because of large-scale reorganizations of the product. The issue is that with a big change in the way the product is organized, there might be application state under plan A which is literally unrepresentable under plan B, requiring the customer to manually migrate their application state from plan A to plan B, since it's impossible to do safely in an automated way.
I'm currently living through this fundamental oversight : )
Re: Billing Engines Don't Solve Pricing Problems
#48Earlier 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.
I think recognizing it's a different problem than billing and have it as a different entity is important. And of course that knowledge needs to be materialized into a technical block.
Now, I'm totally with you that calling that an "engine" is misleading for 99.9% of businesses. In most cases that's a configuration file, or a business class if they're dealing with more user behavior check, calculations or conversions.
Re: Billing Engines Don't Solve Pricing Problems
#49Earlier quoted context omitted.
The difficulty of pricing lies on actually pricing things, there is no missing technical brick, but missing knowledge.
I think recognizing it's a different problem than billing and have it as a different entity is important. And of course that knowledge needs to be materialized into a technical block. Now, I'm totally with you that calling that an "engine" is misleading for 99.9% of businesses. In most cases that's a configuration file, or a business class if they're dealing with more user behavior check, calculations or conversions.
Yes definitely. The domain of "Pricing" things is a giant industry; i.e., the accounting and finance industry.
Re: Billing Engines Don't Solve Pricing Problems
#50The 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…
Another one I've seen around before is Hyperswitch