Backend-as-a-Service Shootout (the best alternatives to Parse?)

Using a Backend-as-a-Service (BaaS) can reduce development cost and time-to-market. It’s a simple way of getting a highly scalable backend solution without significant upfront investment. This avoids the technical risks of having to scale your own service to meet demand as your user base grows; in a world where an app that hits the store top charts might gain more than a million new users before you complete your next iteration of development this is worthy of serious consideration. In most cases the tradeoff is giving up control of your backend. This tradeoff was brought into the spotlight recently when the most popular BaaS, Parse, was acquired by Facebook. This created a predominantly negative reaction from developers who went from buying a service from a neutral party to hosting their backend with someone many already distrust that has an interest in mining their app data. So, if you’re looking for a BaaS for new project but don’t want to share your data with Facebook, or want to migrate away from Parse, where do you go? Our last survey asked developers using BaaS offerings to rate their primary tool against a range of criteria – the results could highlight some attractive alternatives.

Splitting out the 8 tools which had more than 10 ratings each, the “other” category is still almost 25% of responses and includes a further 11 tools that developers had selected as their primary BaaS. Our own sector page lists 43 vendors at the time of writing, suggesting that the sector is still very fragmented and likely to see consolidation in future.

BaaS Shootout

Some popular BaaS options tied to other tools

Parse was by far the most popular with almost 2.5 times as many responses as Appcelerator’s Cloud Service as the next most popular. Appcelerator’s service is fairly heavily tied to their popular Cross-platform tool (CPT) much like the Sencha offering, which had a very similar number of responses. However, while Sencha’s BaaS had the highest developer satisfaction in our survey, Appcelerator’s was the lowest of the top eight. This situation is the same as the satisfaction levels for the corresponding CPTs. While may look attractive on developer ratings, adopting it implies using (at least some of) the Sencha libraries for cross-platform web development too – although this tool scored highly on cross-platform availability (the web works everywhere) there are no native SDKs.

Applicasa switched focus

Just behind for developer satisfaction was Applicasa. However, while our survey was running Applicasa were in the middle of a mini-pivot from a generic BaaS to a “Mobile Game Management Platform”, having recognised that the generic BaaS sector was exceptionally crowded. They haven’t yet come out of beta or announced pricing, although this is likely to reflect their value-adding services for game developers. If you’re looking for a BaaS offering with extra functionality for mobile games then Applicasa may be worth a look.

Open source or specialised

Behind Applicasa comes Parse, closely followed by Deployd and CloudMine. Deployd does not yet have a production hosting solution, so it’s currently just an open source project that you host your own instance of on Heroku or Amazon. That’s also an advantage in that you can modify the code and you’ll always control your own data. Another open source BaaS option like this, Helios, was recently launched by Heroku themselves. If you can take on responsibility for some of the maintenance of the backend in order to maintain control of your backend code and data then this kind of open source option is very attractive. CloudMine on the other hand is focussing on larger corporate clients – they’re targeting enterprises and agencies producing lots of apps. Like Applicasa, they’re specialising to target what they see as a more profitable niche and trying to avoid mass market generic BaaS competition.

Further acquisitions likely – select with care

The remaining popular BaaS options in our survey scored below the average for “others” on developer satisfaction. However, just by looking at the top handful we can see some trends for the still immature sector emerging. The generic BaaS space is all about scale. The remaining vendors fighting for this market are likely to get acquired by a larger company, or run out of cash trying to compete. It was implied that there were multiple parties interested in acquiring Parse who are presumably still in the market for a similar solution. If the acquiror of your chosen BaaS is a PaaS vendor then the service should continue to evolve and developers’ data remain private. The large PaaS vendors are likely to build or buy a more complete BaaS solution – we already see this with Helios and Windows Azure Mobile Services. Other companies interested in buying a BaaS vendor might want to integrate with their own analytics (as with Flurry buying Trestle) or other developer services, secure a key supplier or just get a closer relationship with mobile developers. There may also be large enterprises that snap up a small BaaS vendor for their own internal use. Other BaaS vendors will specialise towards specific developer segments.

