Facebook never wanted to host your app: The real reasons it shut down Parse

For those working in the “aaS” business, the Parse shutdown was the main topic of conversation this weekend. Many in the developer community were taken by surprise and took to Twitter to express their disappointment.

So why did Facebook decide to shut down its developer platform play? While I believe the arguments about streamlining and focus are mostly true, I think there is definitely more to the story.

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":1870928,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,dev,","session":"A"}']

Developer platform vs. strategic move

When Facebook acquired Parse back in April 2013, many people thought it meant Facebook was going all-in to become a developer platform. If you recall, Facebook was at a crossroads back then, with a share price below IPO level, desktop traffic plateauing, and mobile revenues a big question mark.

Enter Parse, which brought immediate mobile app developer reach, helping Facebook to distribute its SDKs and ensure developers would use Facebook’s login system. That, in turn, helped secure mobile adoption and a foothold in user profiles and mobile advertising. Fast forward to 2016, and Facebook essentially owns the mobile ad space, and its SDK is #1 in terms of mobile reach. Meaning Parse has run its course as an SDK distribution vehicle. In other words, Facebook never wanted to host your app, it just wanted you to use Facebook login.

Lack of commitment in light of competition

Parse was an early market leader in the mBaaS segment (mobile Backend-as-a-Service) in 2013. If Facebook really wanted to become a developer platform, you could have expected it to double down on the space, with lots of investment, more acquisitions, and integration of infrastructure. Instead, Parse changed very little, no other development platform acquisitions took place, and Parse never got integrated into the Facebook stack. All the while, Amazon, Google, and Microsoft were aggressively doubling down on their respective developer platforms. And so Parse’s lead evaporated.

Challenging unit economics

Instead of shutting the service down, why would Facebook not just sell the business to someone else? My suspicion is that it may just not be such a great business after all.

In 2013, Parse powered over 60,000 apps and had about the same number of developers. Its strategy was to go for broad developer adoption with a pretty broad feature offering. The corollary of that strategy is that the depth and quality of individual features and services were rather shallow. Large mobile app devs such as mobile gaming companies mostly shunned its service, building in-house custom solutions instead. Small- to medium-sized developers embraced its service but had a much smaller propensity to spend. Parse’s pricing was often perceived as notoriously cheap, making it unclear how they could ever make a profit off the service they provided. Faced with only low-margin volume business, potential divestiture proceeds were immaterial for a company the size of Facebook. So why even bother?

Lessons for relying on “aaS” developer platforms

With many developers now scrambling to move their apps away from Parse, the developer platform service model is coming under fire as well. Can you trust your platform of choice, or will it close shop on you tomorrow? I feel you’re pretty safe if the developer platform is an early leader and checks one of the following boxes:

• Either it should be one of the big boys: AWS, Google, Microsoft
• Or it should have a laser focus on a narrow set of problems/features. Think Stripe as the developer platform for payment. Or Twilio as a developer platform for communications. Being focused allows them to maintain their technological lead over a generalist developer platform like AWS.
• Or they should do a good job in creating (and capturing) value for enterprises. Enterprises are very demanding in terms of requirements, but once they commit, they can be loyal and provide a developer platform with sufficient revenue to sustain their technological lead. Think GitHub.

Sascha Konietzke is cofounder of Contentful, which he launched in 2011 when he was too frustrated with the capabilities of existing content management systems when developing mobile applications for customers.