Right, but what the article tries to point to is places where they don't see whether it's good or not after the feature is shipped.

If you know it is going to be a nightmare to support, it will consume tons of resources (cpu/storage), and nobody wants to pay for it (or not pay enough to cover its costs), it is not good.

As has been mentioned many times on this site, it is very easy to sell $2 for $1 all day long.

> nobody wants to pay for it (or not pay enough to cover its costs), it is not good.

And how do you know this in advance?

You ask them.

‘Will you pay an additional $x/mo for this feature?’

You can estimate your AWS costs for what the feature would cost for that user.

You can estimate dev and implementation time.

It doesn’t even have to be 100% accurate, but if the numbers come nowhere close to making sense, don’t pursue this further.

Now, there may be a future time where some fundamental cost changes, and it is worth considering again.

It sounds nice, but it doesn't work very well.

Users lie. Not even maliciously.

Clients will say they'd pay for it, then when you deliver it they'll say they realized that your competitor provides that and everything else that is really important to them in the standard fee. The competitor is actually no better, and would require the same amount of development to get to parity in other areas, but they win by claiming that everything will be rainbows.

Clients will say they'd pay for X, but once you deliver it they'll suddenly realize that it won't actually work for them until you also implement Y, but they won't pay any more for X+Y than they would for X alone.

Clients will say they'd pay for X, but once you deliver it they'll have shifted direction or something has changed and they don't need it anymore.

Clients will say they'd pay for X, but once you deliver it and they start using it they'll discover that it's not at all what they actually needed.