Vendor Trap: Paying for Industry Features

I've noticed that the charity sector is far less demanding of its software vendors than my corporate customers were back in the day. Or perhaps it's a function of size, as most of my customers were larger in the corporate world compared to those in the charity sector.

For example, I don't think it's acceptable for a software vendor to charge customers for building new features. From an economic standpoint, the whole idea of a software vendor is to gain economies of scale by building the same features and offering them to many customers. Although it's a favorite topic of mine, I am excluding customer-specific customizations here. I'm only talking about features that are used by more than one customer and are built into the underlying product.

I've recently encountered a couple of situations where a vendor was asked to provide a solution to a problem, but it couldn't be adequately addressed by the existing product. In one instance, I was initially excited about the vendor's willingness to extend their product to incorporate a new feature. This feature would have been beneficial across the industry. However, I was gobsmacked when I realized they expected my customer to pay for it.

The second example was even more extreme. A change was needed due to an update to the SCHADS award. In any other industry, customers would assume the vendor was well aware of these changes due to their deep industry knowledge and would be ahead of the curve, anticipating these updates. Yet, in this case, the vendor offered to make the change as a paid engagement.