let's invite the rest of the BaaS PaaS players to chime in...
Very cool service. Haven't used it before. Apologize in advance for delays in responding.
Branch was a very good idea Alexander. My only point is that Ty's implication that his "no charge per API call" was unique to StackMob was a little misleading, that's all. If a developer prefers to pay by number of users, our model may work for them; if someone would rather buy features, then StackMob may make more sense. It's all good. Everyone has their own twist on pricing. Vendors should strive to highlight their own value without misrepresenting others'. Fair?
We don't charge per user. We don't charge per API call. We think those are outdated and archaic pricing models. You only need to check the pricing page of the other vendors to see they do charge for API calls and do charge per user. You can contact me directly to talk more about how our predictable and value-based pricing might work for you. steve (at) stackmob.com
By the way, words like 'misleading' and 'misrepresenting' may be interpreted to be a little inflammatory.
But Joe, you're a GREAT marketer!
Love you bud, and I am eager to have drinks next time I am in SF, but when it comes to "misleading" the proof is in the pudding. It appears Alexander was misled by Ty's comments in Sarah's article. The headline read: "StackMob Ratchets Up The Competition: Makes API Calls Free." They were already free, with Kinvey. If a reasonable person was misled (and by all indicators, Alexander is reasonable), then, by definition, it was misleading.
Hi Miko, I hope it isn't the beginning of a war (we don't need another one of those), and we do hope that developers realize they shouldn't be penalized for success and should only pay for features they use in creating an app.
You'll see from looking at the StackMob Marketplace that there are plenty of options for paid modules if you want to take advantage of our partners' solutions that they've seamlessly integrated into StackMob.
I had intended out of this, provided Steve stood down on this "success tax" FUD. First off, StackMob is SECOND to market with "no cost per API call" pricing for native apps. So there's no news there, despite their best efforts to make it so. They are likely first with that pricing for Web apps. Ty forgot to include that asterisk in his media pitch. This "success tax" is nothing more than PR FUD, because it opens the door for a logical counter: by charging for features, StackMob is making companies pay even if their app doesn't succeed. In their own parlance, that's a "failure tax." I don't understand why they are trying to market this way, why they can't cheer their (second to market) pricing model, without deriding others'.
That was funny, Miko. 100% agree, the market doesn't care who was first. Just some of the pub last week made it sound like SM was claiming this status, so I pushed on that claim a bit. Charging for features as SM does transfers the risk to the dev, success pricing transfers the risk to the BaaS player. We like our pricing model. And apparently SM does too ;)
@Jchernov, nicely said. I do think it's important also for the market to test claims and keep everyone honest and of course the combination of deadlined journalists and creative marketers sometimes gets close to the line. As far as MBaaS pricing goes you're absolutely correct to say that you can push risk to the developer or to the MBaaS provider and that vendors will optimize this around their own costs as well as the customer's ability to pay at the appropriate time in their lifecycle. We might see pricing models diverge as a function of market segmentation or converge and get cheaper as a function of competition.
Seems to me that whether something is a tax or not is a bit of a red-herring, If the PAAS ou are using cannot make money in some fair way then you probably should expect it to be dying sometime soon. Which model is best in our experience depends a lot on what type of market you're serving - individual developers tend to like by the drop because (start cheaply and scale). Large companies tend to like predictability so they can budget properly.
Box.net is a storage company - yet, for all their enterprise accounts storage is unlimited. Variable scared their customers. Instead they charge by number of seats/users - something their enterprise customers CAN predict.
Thinking more abstractly: If a developer is successful, there will be some sort of increase in volume. Unless the PAAS service is truly magical that means extra cost for the PAAS provider.
Any (functioning) business model has to pass some of the cost on, whatever the mechanism for that is (tiered, volume, opaque enterprise - whatever). You can call this a success tax, but in my view what matters is not if there is more cost to the developer but if the unit cost goes down over time. I.e. As I succeed, I'm happy to pay you a bit more as long as you are not getting an increasing %age of the pie (and ideally if the %age is decreasing). If that %age increases I'll most likely ditch you for someone who offers me better terms at that point.
Hello Guys! Sorry for the Delay. Our pricing model is per API calls as well, we do it like that because it is clear for developers (and for our business model), also allows to create apps and prototypes that, in case they are not successful, the developers won't be charged. according to @jchernov.
Thanks for the invitation. We are in London, but enjoy SF and AppsWorld next Feb.
I like what @njyx is saying. By the way Kii Cloud MBaaS uses @3Scale for API management. It's interesting that the tenor of this conversation echoes that of the US elections somewhat in the idea of "taxes". What Steven contributed is meaningful, which is simply that increased usage means increased cost for the provider. So logically the cost needs to be transferred to someone.
Thoughtful post Miko. I am guessing we'll see one of your "midsized" companies raise a B before a "Small" raises an A. Re: "he smaller players may try to pivot to Enterprise revenue ... but smart Enterprise buyers should exercise caution in selecting vendors who are so unstable" ... I can't imagine ANY enterprise buyer (not just the "smart" ones) would take a risk on a company without ample funding, momentum or track record. I imagine business viability is a prerequisite. I just don't think a pivot to the Enterprise is viable for these companies.
Lastly a question for you: With the size of seeds growing, and with accelerators (hopefully) advancing the maturity of startups, can seed-funded companies last longer or succeed faster w/o an A?
hi @jchernov there will be a few exceptions but yes, disciplined IT buyers should consider Vendor Viability in MBaaS and there are mechanisms to ensure that they do. One of the tricky patterns in any kind of PaaS is to expense the early cost by credit card, then saddle the organization with the bigger cost when it grows. But smarter IT organizations are sensitive to this kind of approach.
A purely bootstrapped MBaaS player is going to face being out-marketed, out-priced and questioned over their viability, all of which will hit revenue. You might see a few corporate strategic investments, but this cuts off exit opportunities for smaller players (for example, Oracle wouldnt buy a startup that was funded by SAP if it had a choice). In a market where upfront revenue comes in big chunks I wouldn't be as concerned but MBaaS is a loss-leader, exponential revenue and therefore investment-driven space, imo.
Hi Alex -- I think you may have minted a new meme - #ByitaS. It made me laugh.
I was interested in reading the article this morning. Fred is, indeed, a bright investor and I sincerely hope he's encouraging his portfolio companies to price their products in the way customers want to pay, rather than bleeding them dry when they are successful in their business.
Also, beware of companies that use their investor's money on arts and crafts projects, rather than in building solutions that work for their customers.
Thought this group would enjoy Kinvey's latest arts and crafts project, which ran for two days on the homepage of ReadWriteWeb. (My goodness what that does to traffic, inbound links and user acquisition!) readwrite.com
Kin Lane: "If you are building your app, & depending on an aggregate API service like Singly, or backend as a service (BaaS) platform like Cloudmine or reliant on a automation platform like Zapier, you want to know the company is going to be around in a year. Right?
Another way these startups can instill confidence in the developers who are building apps around around their services is to also offer open source options... backend and automation as a cloud service, while also as open source download and fork, this new breed of providers can do a lot to build confidence and goodwill with potential users... an open option, if for any reason the startup should change or go away, app developers have the option to put the open codebase to use."
I am glad the topic of vendor viability is being raised. As more professional and enterprise developers get into MBaaS, there are increasingly questions about this topic. Open Source is just another form of source escrow that is typical in Enterprise license situations. Enterprise procurement guys are often pretty sensitive to that issue.
My blog post was crafted with the intent to bring more participants to the conversation as I have an audience in this space. So I hope that exposure wouldn't deter you from future comments, yet encourage. I took a lot of care to make sure my blog post was respective the conversation, and wasn't about PV. I think this is a great covo, that lots will benefit from... not that my blog post was the one you were talking about. ;-)
Thanks for your feedback! Team Branch