The Freemium business model is normal for consumer applications, but can it work for enterprise software? Freemium usually means a free service with an "up sell" to paid premium subscriptions. Examples include Skype, LinkedIn, Flickr, Ancestry.com, Typepad, Dropbox, and many others. Freemium differs from Free Trial in that a free trial is the fully functional product but only for a limited time. Freemium is always free, but you can purchase additional features or service for a premium price.
Freemium business models usually involve a Free service, sometimes time limited or feature limited, supported by advertising. The ads rarely cover costs. The goal is to convert these free users to paid subscriptions. Most consumer services start with a $10 per user per month subscription and scale up to $20 or $50 per month based on a small, medium, large usage scale.
Enterprise software is also using the Freemium model, sometimes with higher prices commensurate with the power and functionality of the product. They all have slightly different measurements and cut-off points, but most have some notion of small, medium, large.
Most companies see a 1.5% to 5% conversion rates, with most of them averaging around 3%. That doesn't sound like much but they are reaching tens of thousands to hundreds of thousands of users...sometimes millions.
Here is some math. 100,000 free users convert to 3,000 paid users. If they pay $50 per user per month, that is $150K a month or $1.8M per year. That is an excellent revenue stream for small startups that typically have 3 to 5 employees. And, it is an annuity stream that continues to grow every year. By the 3rd or 4th year these small companies can be generating $5M to $10M a year, still with less than 10 employees. Most of these small companies don't take Venture Capital so they own the whole company. It is a pretty good cash flow business.
Recently at Google IO I moderated an all-star panel of VCs on the subject of Freemium in the enterprise.Making Freemium work - converting free users to paying customers - Venture Capitalists, Brad Feld (Foundry Group), Dave McClure (500 Startups), Jeff Clavier (SoftTech VC), Matt Holleran (Emergence Capital) and Joe Kraus (Google Ventures) discussed strategies for building free products that can be upgraded to paid versions.
Some key points from the panel;
Watch the video for more details and insight. This group of VCs has built lots of companies based on the Freemium business model. They have some great insights.
The programming language of Google Apps Script is JavaScript (ECMAScript). JavaScript is a very flexible and forgiving language which suits us perfectly, and there's also a surprising amount of depth and power in the language. To help users get into some of the more useful power features we're starting a series of articles introducing some more advanced topics.
Let's say we want to create an object that counts the number of occurrences of some event. To ensure correctness, we want to guarantee the counter can't be tampered with, like the odometer on your car. It needs to be "monotonically increasing". In other words, it starts at 0, only counts up, and never loses any previously counted events.
Here's a sample implementation:
Counter = function() { this.value = 0; };
Counter.prototype = { get: function() { return this.value; }, increment: function() { this.value++; } };
This defines a constructor called Counter which can be used to build new counter objects, initialized to a value of zero. To construct a new object, the user scripts counter = new Counter(). The constructor has a prototype object, providing every counter object with the methods counter.increment() and counter.get(). These methods count an event, and check the value of the counter, respectively. However, there is nothing to stop the script from erroneously writing to counter.value. We would like to guarantee that the counter's value is monotonically increasing, but lines of code such as counter.value-- or counter.value = 0 roll the counter back, breaking our guarantee.
Most programming languages have mechanisms to limit the visibility of variables. Object-oriented languages often feature a private keyword, which limits a variable's visibility to the code within the class. Such a mechanism would be ideal here, ensuring that only the methods counter.increment() and counter.get() could access value. Assuming that these two methods are correctly implemented, we can be sure that our counter can't get rolled back.
Javascript has this private variable capability as well, despite not having an actual keyword for it. Let's examine the following code:
Counter = function() { var value = 0; this.get = function() { return value; }; this.increment = function() { value++; }; };
This constructor gives you objects that are indistinguishable from those built with the first constructor, except that value is private. The variable value here is not the same variable as counter.value used above. In fact, the latter is undefined for all objects built with this constructor.
How does this work? Instead of making value a member variable of the object, it is a local variable of the constructor function, by use of the var keyword. The get and increment functions are the only functions that can see value because they are defined within the same code block. Only code inside this block can see value; outside code does not have access to it. However, these methods are publicly visible by having been assigned to the this object.
Limiting visibility of variables is considered a good practice, because it rules out many buggy states of your program. Make sure to use this technique wherever possible.
Cross-posted from Google Apps Script Blog
by: Jason Ganetsky, Software Engineer, Google Apps Script
