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.
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).
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.
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 Sencha.io) 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.
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.