Tag: developer tools

In the great app store gold rush of the last 5 years a lot of vendors of virtual picks and shovels have set up shop, hoping to cash in on the boom regardless of which individual developers succeed in a fiercely competitive market. Having surveyed developers on their tool choices and revenues, we can see how popular these third party tools and services are. We can also reveal whether those buying the virtual picks tend to do better than those who opt for the virtual shovels, or whether you really need both developer tools.

With great opportunity comes great complexity

As the expected level of quality and functionality in mobile apps is increasing, the monetisation strategies are also getting more complex. [tweetable]In order to succeed, most developers need advanced tools to manage quality in a world of fragmentation[/tweetable]. To optimise revenue models beyond the simple paid download, systems to acquire and analyse the behaviour of users are also essential. Most developers turn to third parties to provide some or all of these tools. Many additionally look to third parties to provide some of the functionality, particularly via scalable cloud-hosted services.

Over 85% of developers who completed this section of our survey use at least one third party tool, while just over 45% of developers use tools from at least 3 different categories. There’s clearly significant demand but how does tool adoption correlate to revenue? Looking at only those developers who generate between $1 per month and $5 million per month (i.e. excluding those not trying to make money, not yet making money and the mega-rich – n=1596) we get the following:

More developer tool use, less risk

Looking at only the mean average revenues you could be forgiven for thinking that developers should be avoiding most third party tools, since by far the wealthiest developers are those not using them. However, a look at the median revenues shows the opposite. Some of the largest and most successful developers can afford to build and control their own tools so don’t need third party offerings. [tweetable]The vast majority of developers trying to make it without any third party tooling support generate hardly any revenue at all[/tweetable]. The median number of people involved in development for the organisations not using tools is 1, whilst it is 3.5 (2-5) for all other results. In general the increasing median revenue with use of more tool categories suggests that those who use more tools have lower financial risks. It’s tempting to speculate that there’s some causation here where developers are able to offload some risk by using proven third party solutions. In fact, the major driver is that the tool categories cover such a wide spectrum of apps that the more you use the more likely you are to be doing a lot of contract development – an inherently lower risk revenue model.

It’s not what developer tools you use, it’s how you use them

How use of tools in the various categories correlates with revenues doesn’t produce any great surprises. Those using cross-promotion networks, game development tools and ad networks are at the bottom of the revenue pile. Large game developers and publishers tend to have their own game engines, can cross-promote with their own titles and even run their own ad systems. The [tweetable]smaller, independent developers who rely on third parties for this typically struggle to climb the app store charts[/tweetable]. App store analytics users are next up from the bottom, this may simply reflect the relatively poor revenues of those who rely on app stores. Most other tool use was correlated with fairly average revenues. Notably above average, ranking second overall, is Backend-as-a-Service (BaaS) – where the mean revenues are about 35% higher than average and the median revenues 50% higher. As a result those using a BaaS typically beat average revenues by significantly more than the associated costs.

Using the data from our survey at the beginning of the year, we previously argued that developers who collect lots of analytics and quality data for their apps and act on it are significantly more likely to succeed. Users of crash analytics tools had the highest mean ($26k/person/month) and median ($2.1k/person/month) revenues of any single tool category in the latest survey. Nearly 50% of respondents to this section of the survey now use usage* analytics tools so it’s unsurprising that their mean revenues are almost exactly average ($17.5k/person/month) although noteworthy that their median revenues are 50% above the average ($1.5k vs $1k). Those using both crash and usage analytics tools had similar mean revenue to those just using crash analytics but significantly higher median revenue ($3.5k). The only tool combination to beat this was crash and usage analytics plus beta testing, which had mean revenues of $33k and median revenues of $3.75k. Beta testing tools can also help developers to improve the quality and usability of their apps, as such it’s interesting that those using just crash analytics and beta testing had extremely low mean ($5k) & median ($750) revenues. Possibly this last tool combination typically signifies a developer with a quality problem rather than one proactively seeking quality?

Is selling picks and shovels where the real money is?

There are some massive app developer success stories but our data suggests that the typical app developer (as represented by median revenue) is struggling to break even. It turns out that the developer tools market is similarly competitive. Selling services to developers ranks third in mean revenue per organisation and per person involved amongst all revenue models (behind per device royalties/license fees and subscriptions). Compared to the users of the tools the mean average income at $29k/person/month is slightly higher than for users of any single tool category but the median income is exactly the same as for the tool users.

* This category gets called both “user analytics” and “usage analytics”. The developer tools do both, although if you only use them to get an idea of who your user base are and how often they use the app (user), rather than what they do in the app (usage), you’re probably doing it wrong.