They never wanted to host your app. The real reasons why Parse shut down.
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 their developer platform? While I believe the arguments about streamlining and focus are mostly true, I feel there is definitely more to the story, making the shut down a logical step.
Developer platform vs strategic move
When Facebook acquired Parse back in April 2013, many people thought this meant Facebook goes all in on becoming 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 are using 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 ads 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, they never wanted to host your app, they 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 was to really become a developer platform, you could have expected them to double down on the space, with lots of investment, more acquisitions, and integration of infrastructure. Instead, Parse changed only very little, no other development platform acquisitions took place, and it 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 somebody 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 developers 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. Even by them, Parse pricing was often perceived as notoriously cheap, wondering how they could ever make a profit for 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 comes under fire as well. Can you trust your platform of choice, or will they 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:
- It can have 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 can 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.
Ideally, as a developer platform you want a service to check both boxes.
This is what we have been trying to do here at Contentful, spending a fairly large time in beta and crafting a content management value proposition that is compelling on both dimensions.
