Parse caused some waves in the developer world recently when it announced it will shut down in January 2017. The Facebook-owned mobile backend-as-a-service (mBaas) platform was well known and generally well regarded by developers, so the news came as quite a surprise. Why would such a seemingly popular service shut down? Furthermore, what lessons does it hold for other BaaS and developer tool providers?
Why is Parse shutting down?
The official word from Parse’s announcement is that it’s closing because “we need to focus our resources elsewhere.” A Facebook spokesman said, “Moving forward we want to dedicate more resources to high-impact products and services in areas like analytics, monetization, discovery, and authentication.” Pretty typical corporate-speak stuff, really.
On the face of it, the acquisition of Parse by Facebook turning into an acqu-hire isn’t that surprising. After all, Parse’s developer offering doesn’t totally fit with Facebook’s main business, and it’s unlikely that it would grow enough to make a significant impact on the parent company’s revenues or profits – which would require a contribution of hundreds of millions of dollars.
But Parse was certainly popular. Data from our DevMonitor tool shows that over the last year, an average of 450-650 new projects were started on GitHub with the keyword “Parse”, and the number was trending up. While that is impressive, it may just not be enough on the backdrop of the scale of Facebook’s larger business. This isn’t unprecedented, either, as it harkens back to the decision by PayPal to shutdown Stackmob, the BaaS service it acquired, in 2014.
Also, it’s worth considering the question of the success of these and other services at turning their users of free tiers of service into paying customers at sufficient scale. There is anecdotal evidence of many developers launching prototypes, MVPs or other first-effort projects using free resources, particularly for backends, then building their own infrastructure as their project grows.
Shutdowns like those from Parse, StackMob and others color developers’ perception of all similar providers. Why build on a platform that could disappear at any point, and potentially with short notice (such as the recent developments at Venmo and Kimono Labs)? Even if the services are backed by a big company, there is little guarantee of security – and a big credibility hurdle for service providers to overcome.
What can developer tool providers learn from Parse?
It’s essentially impossible for developer tool providers to overcome this credibility hurdle with developers, but it certainly can be mitigated effectively, and the Parse shutdown offers several tips on how to do so.
1. Know your developers, especially the free riders
Offering a free version of a service is, for the most part, table stakes these days for developer tool providers. Developers learn by doing, and in order to accurately assess a tool, they need to be able to use it. That said, providers need to be careful where they draw the line between their free and paid tiers of service.
Often, this is dependent on the provider’s business goals. Is user growth the primary objective, financial implications be damned? Or is it building a sustainable business with paying customers? The VC-driven nature of this space often emphasizes the former, but this in itself can work against the tool providers. Developers’ skepticism of free services, and their long-term stability, exists, and news like the shutdown of Parse only makes it grow.
Understanding who is using your service – and how – is crucial in order to tier and price your products correctly meet your business goals. Giving away services to try and get hockey-stick user growth isn’t always the right answer.
2. Use open source, open protocols and open tech to your advantage
Building user lock-in around proprietary technology is a long-standing tactic. But it’s something developers are increasingly on the lookout for – and again, the demise of Parse and other providers will only boost this further.
The higher the degree of lock-in, the higher the hurdle to attract developers will be. But this can be mitigated by building around open technologies and allowing developers to fully export their data, so that if they wish to move off of your platform, it’s easier for them to do so and reduces the reworking they will have to do. In turn, this makes developers more comfortable choosing to adopt a service to begin with.
This may seem counterintuitive to some – making it easy for customers to leave your service – but when lock-in turns developers off of your service in the first place, it’s a necessary step to take.
3. Eat your own dog food – and shout about it
One of the best ways to build developer confidence in your tools is to use them yourself. For example, Amazon Web Services avoids being painted with the same brush as some other cloud service providers in terms of long-term stability, because developers understand that the same services are used to power Amazon’s own business. AWS’ future is more assured than some other providers because Amazon needs it to survive, and shutting AWS down would have serious internal repercussions for the company.
For many tool providers – particularly when after they are acquired by bigger companies – this sort of dog-fooding either doesn’t exist or isn’t at all clear. By utilizing your own products and services and deeply integrating them into your own business, and by making developers aware of it, you build credibility as well as confidence that the service will exist over the long-term.