How the app world may look like after Parse died?

Parse died

I bet that literally thousands of app developers, C-level executives and startup owners and many others were truly terrified after discovering what does an e-mail entitled “Important Parse Announcement” sent on January 28, 2016 contain.

“We have a difficult announcement to make. Beginning today we’re winding down the Parse service, and Parse will be fully retired after a year-long period ending on January 28, 2017. We’re proud that we’ve been able to help so many of you build great mobile apps, but we need to focus our resources elsewhere. (…)”

Hearing such news by far changed Thursday’s and Friday’s meeting agendas in numerous organizations across the globe and brought cold shivers to those founders who associated their app growth strategy with using Parse. A huge chunk of the app world is probably trying to answer two questions now:

1) Why did it happen?
2) OK, now what?

We will try to share our still fresh findings on those two issues.

Why did it happen?

Parse definitely was one of the market leaders in Backend as a Service solutions. It made the lives of loads of startups and well-established business a lot easier. Having a ready-made, clickable and easily customizable backend meant loads of time and budget savings. It was in line with the Lean Startup principle – it allowed you to deploy your solution fast, get out of the building with your idea and get users’ feedback and it was flexible enough to handle vast majority of changes requested by users after the release anyways. Plus, it was generally free until you reached enough user traffic to become successful, and only then did you start to pay to Parse. Sounds like a really reasonable win-win, right? That was probably one of the reasons why Parse became so widespread and their market position was even further strengthened when they were acquired by Facebook.

It is probably hard to determine in 100% what was the reason for Parse market failure with the information we have now, but let’s try to make some educated guesses and hypotheses:

  1. Parse monetization strategy resided upon giving the solution for free and waiting for the app to become successful as measured by the backend traffic it generates. It seems there were too few great and successful apps on the market to generate enough revenue for Parse to survive (there may be some of the reasons here – link)
  2. Even after some of the Parse apps became successful it was still relatively easy for them to start building the proprietary backend from scratch on their own and switch to their solution really soon after they entered into a pricy Parse plan. Some apps may have basically used Parse infrastructure for free during their harsh times and they had strong alternative to Parse soon after they experienced traction and sustainable positive cash flow.
  3. Many people have heard about the performance problems with Parse which were forcing the mobile app users to wait for far too long for the back-end responses. It is still not clear whether these problems have been fully fixed or not, however surely they might have been posing a significant risk for any serious application. For this reason, it might be that serious businesses were not choosing Parse or were moving away from it.
  4. It may so happen that Facebook was so desperately in need of dev resources that they closed Parse in order re-allocate Parse coders to more important products. That’s probably least likely to be the major cause, especially if Parse was truly a cash cow or had prospects to become one in a foreseeable future.

We probably will learn more about the reasons for Parse failure from the founders in the next weeks but in any case this already is a great lesson for any product focusing on long tail components in their sales strategy and hoping that once some end-users success metrics are met they will finally start to earn.

OK, now what?

While waiting to determine what was the cause for Parse failure, it is definitely worth concreting about the immediate alternatives and general backup plans. Here are some of our findings.

If you’ve already had your backend implementation on Parse then the best way to move forward is to use Parse’s migration tools. We haven’t tried them yet but we believe they mostly work fine. The migration tools include:

  • an open source Parse Server which, according to Parse’s assurance, can handle the Parse API on any infrastructure that supports Node.js,
  • or a database migration tool which helps you move your data to another MongoDB instance.

Even if the service will be retired in one year, the Parse’s dev team recommends to start migration of your data ASAP. The very detailed guide on how the migration process should proceed is here.

If you were planning to use Parse for your application or have just started using it, then you can consider to choose another mBaaS solution straight away. Here is a list of some alternatives to review:

It is also recommended to consider using an IaaS (Infrastructure as a Service) provider and create a bespoke backend solution which, by the way, our company is able to provide. A bespoke solution does not necessarily have to be much more expensive than a BaaS configuration. Anyway, here are some IaaS solution providers: was integrating several services in one place in addition to BaaS, in particular analytics and push notifications. Alternative solutions may not support those, so it will be worth to consider using additional services such as Urban Airship.

It is probably still too early to draw far-fetched conclusions about the consequences of Parse’s death for the whole app industry and specifically for the Backend as a Service sector.

A couple of things seem to be evident, tough. For app startup owners: always try to think of some backup plan in case one of your core technologies goes bust (no matter how widespread it is). For the service providers: make sure you do not rely on too many uncontrolled variables in your revenue stream plan.