Platform-as-a-service startup Bungee Labs this week released a new utility pricing model that really starts to put the spotlight on the pricing charged by established software-as-a-service providers. Bungee also announced what it calls 'federated hosting', which gives customers the choice of where to host their Bungee-developed applications; with Bungee in North America or Europe, on Amazon EC2, or (on payment of a per-instance monthly license fee) in any data center of their own choice. More about that below.
The pricing is interesting because Bungee has done away with separate pricing for storage, bandwidth, processing and so on, instead setting a single fixed price of $0.06 (six US cents) per user-session-hour. (It's pro-rata to the nearest second, so if you log in for just three seconds every day for ten days, you'll pay for a total of just 30 seconds of usage, ie 3c. But per-session also means that if you log in and then go out for two-hour business meeting without closing the application, you'll pay for the full two hours).
What caught my eye about the pricing was when Bungee showed me this calculation of the typical monthly cost of a business productivity application such as CRM or a collaboration client deployed on the Bungee grid:disclosure: both Bungee and Salesforce are clients]. Even if you argue that the three hours a day is an underestimate and double it, you're still looking at a very modest $7.20 per user per month. Bungee Labs doesn't offer storage (its main use case is applications that integrate other online services) so add in a few more dollars per month for data storage on S3 (soon with even lower transfer charges). Now compare that to the $65 and $125 figure that Salesforce.com charges for its packaged application license. Or the $50 per user per month you'll pay for its Force.com PaaS platform.
This is a direct question of value. Is there enough value in the finished application supplied by Salesforce.com to justify the 1100% markup of Enterprise Edition? (I use this comparison since customization options are restricted on the lower-priced Professional license, so it's not directly comparable to a fully customizable PaaS alternative).
The risk for vendors like Salesforce.com is that many software buyers are going to start asking that question in earnest. They can choose between buying Salesforce.com's packaged functionality and then customizing it to their needs, or they can buy a programmable platform like Bungee Labs and build exactly the functionality they need. It boils down to which course appears most cost-effective.
A similar, starker question, surrounds the $50-per-month bill for Force.com. Are all the tools Salesforce.com provides worth five times as much as what Bungee Labs provides? ISVs will analyze this especially closely. In its last financial year, Salesforce.com's own cost of revenues — effectively the cost of hosting and supporting its software — was just under 14% of its subscription revenues. If I'm an ISV and want a PaaS vendor to provide that 14% element of my costs, am I going to use a PaaS vendor that charges me $10 or $50? In fairness to Salesforce.com, I do recall some talk of lower OEM pricing for ISVs. But even if the OEM price is more like $35, can differential services and reputation bridge that wide a delta from Bungee's sub-$10 offer?
The divide becomes even more of a chasm when you look at the costs Bungee has worked out for occasionally or intermittently used applications. Whether it's Bungee or any other PaaS provider quoting these prices, once the cost of cloud services starts to filter into mainstream awareness, all categories of SaaS application pricing — not just Salesforce.com — are going to fall under scrutiny (and I'm not even going to start discussing the impact on on-premise pricing). The repercussions won't be pretty.
I do feel, though, that Bungee is perhaps exposing itself to support headaches by offering this option — the code is deployed using VMWare but won't be managed by Bungee, so the company will
be emailing customers to let them know about use developer accounts and the server management console to notify patches and updates and rely on customers keeping their instance up-to-date [corrected in light of 'minor errata correction' in Talkback below]. Was the team worried about having to support lots of different versions out in the field? "We'd love to have that problem," came the perhaps telling reply.