My first thought is that if your product does not meet a client&#x27;s security policy, then it is not the right product for that client. There is nothing wrong with that, and a great deal right with it. It&#x27;s the basis of market segmentation.<p>Selling &quot;shrink wrapped&quot; software is a different business than SaaS. Support infrastructure is different...and probably less efficient. Distribution infrastructure is required. More importantly, customer expectations are different. The software company starts owning client decisions regarding platforms and hardware and configuration that are out of their control. And your client has told you that they want to run your software on configurations that reflect decisions that are outside your control. These could be dynamic, e.g. your company on the hook when they move from in-house hardware to AWS or Azure or Bob&#x27;s Discount Cloud Mart.<p>As far as pricing, my take is that it should cover the costs of going into an entirely new market segment. That means covering the cost of additional engineering, support, and sales. It should be priced for <i>serious</i> buyers, i.e. at <i>many</i> thousands of dollars per month. It should reflect the value the customer places on running your software on their hardware.<p>To put it another way, the approach to a client who runs your software on their hardware is as a consultancy. &quot;Nickling and diming&quot; is the core of successful consultancy. It&#x27;s a linear growth activity. The price should be just slightly less than the probable cost of the client reproducing your service with it&#x27;s own developers times the time value of money divided by the probability of it being successful. This is a big number which is why they are willing to pay for your service.<p>So my gut is, go big if you want to be in the consulting business. Otherwise, stick to product.<p>Good luck.