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.

Hm, it looks like your assertions aren't jiving with your pricing page (beautiful site, by the way). I'd love to hear what developers think for themselves.

Thanks @AAinslie this is a terrific discussion. I feel like I'm at a conference on a panel on MBaaS Pricing moderated by @sarahintampa

I respect what @StackMob is doing but in looking at their pricing page, isn't it just segmenting everyone into a free tier and a "custom" Enterprise tier? @stackmobsteve ?

Also, is this the start of an MBaaS price war?

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'.

Wooo @jchernov @stackmobsteve I'm in San Jose and wanna be in on the drinks when Joe comes to town. @AppsWorld in Feb at the latest, right?

@jchernov I wouldn't worry too much about the claims about who is first or whether the spin is misleading or not. Developers are going to run all the numbers and test drive the MBaaS then decide. @Stackmobsteve

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.

FWIW: Here's a compelling argument against 'failure tax' (charging for features - regardless of an app's traction): nytimes.com

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.

Funny: StackMob just began serving "success tax" ads against my name after this exchange. Guess they've had some time on their hands since bailing on this conversation. ;)

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.

@jchernov I'm sure stackmob isn't deliberately buying ads against your name, they seem to be prodigious AdWords Display users and it's probably happening algorithmically. Just my hypothesis.

Hey @jchernov do you plan to update the MBaaS Ecosystem "subway" map to include Kii Cloud MBaaS? Thanks.

We will update it periodically, Miko. Don't have a date set for the next rev, but we'll include additional companies when we refresh. Happy to include you.

Hi @jchernov that's fair-minded of you, appreciate the effort and let me know if you need any thoughts we would be linked in NTT DoCoMo and Softbank in such a diagram most likely.

ow.ly as long as we're being controversial: How the Series A Crunch will impact MBaaS

@mikojava excellent points and post, keep driving this important convo forward. thx!

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.

blog.programmableweb.com Here's a post on the value of reliability in MBaaS

"Ten million (users) is the new one million" - @CDixon t.co

Should #mBaaS platforms be considering the above reality as a new baseline in their "utility" pricing models for developers?

#mBaaS ecosystem map
yodacom.com

Beware of #mBaaS #SuccessTax as it may #ByitaS (Bite-you-in-the-aaS) :) venturebeat.com <- good article on 2nd gen cloud startups by the super smart #CaaS (Carrot-as-a-Stick) money man, @fdestin

Agree Fred is awesome. Also suspect Fred hasn't been fooled by the success tax FUD.

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.

I am eager to hear your definition of "arts & crafts" projects, Steve.

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

(P.S. Steve, assuming our former employer's tracking is accurate, it seems pretty much your entire team enjoyed our arts & crafts marketing.)

.@fdestin #Open By Default for New Generation of #API Integrators #BaaS #MBaaS

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.

Perhaps it's time for all you guys to come together and craft a #mBaaSManifesto - it will help the entire ecosystem and drive confidence via transparence in the nascent #BaaS sector as a whole.

I'm happy to help mediate a #mBaaSManifesto. Be the neutral voice, with no warez to sale. I'm working on a deeper dive and comparison, this would be a nice addition.

Kin let me know how I can help. Maybe we can talk about this at the API Strategy Conference in NYC

Hi Kin!
Thanks a lot for offering to help these guys.

Will do. Such a great topic....I've had this thread open for a week now, trying to decide how to tell story around conversation.

Great, thanks! ... and do invite any other mBaaS/BaaS players to this Branch convo that you can think of

“#mBaaSManifesto: #mBaas & #BaaS players, do take @KinLane up on his offer to craft a #manifesto”

Kin, thanks a lot, all your work has been really helpful for vendors and developers to discover APIs features and pricing.

So what do you guys think about the Stackmob PARSE importer? techcrunch.com I think this kind of migration cant be done by a script, ergo it's hype.

Any examples of any apps who have actually left PARSE?

If "stirring the pot" were an Olympic sport Miko, you'd win the gold, silver and bronze. ;)

Thanks @jchernov =)

You always make me laugh, bud.

Glad to amuse... any thoughts on this topic though?

I have plenty of thoughts on the topic. But last time I shared them in this Branch, they found their way into a blog post.

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. ;-)

To support your question Miko....APIomat did an exporter too - apiomat.com