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.

[featured_stories ids=’198′]

Take advantage of free where you can

If you can get a backend service for free then there’s no restriction on revenue model; this is ideal where it’s possible. For some use cases the platform providers offer free infrastructure to enable this (e.g. Apple’s Game Center). Alternatively, where an app has a very limited usage lifetime (e.g. for an event, or maybe a seasonal game) and/or target market, it’s likely that the free tier from one of the larger BaaS providers will cover the needs of the application indefinitely. These free offerings range from tens of thousands to a million API calls per month, so this is a very real possibility for apps that don’t ever expect to scale beyond that. This is something of a loophole in the pricing models though and it’s worth bearing in mind there’s no guarantee this pricing will continue.

Consider the cost of building your own Backend-as-a-Service

Building a custom backend service for a relatively simple application and writing the client-side code to talk to it would typically take at least a couple of weeks. For most developers the value of that time will buy a lot of hosting. Leading BaaS offerings generally provide at least a highly scalable database, location-based search, file storage, user account management, push notifications and social features with easy to integrate client SDKs for the major platforms. If the app is going to need most or all of the these the build cost could be significantly higher. Even at high usage rates it will often be possible to pay for more than a year of service for the cost of building your own; taking into account hosting and maintenance costs for a custom built solution the trade-off gets even better. In hit-driven app stores, particularly for games and entertainment content, it’s extremely difficult to both predict and sustain scale. As such the BaaS option is very likely to be cost effective.

Running costs vs revenue models

With costs for BaaS ranging from about $0.01-0.10 per thousand API calls (with greater usage having lower rates), the expected level of API calls per user determines which revenue models are sustainable. Only the lowest levels of API usage can be covered by a straight paid download in the usual $0.99-2.99 range with room to cover development costs and make a profit. Somewhat counter-intuitively, an ad supported model can sustain a relatively high level of use, with global average eCPM at $1.90 across platforms, apps that show an ad for every 10 API calls they make (or better) should still come out significantly ahead – they just have to drive more usage to compensate, which the interactive service will help with. The key here is that both costs and revenue are dependent on continued usage. An in-app purchase model where continued usage is highly correlated with purchases (e.g. consumable content) is likely to work well, although any level of free usage carries a risk conversion ratios to paid usage are poor and costs exceed revenues. In-app purchases that remove ads or add features are equivalent to paid downloads in this context. A subscription model is the safest of all although again a free tier introduces risk.

Money isn’t everything

A Backend-as-a-Service is less flexible than a custom built solution. With the latter it’s possible to limit server resources to (subsets of) users such that performance degrades at busy times but cost of service is fixed. With BaaS the server resources and costs will always scale to meet demand for all users. In practice, it’s also going to be hard to switch away from a BaaS once it’s in active use, even if they offer data export. A final risk to consider before selecting a BaaS solution is provider longevity – will the service be around as long as the app needs to be running. It’s a competitive market where the pricing models of vendors depend upon reaching scale and the apps they serve reaching a certain level of success. Pricing models may change suddenly. In addition, the engineers capable of building highly scalable server solutions for mobile devices are in great demand right now – an acqui-hire is also a risk even for the providers with significant VC backing. With all of the risks considered, if a Backend-as-a-Service solution is technically capable of supporting your app then sharing and spreading the cost of building and maintaining the backend in this way makes a lot of sense and is easily worth the time to evaluate the options.