The costs of free

A talkback commenter took me to task yesterday for an assertion I made (repeating Chris Anderson's line from his book Free: The Future of a Radical Price) that "The cost of distributing content and software online has fallen close to zero." chris@... retorted:

"Phil, you are close enough to the business to know that this is just not true. I've been in plenty of budget meetings ... and seen the costs in the publicly traded SaaS companies to know that Capital Expenditures is a big chunk of the costs."

So I thought I'd follow up today by running through the various elements of cost that a provider of free software may or may not bear — and by extension, identify those costs that customers will expect you to bear if you decide to charge a price. This is especially timely given the news emerging yesterday that PayPal is preparing an API that providers will be able to use to collect, aggregate and distribute micropayments, since that could motivate quite a few new entrants into paid on-demand services. As the discussion below makes evident, there's quite a delta between free and paid, because adding a price instantly adds a lot of additional infrastructure costs. So there are limits to how micropayments can work.

I did qualify my assertion about the cost of distributing software online. Here's the fully hedged version from my post yesterday:

"Software with mass market appeal — so long as it’s easy to develop, operate, support and maintain — now costs virtually nothing to deliver to customers."

Now let's dig into those components and see what's really involved in driving the costs of software distribution as close to zero as makes no difference.

• Scale. Mass market appeal is crucial because you need to be able to share the infrastructure costs across many thousands of users. If it's going to cost more than a few pennies per month to operate per user, it's unlikely to prove viable. It goes without saying of course that you have to be running on a massively shared multi-tenant architecture if you're going to get anywhere close to those economics.
• Usage patterns. You want an application that's used occasionally by the majority of users rather than one that everyone uses intensively. PaaS provider Bungee Labs did some analysis last year for the costs of operating various types of business application based on Amazon-style pay-by-usage pricing. As I reported at the time, it estimated the monthly cost of an intermittently used application at anything from 48c down to as little as 2c per user per month.
• Limited functionality. It goes without saying you probably want to put some limits on what your free version can do, especially around infrastructure costs that could escalate rapidly, such as high-volume storage, mass emails, intensive transaction processing and frequent calls to external services. You also want to hold back some incentive to encourage prospects to upgrade to your paid version, if you have one.
• Sales & marketing. You need a viral application that sells itself, because if you have to invest any significant amounts in marketing spend or sales people for a free offering, you'll rapidly run out of cash. If you look at the published accounts of listed SaaS providers, you'll see this is their biggest element of spend.
• Development. The cost of creating the application is likely to be your largest sunk cost. You can reduce the cost by using open-source development and hosted deployment platforms — and it helps if your developers will work for peanuts — but unless you're expecting to reach huge volumes of users, avoid complex development projects. The simpler you can make the application, the better.
• Operations. Some listed SaaS providers spend as much as a third of revenues on operations, but the most efficient of them have managed this figure down to below 10 percent of revenues. Remember that's for enterprise-class infrastructure and complex business applications that probably have more functionality and usage than most free offerings will aim for. Free providers can massage those costs even lower by stripping out some of the following.
• Support. Users won't like it, but stripping out support is one of the simplest ways to reduce operational costs for a free offering. The Web giants are past masters at this. For good measure, slap on a 'beta' label or call it a 'labs' version. If users complain about the lack of support, offer a paid support option.
• Maintenance. Keeping your application up-to-date is another overhead you can limit by choosing wisely. Write to a stable, well-supported platform, choose a business process that's relatively timeless and unchanging, and avoid categories that are subject to frequent regulatory updates or that vary between jurisdictions, such as HR and financials.
• Availability/performance. People will still complain when your service goes down or runs slow, but no one can reasonably expect three-nines availability or consistent sub-second response times for a free app, can they? (Unless you're demonstrably raking in profits from your ad-funded or freemium strategy). It's astonishing how much it adds to your operational overhead to provide a truly resilient service. Portent Interactive, one of the providers affected by last week's Fisher Plaza colocation fire, spelt out the trade-offs:

"Portent had only one way to avoid this outage: Host all web sites in two physical locations ... The problem with this solution: It's expensive. Extremely expensive. It requires that we duplicate the hosting environment — hardware and software — and that we constantly keep both hosting locations in sync. For a once-per-decade power outage, the cost/benefits balance just doesn't work. However, cost/benefits analysis doesn't feel as good right after your sites are down for 26 hours. So Portent will be planning and offering two additional services ... These services will cost extra."

• Customer administration. A huge area of cost that you skip by going free is all of the administration required to measure usage, bill for it, collect payments, manage disputes, monitor and report on service level compliance, so on and so forth.

All of these costs that providers of free on-demand services can avoid suddenly become costs as soon as you start charging. That creates a huge delta on the supply-side between free and paid — you need to be able to charge dollars per month rather than cents, because you'll have a lot of extra costs to cover. But you also need to add significant perceived extra value, since as Chris Anderson observes in his book, experiments testing consumer psychology have found there's a delta between free and paid on the buy-side too. As quoted in Malcolm Gladwell's New Yorker review:

"From the consumer's perspective, there is a huge difference between cheap and free," Anderson writes. "Give a product away, and it can go viral. Charge a single cent for it and you're in an entirely different business ... The truth is that zero is one market and any other price is another."

The other complication in this, as several other Talkback commenters mentioned yesterday, is that some market players will use free as a means of gaining market share because they're either too wealthy or too financially incompetent to mind the costs. So even if you've worked out a perfect model to use free as a means of acquiring paying customers, some miscreant may come along and skew the market in ways your model doesn't reflect. As with any emerging business model, free and freemium involve lots of risk. Take care.