If, like most developers, you’re still experimenting in the market and not yet building your own services with a long term view then a BaaS that’s specialised to your app category might be a great option. For those looking to select a common backend architecture that they’ll re-use across multiple products, or platform to build on top of for the longer term, the open source frameworks look like the safest option in the current market.


Parse leads with 28% but competition for second spot is heating up as BaaS rises in popularity

As mobile apps become more sophisticated and expand their user base, the requirement for remote storage and user management becomes more important in terms of both functionality and scalability. This capability is usually provided at the backend that manages the application data. Off-the-shelf mobile Backend-as-a-Service can save a considerable amount of time for developers that require backend support for their apps. At the very basic level, mobile BaaS services offer a managed, cloud-hosted database that scales as the user base grows. All BaaS services provide additional functionality on top of this basic layer that may include user management, push-notifications and large-file storage among other.

Backend services used by 14% of developers

Backend services are currently used by 14% of developers, but their use is more frequent among developers working on 16+ apps per year (25%). Backend services are used slightly more on iOS (18% of iOS developers) than on Android or WP (both at 15%), while BlackBerry developers use these services much less (9%), perhaps as a result of limited support among these tools for BlackBerry.


Parse in the lead

The clear leader in the BaaS sector is Parse, considered by many as the de-facto BaaS provider and used by 28% of all BaaS users, followed by enterprise-focused CloudMine, used by 11% of developers. and Appcelerator, both commanding a 10% share among developers using BaaS, are solutions that are well integrated with their corresponding development frameworks (Sencha and Appcelerator) and therefore not directly competing with services such as Parse or StackMob. While the BaaS market is crowded, services address different niches that differentiate them among competitors. As a result we have yet to see any service dominating the sector to the extent observed in other developer services such as advertising or user analytics.

While the core features may be common among BaaS providers, there are significant differences and advantages to each of these services that may make the selection easier. For example, exporting data may not be available on all services so if this is a key requirement, then a number of these services can be ruled out. Developers often find BaaS restrictive for their application requirements so several BaaS providers such as Parse, CloudMine, StackMob and Kinvey allow developers to implement custom business logic. However, developers frequently opt for a custom-built backend solution rather than a BaaS for greater flexibility.

Selection criteria

The main selection criterion for developers is, as in most third-party developer services, availability across platforms. However, the richness of the feature set is almost equally important as is the flexibility of the service, e.g. the ability to implement custom business logic. Ease of integration and use, stability and performance are important to 25% of developers using backend services.

Another important aspect of backend services is the pricing flexibility, i.e. the way costs scale with usage. Many developers whose apps experience a sudden surge in user base may find it extremely difficult to scale their costs as usage grows: a free service using a third-party backend that suddenly amasses hundreds of thousands of users will incur significant operational costs as access to the backend rises with the number of users. Developers should keep this in mind when designing their apps and backend service providers should aim to align pricing strategies with developers’ business models.

Backend features

We asked developers using backend services to highlight the most important feature for them. 28% (of developers using backend services) indicated data management and 18% indicated user management and authentication. Next most important features are push notifications and content management highlighted by 11% of developers using backend services. Less important features include analytics (9%), file storage (7%), cloud code (custom logic) (6%) and social graphs (3%).

The backend service sector is relatively young and expected to grow as developers familiarise themselves with such services and realise their potential. At the same time, there is much room for improvement as BaaS providers better understand and adapt their services to developer needs such as flexible and customisable business logic.

[doritos_report location=’DE13 Article – BaaS’]

Which BaaS services are other developers using?

[toggle title=”Important things to know about this interactive graph”]

  • All the filters in the graph refer to survey questions in which respondents could select multiple answers. This means that there is no direct link between the filter and the use of the tool. For example, filtering on “Android” means that the respondents develop Android apps. It doesn’t imply that they use the tools for their Android apps specifically, or even that the tool supports the Android platform. Use filters as a guideline only.
  • Keep an eye on the sample size. If the sample size is low, the graph doesn’t offer strong conclusions about the popularity of different tools. Use your good judgment when making decisions.
  • In this graph, “Other” was removed as a possible answer. A lot of respondents used the “Other” answer to indicate that they use an in-house solution, which is not a “Backend-as-a-Service” at all.[/toggle]

    Find the best BaaS service for you!

    [sectors slugs=’backend-as-a-service’]


