Software Has Marginal Cost
Posted by Bob Warfield on January 9, 2011
Every now and again I see the old chestnut trotted out that Software has no marginal cost. It’s used for all sorts of reasons. The gut feeling that it is true is probably at the heart of most people’s justification for why piracy is okay, for example, not that I’m saying most people think it’s okay. This time around, I was surprised to see it brought up by fellow Enterprise Irregular Basab Pradhan. Basab has a long history in the world of software, and so should know better. Nevertheless, in talking about whether app stores are worth the 30% or more they take of the revenue, he remarks:
Is the 30% cut of revenues too much? It depends on how much you expect your revenues to go up by. After all, software has no marginal costs. Every dollar of incremental revenue is a dollar of incremental profit (before taxes).
There is, of course, software that behaves as Basab says, but it has certain distinctive qualities:
– It is never updated, so there is no marginal cost to keep an engineering team running. This of course is the problem with any big professional services investment–you’d better hope you don’t need to update whatever they built. But it’s really a problem for all software that is not absolutely the most casual stuff you rarely use and then throw away. Someone has to keep it secure, fix bugs, and hopefully continue to innovate. One of Basab’s examples in his post is Evernote. As an Evernote user, it isn’t the kind of software I would want to see go without an engineering team. In general, if people didn’t care about this, they wouldn’t pay the ridiculous maintenance fees most big software vendors charge.
– It is not SaaS. Clearly SaaS as a service has some marginal costs. While it is true that an app downloaded from an app store may not be SaaS, it is not true that it must not be SaaS. My view is that all software benefits from having some SaaS component or other. Even if all that component does is keep your software up to date, there will be marginal costs to keep that SaaS infrastructure running. Of course if the software is never updated, this may not be an issue.
– It is unsupported. Support is one of the dirty little marginal costs of all software. There is a reason it appears where it does on the financial statements of many companies, coming out as an immediate hit on the gross margin. Ditto the remarks on ridiculous maintenance fees.
There are bound to be other marginal costs I can drudge up, but the point is made. The question to ask yourself if you come across some software with no marginal cost is whether you want any part of it. No support, no updates, no connection to any online service. Some software is so far off my critical path, I figure, why not? Most of it isn’t. Have you been involved with much software that has been “sunset”, “coasted”, or any of a number of other euphemisms for abandoned? It’s no fun unless said software is extremely simple and does what you need of it immediately. If it doesn’t, don’t keep fiddling, go find yourself some real software. If we had more people thinking of how to manage software’s marginal costs at a profit, we might have longer lived software companies and fewer examples of customer abuse like Dim Dim’s.
A more interesting thought on whether the app stores are worth it is to look at how much revenue these days is coming via in-app purchases, which are starting to overtake app store purchases. Of course you’ll probably need some marginal software costs to be able to deliver anything of value via in-app purchase, but now you’ve got a better financial justification for it.
Basab Pradhan has responded
As you can see from the linkback above, Basab has responded. He brings some new chestnuts to consider:
Engineering costs are fixed costs. They have no relationship to the units of software sold. Sure, if you sell more units you have more money to spend on engineering, but that is conflating cause with effect.
Basab, if your growing customer base makes new demands on the software, whether from a desire to see bugs fixed, or progress, and you accept those challenges to keep things growing, there is no conflation, it is a cause and there is an effect that has costs. Simple example is deciding to do translations for new markets. Oh, but wait, we have to have localizable software first. Better hire some more engineers. Or better take the same engineers and make them work on that instead of a new product. Wait, you want interaction between users? You want in-app sales? Wow, how are we going to make that scale? Oh no, users are reporting a bug on that new release of iOS. Sales have stopped entirely until we get it fixed. That list goes on and on. I’ve run enough engineering organizations at companies large and small to tell you that is a fact. Whether the bean counters choose to classify it as a marginal cost is irrelevant at best and distracting from the main business at hand at worst. Organizations that think they can ignore it and reassign the engineers to the next project are called professional services organizations, not software companies.
…after a certain user base has been achieved, incremental (support, bw) costs are not material, in my opinion.
Basab’s argument is that by throwing all the support into forums and relying on superusers to take care of all but a few that are then handled by remaining support, we needn’t view support as a material. If only it were so, Basab, if only it were so. You probably are not aware, but my last gig was running a company that built support solutions exactly as you describe. Our product derived real metrics on the ROI and effectiveness of Social CRM for customer service, and these results were covered by Forrester, Gardner, and others. There is Good News and Bad News. Under ideal conditions (and most do not achieve these for a variety of reasons), customer service costs can be reduced to about 1/3 of a pure ticketing and knowledge base system. There are complex dynamics and the idea that superusers will do all the work is one of the flawed assumptions many make that leads to disappointing results. In any event, even if you get to 1/3, you’re still going to have support costs that are quite material. BTW, many do not restrict themselves to forums either. Electronic Arts, for example, still does Trouble Tickets direct to support. Others will decide they can get away with forums since they’re cheap, and that’s the name of the game for app stores, so fair game. But lest someone reading all this think they can just toss their users into a forum, forget about Customer Service, and expect good results, beware. That’s not a winning formula for customer satisfaction.
Is this particular cost (SaaS costs relating to a server-side component, bw) material compared to the revenue from the next user? I doubt that Angry Bird or Omnigraffle worry about it. Evernote perhaps does, but how many apps do you know that users regularly use to scan and upload documents to?
How many apps result in uploads? How many apps result in interaction of one kind or another between users? How many stories have you read lately about scaling problems of one kind or another at small companies giving away their software for free? Enough said.
I was pretty clear in my original article. There is software that fits Pradhan’s criteria of low to no (certainly not-material) marginal cost per user. There is a lot of it on app stores. His arguments hew to the definition I gave of that kind of software which is software that you don’t bother updating much, that has poor (throw ’em into a forum and let them answer each other’s questions) customer service, and it has little or no SaaS component (no uploading data, no interaction with other users, and I already mentioned having to deal with in app purchases as a valuable SaaS component). I don’t see much in the rebuttal that changes those conclusions, though it was a decent attempt at response. The point of the post is that its silly to say Software (capital “S” by intention) has no marginal cost. Of course a whole lot of software has marginal cost! Since we’re now just arguing about degree, my work here is done.