Freemium Utility, Amazon FPS, & Platform Currency

There are some things in life and business you can only learn by doing... or at least planning for. So, it's not a surprise that the latest web "revelation" I've had, which are oft-inspired by the process of building BricaBox, has come as Kyle and I have started to architect our premium features and billing system; needless to say, it's an important part of the platform, given it's the way we're going to make money.

Prix Fixe Freemium

Traditionally, software sold on the "freemium" business model (where the base product is free, but some key features are paid) is neatly packaged around "sets" of premium features, wrapped up into carefully calculated monthly rates and sold via fancy names.

Think you didn't know what a "tall" coffee was? Makes as much sense as me buying "Pro" Flickr account. I'm no pro. I just want their service.

For reference, take this pricing sheet from the popular productivity/project-management app, Basecamp:

Or this one from Google Apps:

And this one from Harvest:

These "prix fixe" menus, of sorts, keep things simple for the developer and the customer, because there's a fixed grouping of features to a fixed monthly total, allowing the business to operate much like a magazine or a gym, selling a monthly or yearly subscription in return for a fixed set of services -- or, in the case of web applications, packaged Utility.

Also, "prix fixe" has been a fairly good way of operating a web businesses over the past few years, as it creates stable revenues and usually you can get away with up-selling features people didn't want (you may want more storage, but not a chatroom).

Finally, and perhaps most importantly, when you go to think about how to bill your users (from a software architecture and UI perspective), prix fixe has always seemed like the only option to bill your customers for recurring costs. Adding a billing and payments system to your site is already a huge pain, and the pricing models and APIs offered by payment gateways are kludges and severely penalize small transaction sizes. Until recently, selling subscription-based, prix fixe online software only made sense in this context.

Utility & Utility-Based Freemium

The point that people are buying subscriptions to Utility is a point that shouldn't go overlooked (look back three paragraphs ago). For a full overview of the term and its economic meaning, visit Wikipedia. Keep that one in mind, and also think about your local electric company as I go through these next points.

The way that Utility relates to the Web is that, increasingly, services are being broken apart in to smaller and smaller units, allowing people and machines to consume those units in smaller and units. Widgets, Facebook applications, niche social-networks, micro-formats, and OpenID are indicative of this process of software becoming more and more Loosely Coupled and interoperable on an increasingly granular level.

It's like electricity, because at first there were bunches of providers, plug makers, appliance makers, etc, so there were different numbers of wires, sizes of plugs, and no standardization to what voltage and amperage to run through the system.

The world loved the new invention, but it was a mess. Like the first ten years of the Web. But now we're moving towards Utility, and pieces are coming together.

(As an aside, it should be noted that this trend of the web moving to a utility based model is not one I'm pointing out for the first time. The forecasters have been talking about it for a while. See this this article from 2001 in WIRED, called The Grid: The Next-Gen Internet?, as one single example). You can really see this model in the birth of the WWW, and Tim Berners-Lee's vision of the Semantic Web.)

Back to billing, however, you'll see that leading the charge in the Utility-Based Freemium model is Amazon.com and their Amazon Web Services (AWS) group.

As many are aware, AWS provides services such as S3 (for storage), EC2 (for computing), SQS (for process management), and Alexa (for web stats). All of these services are metered and billed at a mirco-level. For instance, EC2 is billed by the hour, instance, and per GB of data transfered. S3 breaks its billing down to the GB (and after trying the service out by backing up about 10 MB of photos, I was getting a monthly bill of $0.05).

Amazon Flexible Payments Service (FPS)

This brings me to one of Amazon's most recent service, called "FPS." With FPS, software providers can begin to build their web applications using the same, innovative billing platform that allows Amazon to bill be $0.05 and not have its margins completely disemboweled by the fees payment gateways and the banks traditionally charge.

And this is the significance: With FPS, Amazon allows other companies to follow suit and make a business based on selling utility, rather than prix-fixe subscriptions. This is good for the Internet and for web businesses, because it allows technology to be sold on its own terms, not those a gateway dictate.

In fact, FPS allows many other types of businesses to sell on their own terms. Check out this video about a car insurance company changing their business model to a per-mile rate using FPS. Insurance per mile! That innovation!

Significance to Platforms

To close out this long-winded and poorly-structured post, let me address the significance of FPS we see on platforms such as ours.

You see, with products (like Basecamp, Harvest, and Google Apps) you can get away with selling packages, and the building a simple billing system to handle them.

But for a platform, where lots of parts are coming together, some which will be paid for and some which will not be paid for, some on a monthly basis, and some on a per-use basis, one would have to create a highly sophisticated billing and payments system.

For instance, I can't imagine how much work went into developing Ning's a la carte system, but I can imagine it weighed down their sizable team of developers for quite some time... and I can also imagine that they're just as embedded in their current system as they are in the rest of their platform. Here's a screenshot of their menu:

What happens when they want to include a metered service? Chances are, they can't.

But, by taking advantage of the way FPS abstracts payments from billing, we are able to sell customers any combination of services they may want, using a token system on our platform, and then link the cost to the AWS payment system and bill them for as much or as little of our service that they use.

As our platform builds out, and as we incorporate more and more of the utilities of others (data sources, blocks, etc), FPS will give us the ability to scale our billing and services together, without getting weighed down by it at the same time.

And while abstracting payments and billing allows us to mix and match monthly-recurring costs with one-off costs, we can take full advantage of that abstraction and build a token-based economy within our platform. This means that, down the line, we can easily give publishers tools for making money, give our users ways of earning services, exchanging tokens for information and access, rewarding behavior, etc... and make the whole thing a lot simpler to implement, account for, and manage on our end.

While we still have yet to build the billing and payments side of things, it's the process of planning and architecting which has brought out this appreciation of token-based systems and Amazon's FPS (which has been out for several months already).

It's a perfect combination, though: a fresh-start, a token economy, billing abstracted from payment. We're pumped (and can't wait to start making money!).