Backend-as-a-Service Economics

There are a wide variety of products that can be considered Backend-as-a-Service (BaaS) offerings. At the time of writing we list 43 of them on our sector summary page. We have previously discussed whether or not they’re a good idea and how much development effort you could save by using one. In our most recent survey we asked developers about their use of some of the most popular options. By comparing developers’ use of BaaS with their average revenues and active user bases, we can determine how well these products are working for them.

BaaS, what’s BaaS?

An interesting point to note is that a lot of developers don’t appear to know what BaaS really is yet, suggesting there’s plenty of room for growth in this sector. Almost 20% of the developers in our survey who indicated they use BaaS solutions said they were using their own proprietary backend; this is just a backend service and not BaaS, since it is built in-house rather than re-using a more generic backend solution from a third party. We exclude all of these people from this analysis. Technically it’s only really BaaS if the provider hosts it for you too, although we include options like Deployd, which is an open source project that combines with a PaaS offering like Heroku to give all the features of a BaaS (and more flexibility).

[sectors slugs=’backend-as-a-service’]

Show me the money!

Developers using BaaS solutions have an above average interest in making money. Only 11% of BaaS users were not interested in money vs. 20% of non-users. This is probably because the costs of running any kind of backend service are a deterrent to hobbyists. Of the remaining developers who are interested in making money (excluding those who were unable to report their revenues, or earned over $50k per app per month) 43% of BaaS users were earning more than $500 per app per month vs. 31% of those not using BaaS. The average monthly revenue for BaaS users was $3223 vs. $2482 for non-users. So, developers are more likely to earn enough to cover the costs of running a backend if they use a BaaS and also earn more than enough extra revenue to pay for hosting/service costs on average.

More backend features = more revenue

