I agree that in general usage-based pricing makes the most sense (particularly as that is a good proxy for measuring how much "value" someone is getting from it), my biggest complaint was that the way they were trying to measure it was dumb and very outdated. It really only made sense in a world where everyone was still running on physical servers or VMs. I would certainly concede that pricing is a very hard problem for a product like this, but whatever pricing they come up with should at least map onto the system it's being used in. Basing it off of number of pages of PDFs generated might would make sense, but they insisted on knowing how many CPU cores I would be allocating (which makes little sense when it's deployed as a highly elastic lambda function!)

Salespeople often misunderstand value-based pricing. If a product costing V dollars is made of N parts, then each part provider claims their value is V, so they deserve V-$1.

A PDF conversion may be required for the end-users, but it doesn’t make the entirety of the value of the product. It just doubles it, as well as the N features before that. But although each feature doubles the value of the product, the order of features doesn’t matter; A PDF export might have been added as the second feature, but the 10th feature still doubled it.

> How do you price that “objectively” unless you’re given a breakdown of the company R&D expenses, operation costs and margins.

You ballpark how long it would take you to build something similar? You don’t need any breakdown for that, just a marginally competent engineer on staff.