Hacker News Reader

Comment by pqdbr | Hacker News Reader

From the Pricing JSON page, on the 'Why Each Plan Must Have At Least One Feature' question, it says:

> Without this restriction, it would be significantly more expensive to fetch your pricing model from Stripe's data.

I didn't quite get that. I understood that application code should reference features (and not plans directly) so it becomes easier to change plan structure (via https://priceops.org/4-entitlement), but that's not the reasoning laid out here, is it?

View on HN

It's a fairly common occurrence (I think) that when you are running a query against some store and there is nothing to filter by, you get all the results back. Now the client has to sift through the result set and find products with an empty feature list on the receiving end.

The fix is to add a "no features" placeholder feature and look for it when you are trying to find plans without any features.

I don't think that's 100% accurate implementation-wise, but the gist is definitely correct. Basically, yes, owing to the way that these things have to get mapped into Stripe's objects, having a plan without any features would make it really costly to reconstruct the model later, and we wouldn't be able to create a subscription to it anyway.

You can create a plan like:

    "plan:nofeatures@0": {
      "feature:donotuse": {}
    }

and then the customer subscribed to that plan will have a single $0 item in that subscription phase. (Tier could in theory do something like this automatically if there's a plan with no features, but figured since an empty plan is likely a mistake anyway, better to just let it be explicit.)

To the parent comment, there's nothing in PriceOps that theoretically says a plan must have features, this is just an implementation detail that's somewhat unavoidable.

Reply on news.ycombinator.com