Product variants (multiple prices per product)

[coopbri]

In the real world, 1 product might have, say, 3 pricing tiers, and perhaps 2 pricing frequencies (e.g. monthly, yearly). In this case, a single "real" product would be modeled as 6 "Polar products". Multiply this by 2 for the hosted Polar sandbox and that makes 12 Polar products to maintain for a single true product. Naturally, this does not accurately, relationally map to the way a business' offering is structured. This can cause maintenance issues such as product drift.

Stripe allows this modeling for reference: https://docs.stripe.com/products-prices/pricing-models#flat-rate

I started a related thread in Discord: https://discord.com/channels/1078611507115470849/1351342280128069685

[frankie567]

Hi @coopbri 👋

We deliberately took the decision to not implement product variants as they exist in the industry (see here).

The rationale behind this is the following: if you look closely, variants are actually products that are somehow grouped together in a bucket. They support the same set of features (pricing, entitlements, etc.), but are managed at a deeper level. If you look at Lemon Squeezy for example, their UI is quite confusing because of this. With Stripe, a product is a just a shell to a set of prices — but you actually end up using almost exclusively prices in their API (typical thing: when you create a Checkout Session there, you have to pass Price ID, not products!).

So, we made that choice to actually treat everything as a product. It's clearer and most straightforward to understand. Since our approach with benefits and custom fields is very modular, it's quite easy to come up with """variants""" of the same product, you just need to set the pricing and select the benefits you need.

---

Admittedly, the only tedious part might be the title and description. From our experience, it has not been a big deal for our users. But we have a few QoL ideas to improve that down the road:

• Duplicate products
• Batch update operations
• Tags

[coopbri]

Thanks for responding. I did see the rationale you linked previously. Even though this doesn't model real life relationally (1 product has various pricing models), I understand the design decision is not planned to be changed and you have no intention of matching e.g. Stripe's approach. Shopify, although in a slightly different wheelhouse, nails this abstraction with their variants imo. No problem, the product is yours, I am just offering feedback and thoughts as a user of other similar platforms who enjoys those models.

With the current state, then, the issue I'm more concerned about is long-term drift, which you touched on (title and description). "From our experience, it has not been a big deal for our users" -- since Polar is relatively small, this isn't a huge surprise to me, but I think as your userbase grows you will encounter some more friction with this.

The QoL ideas sound great, and would mitigate some of the concerns I have with this. Appreciate all this food for thought!