Not all BaaS solutions have the same feature set. The more comprehensive offerings typically have user, content and data management, along with push notifications, social integration and some kind of location data support built-in; most are also able to be extended with custom code. Less complete solutions generally only offer a small subset of this feature set, with different vendors providing different subsets. Some services are well integrated with cross-platform tools (e.g. Appcelerator Cloud Services and and although they are quite comprehensive, their results appear to be more influenced by the CPT itself than the use of the BaaS – that said, users of these services also make more revenue than other users of the CPT, with Sencha coming out significantly ahead of Appcelerator in both cases. Finally, Deployd and Apigee Usergrid offer more flexible/configurable options, where users can add features from a fairly comprehensive base.

As can be seen from the graph above, users of the more comprehensive BaaS offerings make significantly more revenue than other BaaS users. On average their active user bases are only about 20% larger, so it seems the more feature rich backend services are translating to higher value generated for end users.

Which features are most important

We also asked developers which features were most important to them when selecting a BaaS. The majority of users were interested in user management and data management, features available in almost all BaaS offering and thus unsurprisingly correlated with approximately average revenues. Those primarily interested in using a BaaS for push notifications or file storage had almost half the average revenues (these are fairly easy to achieve without the overheads of a BaaS, possibly indicating a lack of sophistication) while those interested in content management made about 50% more than average and those most interested in analytics more than double the average. This outperformance for developers focussed on server side analytics mirrors that on the client side, suggesting it’s the developers’ approach and not the feature itself with produces the improved results.


How Much Is An Active User Worth?

App store analytics providers have been telling us that almost all of the growth in app revenues in the last year has been through in-app purchases. However is that just because the model has become more popular? Or because revenue has been concentrating at the top of the market where the strategy is very popular (particularly in free-to-play games)? Probably a bit of both but it’s also the case that subscriptions and in-app purchase do produce the highest overall revenues. If you exclude the developers of top apps (anyone earning over $50k per app per month on average and with over 500k active users) then it turns out that aside from apps that provide enough value to justify a subscription model, the important thing is acquiring users and keeping them engaged. The average revenue for an active user is fairly constant, regardless of the monetization method.

How much do you think is an active user worth? Take the Developer Economics Survey and have your say!

For the purposes of our survey, freemium could be a limited free app with a separate paid version promoted by the free one, or a free app with a premium upgrade via in-app purchase. In-app purchases can be any content, features or virtual goods purchased in the app, which itself can be paid or free. Paid downloads, advertising and subscriptions are hopefully self-explanatory. Note that it’s possible (and indeed quite common) for developers to use multiple revenue models, either on separate apps or within the same app – e.g. freemium with advertising in the free version. The average number of revenue models per developer in the sample above was 1.7. However, if we only look at developers using a single revenue model, the pattern is very similar (and average revenues are lower across the board).

Make the core functionality free if you can

For the majority of developers, an active user is worth around $0.04 per month. All other things being equal, unless you have a sufficient reputation or well known brand association that you can get paid downloads in large numbers, then it’s better to avoid the user having to pay directly for the core functionality of your app. This results in more downloads and a larger user base. Freemium comes out badly here, it seems that the free trial may get lots of downloads but overall slightly fewer active users (and paying users) than a straight paid download. Advertising and in-app purchases had almost identical user bases and overall revenue. Subscription apps had the smallest active user bases but by far the greatest revenue, however, this revenue model requires some kind of ongoing service that is external to the app, which will have associated costs.

In-app purchase beats advertising at the top end

The picture is a little different if you include the highest earning apps. At this point paid downloads fall far behind, both in terms of ARPU and overall user base and revenues. This is not to say you can’t have a very high grossing app with a pure paid download approach (Minecraft is a great counter-example), just that the probability of doing so is much lower. Subscriptions still come out on top but not by so much. The lower ARPU for subscriptions at this level suggests that the top subscription apps have a very popular free tier. Freemium does slightly better than paid downloads for active user base size and significantly better for revenues, suggesting that top quality paid apps with a higher price may sell better with a free trial of some kind. Finally, in-app purchases and advertising both generate the largest active user bases by offering their core functionality for free but a well designed in-app purchase scheme beats advertising for monetization by some distance.

Beware service costs eating all your revenue

In addition to revenue model selection there are also implications here for apps which connect to backend services. The average monthly revenue from an active user needs to exceed the costs of providing the service significantly to make a profit. If the majority of developers are only making $0.04 per user every month on average then say a Kinvey (purely because they price per user for iOS and Android, making the comparison easy) BaaS at $0.03 per user (for 200-5000 users at current pricing) does not leave much for the developer.


In-app purchases or ads?  Take the Developer Economics Survey and have your say! You may win awesome new gear.


How Much Time Could You Save With Backend-as-a-Service?

Backend-as-a-Service (Baas) provider Kinvey published an interesting infographic on the average time taken to build an iOS or Android app (with a backend service) this week. The data comes from a survey of 100 developers with their estimates averaged. Before interpreting the data, it’s worth bearing in mind the following:

  • This is only to build a Minimum Viable Product (MVP) – it’s nowhere near the total that would be spent on a successful app.
  • The features included create an app with a relatively rich backend service and a fairly basic client.
  • This is only building a client app for one platform rather than several.
  • Building a robust API versioning system would not normally be part of an MVP.
  • This survey has been created specifically to promote the benefits of BaaS.

Even so, the the items included in the infographic would be common to a wide range of applications.

Business Platforms Tips

Backend-as-a-Service – Should You Use One?

Many of the most engaging and popular apps connect to cloud services which either regularly deliver new content, enable users to interact with one another or both. Unlike a standalone application, such apps can incur ongoing hosting costs throughout their active usage life. Ideally your revenue model should mirror the cost structure. Using a Backend-as-a-Service (BaaS) reduces execution risk and time to market as well as removing server maintenance and scaling headaches, however, it typically increases the ongoing service costs making the revenue model fit even more important.  Obviously the technical requirements of the app constrain the selection of service and for basic backend features Cloudspring has a good overview article. The variation in pricing of backend services is even greater than the diversity of their technical capabilities but this post will provide some generally applicable advice.