Why freemium pricing model for CRM / Online databases needs to change

October 13, 2010

The typical approach to pricing in the hosted web-apps space, particularly in the domain I am working on – which is CRM and Online-databases – is to have freemium plans with per-user pricing.

It is interesting to note that the average conversion rate in freemium apps is just 3%. That is, 3% of the users fund 97% of the other users who use the free versions.[1]

While there are a few service providers with seemingly generous “unlimited records”[2], I have seen web-apps offering generous free quotas to close shop/move away from this space, leaving their existing customers looking for alternatives and have also seen others reduce their quotas from something like 100,000 free records to just 1000 free records[3].

I believe such actions (leaving the market, or reducing quotas drastically) by service-providers, which can trigger strong reactions from users, are not something they would like doing. No one would like to piss-off their customers intentionally. The problem for these web-app service-providers is in trying to map the costs incurred – typically in terms of computing resources like CPU, bandwidth and storage, with the pricing model which is in terms of users and records. But to do this mapping is not an easy task, because it is not a simple function of the number of records and the number of users. Assuming a fixed set of users (pick any number between 2 to 5)..

Less records, less requests from users // least cost
Less records, more requests from users // moderate cost
More records, less requests from users // moderate cost
More records, more requests from users // highest cost

This is the simplest level. Next comes the number of write operations. This could be to add new records or to just keep updating existing records. So, for a given set of record limits and request limits…

Less read, less write operations // least cost
More read, less write operations // slightly higher cost
Less read, more write operations // considerably higher cost
More read, more write operations // highest cost

Trying to map it to a simple per-user, max-records based pricing is thus not an easy task. Just to be on the safer side, web-apps usually end up over-charging the least-cost users.

With iFreeTools CRM and Creator, we prefer to take a different approach, based on what really costs us money – the computing power, storage and bandwidth[4]. This means our free-version may not seem very much generous, but our paid-versions have substantially better value for money and also allow more user-accounts per application.

Also, our pricing plans are such that we don’t over-charge our paying customers to fund our free users. In a way, our free users pay for themselves – or so we believe – since our free plans our ad-supported. This enables us to provide generous quotas for our paid-users.

CPU based quotas are also planned to be incorporated, after which we plan to remove away the user-limits altogether and increase the record limits substantially. After all, it costs us just $0.15/GB/month (thank you Google App Engine).

Our pricing page is at http://crm.ifreetools.com/pricing

Do let us know what you think. You can also mail your thoughts to raj@sahasvat.com


[1] Freemium model – I am of the belief that freemium model works more favorably for vendors of installed-apps, where the only cost incurred for each freemium use was the download bandwidth. With hosted apps though, the computing resources for the free app users are to be provided by the service-provider, in the hope that they would turn into paid customers one day.

[2] “unlimited” quotas – I am really not sure how they can offer such a deal.. I guess they should have some limit which they do not say explicitly or their apps become unusable after some limit, that they know for sure it will not be a problem.

[3] reducing quotas from 100,000 to 1000 – of course, there was some backlash from existing user base, so they had to allow existing users remain with the old quotas, while restricting new ones.

[4] pricing based on costs incurred – Some may frown on the idea of pricing software based on the cost incurred, rather than on the value it brings to the business. Whether we like it or not, pricing of software tends to get lower and is most likely to reach a point where the software becomes just an add-on for the commodity platform services.


Grails to iFreeTools CRM

October 21, 2009

Had to gain some domain knowledge on CRM/SFA (Sales Force Automation) and provide a solution for a client, to host in their premises.

My client was not so interested in Python and preferred the use of Java for the solution, more so after knowing my past experience. So after more than a year into Python was back into Java, evaluating frameworks for use in the project.

The search lead me to Grails.

The “Convention over Configuration” and “Don’t repeat yourself” approach which Grails enables was a pleasure to work with. (Except, where I believed that grails was against the DRY principles – having to define “constraints”, even for the sake of maintaining the order of properties.)

But, it was a lot better than having to code XML configuration files. One could easily configure/code Servlet Mappings, Filters and Tags, without having to add/modify a single XML entry. And even better, one could get a compiled war (with all those XML files) and deploy it in any servlet container !!

In the next week or so, building a CRM/SFA prototype using Grails helped me pickup stuff from both the domains. And, the way in which Grails works, made me want to approach Python programming for Google AppEngine with the “Convention over Configuration” and “Don’t repeat yourself” approach.

Though Django enables such features, I was a bit biased against using the full pack, since that would require packaging a “lot of files” – so much that it exceeded the file limits of initial Google AppEngine hosting and needed a new feature (zip packaging) to enable those features. I am allergic to “lot of files”, especially if I will have to modify a few of them to have it working my way.

And with the meta programming features available in python, I believed that it could be easier to implement a simple version for my requirements.

The result of that effort is : iFreeTools CRM (Alpha)