We have a SAAS product and we offer it on a monthly/yearly subscription. Once of our products is an API which is also offered on a subscription basis.(Price range, $75-$300 per month). One of our clients recently requested that we license our APIs to them, to be run on their servers for security reasons.<p>1) Should I offer it for lifetime/yearly license?
2) Assuming, I go for lifetime license, how do I price it. Our costliest API plan currently comes as $300/month. ?
3) If I offer it on a yearly license, how do I make sure that they renew it. Since, ours is a nodejs app, they'll have all the code and technically they don't need to renew anything to make it work.
4) If I go for yearly license, do I just offer it for Monthly pricing X 12?
My first thought is that if your product does not meet a client'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's the basis of market segmentation.<p>Selling "shrink wrapped" 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'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. "Nickling and diming" is the core of successful consultancy. It's a linear growth activity. The price should be just slightly less than the probable cost of the client reproducing your service with it'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.
Good and important questions with broad implications for your company. Your current business model is a subscription-based offer of SaaS. You also offer a hosted API under a subscription model. If I understand correctly, access to the API is not usage based. Rather, you currently host the API on your company servers and provide a subscription to use this API via some variably-priced and tiered RESTful interface. So, the questions you ask can be re-stated as follows: should we also offer, alongside the subscription model, a RTU (right-to-use) license-based model for your product. But more is needed that adds significant complexity: you are also being asked to provide source code for integration with the customer's code base. If you agree to provide such a source license to your code, how do you price such an offer?<p>My first advice is that you should consider pricing mechanics as secondary. The primary issue is business model; whether and how you can work in the very different worlds at the same time. You need to sort through the issues carefully. The SaaS model is very different from the more traditional license-based software offers. I won't repeat the abundance of thinking on this here other than to say that (a) metrics you use to measure and guide your success for the SaaS offering are very different from what you will need for a license model, (b) the deployment model for SaaS is very different from source-based licenses. For SaaS, you have complete control over your code base, how and when to issue revisions to your cloud-based services. You have zero control over the source distribution, (c) product support processes are very different between the models, because in the source code model you need to understand the customer's code too! etc., etc...<p>Let me suggest that you DO NOT offer the source license model alongside of your SaaS subscription model. They are different enough to make it very hard to manage the baseline jointly for both offers. And, the significant additional complication of source-based licensing will make it nearly impossible to manage together. I think this "opportunity" is a sure way to kill your SaaS company.<p>Rather, you can consider for the particular customer a ONE-TIME SOURCE CODE LICENSING deal, where you sell the source as-is. To make is easier for the customer you can provide some nice documentation on internal frameworks and interfaces. Make sure that you write careful language in the contract to ensure that the customer will not compete with you in your primary business areas (this may not be trivial). Pricing must have NO RELATIONSHIP whatsoever with your SaaS pricing model. It should be based on value of the solution to the particular customer. Once you have this number, double it. Then include pricing for 1 year support (with some bounds, e.g., not more than, say, 10 hours per month) for a fixed fee and an option for the customer to buy additional support for $$ per hour beyond the built-in 10 hours.<p>If you want to eat Indian food, don't go to an Italian restaurant.<p>good luck