Feedbacks - New app pricings - thoughts on charging per webhooik or per product variants

Shopify App Store
,
1

Hello,

With the new app pricing being live we’re thinking of how to improve our pricing to make it more flexible and also more fair, especially for small merchants.

I’m asking here so see if anyone has thoughts to share regarding potential upcoming good practices with the new app pricing.

We’ve got an app for which our server costs are tightly coupled to the volume of webhooks, the number of products, but also the number of variants

They are two different things, but they share one in common, to the merchant’s eyes they’re not something they would be used to get charged for.

Regarding the webhooks. We’ve got merchants who have large volumes of webhooks because they have other apps constantly synchronizing data, or overnight full catalog re-sync which can be huge.

These patterns force us to optimize our webhook processing logic in a way that benefits only a very few, and also forces us to overload our servers to handle the load.

At the same time they’re not necessarily responsible for the volume of webhooks.

  • It could be poorly optimized apps from other developers that just carelessly update products when unnecessary.
  • Or it could be totally legit updates - but the webhooks themselves come with limitations that make it costly to process for us, such as limited debouncing capabilities on shopify’s side, notably when you need to listen to variants, or metafields.

Charging the most demanding merchants, could also be a way to decrease the cost for the least demanding ones.

I was wondering if other app developers have already had a thought on that and willing to share?

Just keep it easy for merchants and take this load on us? Or, add a small extra fee for it for merchant who have a lot of webhooks?

Now regarding product variants. Actually one of our largest merchant has a catalog of a modest size in terms of number of products, but because each products can have a lot of variants (sometimes up to 2000 variants on a single product), they actually became the most demanding merchant for us in terms of server load because dealing with variants is not as straightforward as dealing with products.

I was wondering if we would be fair to charge for the catalog size based on the number of variants rather than strictly the number of products.

Any experience or insights is welcome to share!

Thank you.

2

Consider a combined “catalog complexity score” (products × avg variants) as your billing unit, wrapped in friendly tier names like Starter / Growth / Scale. Keeps it transparent without exposing raw technical metrics.

whatever you charge for, make sure the merchant can see and control it in their dashboard. Surprise bills for things they didn’t knowingly do will tank your reviews.

On webhooks: Charging per webhook volume is tricky because merchants don’t control what other apps do it can feel unfair and create support headaches. A better approach might be tiered plans based on “catalog activity level” (low/medium/high sync frequency) rather than raw webhook counts. That way it’s a merchant behavior signal, not a technical metric they don’t understand.

On variants: Charging by variant count instead of product count is actually more defensible and easier to explain “you pay based on catalog size” maps cleanly to variants since that’s where the real complexity lives. Many merchants intuitively understand that 1 product with 2000 variants is “bigger” than 100 simple products.