
How to license our SAAS product - mukgupta
We have a SAAS product and we offer it on a monthly&#x2F;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&#x2F;yearly license?
2) Assuming, I go for lifetime license, how do I price it. Our costliest API plan currently comes as $300&#x2F;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&#x27;ll have all the code and technically they don&#x27;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?
======
brudgers
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.

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.

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 _serious_ buyers,
i.e. at _many_ thousands of dollars per month. It should reflect the value the
customer places on running your software on their hardware.

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.

So my gut is, go big if you want to be in the consulting business. Otherwise,
stick to product.

Good luck.

------
mymotta
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?

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...

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.

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.

If you want to eat Indian food, don't go to an Italian restaurant.

good luck

