Author: Mark Wilcox

Mark is developer who has worked on everything from the lowest level smartphone firmware to games and apps that sell pizza. He's also a project leader with a focus on lean methods and a consultant who loves rapid prototyping, app economics and business models.

Categories
Languages

HTML5 Adoption and the Importance of Independence

HTML FUD

Last year was quite a bad one for HTML5 in terms of developer mindshare. At the end of 2011, developer sentiment seemed to favour a shift away from native and towards HTML5 for a large range of application categories. As the year went on, there were more horror stories than successes and the tide of opinion swept the other way as Facebook publicly declared that HTML5 wasn’t good enough for their mobile apps. With a title declaring the importance of independence you’d be forgiven for thinking this article would be about a need to reverse that trend to get away from the tyranny of walled garden app stores. Nothing of the sort we promise.

Look out for sampling bias

Independent surveys and statistics are the important thing referenced in the title. HTML5 adoption just happens to be the subject of one of the best bad stats examples in the midst of last year’s shift. Apparently last summer, just after Mark Zuckerberg’s revelation that betting too heavily on HTML5 for mobile apps was the biggest mistake he’d made at Facebook, 94% of app developers were betting on HTML5 winning. Of course this survey came from Kendo UI – a vendor of HTML5-based tools for mobile app development. It’s unlikely they set out to create a useless survey but they did want some data to support their tools. So they asked web developers if they were using, or planning to use web technologies – amazingly most of them said yes! This is clear from the fact that the number one reason for using web technologies in the survey was “familiarity of languages”. Such a high proportion of developers working with web technologies should be excellent news for upcoming web-app only platforms like Firefox OS and Tizen, however, the huge number of native applications being created across all the platforms suggests the real figures are nothing like this. It’s a clear case of sampling bias. Kendo UI recently published another survey in which a more realistic 50% of developers built some apps with HTML5 last year but a rather less credible 90% were planning to use it in 2013. Contrast this with our latest mindshare and intentshare data, which agrees with 50% use last year but sees only 15% of those not already using HTML planning to adopt it.

Seek transparency and independence

In our developer economics survey we make a big effort to ensure we collect data from a wide range of developers and we publish the breakdown of platforms developers are working with along with the results of all the other questions. Where appropriate we weight or normalize results according the the proportion of different groups in the survey. Of course it’s not possible to avoid all bias in the sample and there is undoubtedly an element of self-selection – developers with an interest in the commercial aspects of app development are much more likely to answer a survey entitled “developer economics”. To a certain extent, that’s deliberate – serious developers who are trying to build businesses that involve apps want to know what other like-minded folks are thinking and doing.

If you’re looking for reliable information on the app market, particularly if you want to make business decisions using it, you need the most independent and transparent sources. We’re doing our best to be one of those sources.

Categories
Business Community Tips

Developer Story: Lyft

developer story: Lyft

Sebastian Brannstrom, Lead Engineer for Lyft at Zimride, talked to us about their app and the business that the technology enables. Sebastian has been working in mobile software since 2006, initially on Symbian and then transitioning to iOS, Android & Web by way of a side project, created in collaboration with designer and product manager Anna Alfut. In 2011 he joined VC-funded startup Zimride, who at the time only had a handful engineers, to create social ride-sharing services. Zimride’s initial service was an online marketplace for people to sell seats in their car on longer journeys. It was (and still is) growing but relatively slowly by Silicon Valley startup standards.

App Background

The company decided to create a new real-time marketplace for shorter trips and hence Lyft was born in 2012. Lyft has iOS & Android apps with two modes, driver and passenger. Lyft drivers are thoroughly screened, background checked, trained and insured with a $1M excess liability policy. Passengers can use the app to request rides that are tracked by the service, which suggests a minimum donation to the driver at the end. The driver mode notifies drivers of a nearby pickup request and gives them a short time window to accept it before it’s passed to another driver. The whole system enforces use of Facebook for identification to provide some additional security.

 

Track Record

The concept caught on and quickly became the main focus of the company. The engineering team has roughly tripled in size and the growth of the service is only being limited by how quickly they can recruit, screen and train drivers. Whilst they advertise for drivers on services like Pandora, Spotify and Craigslist, they have never marketed to passengers at all, apart from their signature giant pink mustaches on participating cars. Word-of-mouth marketing at its best, straight out of Seth Godin’s Purple Cow playbook. They have hundreds of registered drivers and tens of thousands of passengers in their first city, San Francisco. The company was nominated for three Crunchie awards and named runner-up in the “Best New Startup of 2012” category. According to TechCrunch, they very recently closed a $15M series B round of venture capital funding and have also just launched their service in a second city – Los Angeles. Open job vacancies make it clear they’re planning significant further expansion.

Competition

The disruption of transportation enabled by near ubiquitous smartphone adoption is an opportunity several startups are attempting to exploit. Lyft faces direct competition locally in San Francisco from SideCar, whilst Uber provide a high end alternative and have stated an intention to create a direct competitor in the lower cost segment. Fairly high-profile competitors with similar technology but not yet competing in the same geographical markets are Heyride, HAILO and Taxibeat, although the latter are enabling existing taxis with similar technology rather than encouraging peer-to-peer ride sharing. There is also indirect competition from existing taxi services.

Business Model

Lyft do not monetize their apps directly, it’s free to download and there are no in-app purchases for new features. Like almost all online marketplaces, Lyft make money by taking a cut of the transactions on the market. In this case the transactions are donations from the passenger to the driver. These are entirely voluntary (which gets around legal issues with drivers using their vehicles for commercial purposes) but the app provides a suggested donation and drivers can set a minimum average donation – passengers that don’t pay much/anything are likely to find no-one will accept their requests very quickly.

Lessons Learned

A successful service is much more than an app. The technology only enables the business at Lyft. Sebastian was quick to point out that the key to the success of the company is the operations team, building a community of drivers and passengers. If they’d simply built the technology and put it out there to see who wanted to use it, it’s very unlikely they’d be enjoying the growth they see now.

Projects will expand or contract to fill the time available to them. The initial concept for Lyft was originally scoped out as an 8-week development for a team of 5 (3 engineers, a designer and a product manager). One of the founders, playing devil’s advocate, said “what if you’ve only got 2 weeks to do it”. This forced them to really cut the concept down to a true Minimum Viable Product. They eventually got the first version built in 3 weeks (server and iOS app) – even today there are still several of their original requirements sitting at the bottom of their backlog unimplemented. The things you think will be essential parts of a service can often turn out to be unimportant for real users.

Team chemistry is essential. It would have been impossible to build such a complex service so quickly without fantastic collaboration. The relationships and collaborative working mode are more important than physical location – Lyft has been hiring top talent from around the world and sorting out visas and relocation to San Francisco afterwards. Sebastian was based in London when he was hired, their iOS lead was in Uruguay and the Android lead in Russia (the extreme time difference was sometimes an issue in the latter case).

What’s in the Lyft toolbox?

Like many successful development teams, Lyft use a lot of third party tools to help build their product:

Also, although they have built their own backend service, creating a highly responsive notification system was a challenge they solved with a combination of polling for updates when sending driver location, the Apple Push Notification Service, Google Cloud Messaging and a paid service from Pusher. However, the latter was initially a source of many crashes due to immature client libraries (Pusher only provide official support for a JavaScript client library, other platforms are community supported).

Sebastian’s desire for the tools space was very much in-line with our outlook in the latest developer economics report – consolidation. Fewer SDKs to integrate and fewer monitoring consoles to log into.

King for a day

Finally, if Sebastian could change just one thing about the platforms he works with, what would it be?

Better support for web/native hybrid app development (Lyft explored and abandoned that approach), with the Android WebView particularly in need of improvement, was a close contender but the top of the list for fixing was the Apple App Store review process.  5-10 days of waiting and they can see from their server logs that the reviewer doesn’t even login to the app with Facebook Connect before approving it. There must be a better way.

Categories
Business

How Much Is An Active User Worth?

Revenue per user

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.

Categories
Business

Revenue Haves and Have Nots

Revenu Distribution by Platform

While not all developers are in it for the money, most would like their apps to provide an income and the majority of those struggle to earn revenues that will sustain further development. We defined $500 per app per month as a reasonable global “poverty line”, in some countries this is very low while in others it’s a very good income. It’s also worth noting that many developers have multiple apps in the market so it doesn’t represent total income. As we’ve highlighted previously, the revenue distribution on the app stores is highly skewed toward the top and this is a major issue for the health of developer ecosystems going forward. Some developers may feel that the level of competition on Android and iOS is too high and they are thus tempted to try one of the smaller marketplaces in search of revenues. Our survey says that this is likely to be a mistake, there is indeed a wide variation in revenue distribution by platform, but the smaller markets have an even higher proportion of developers below the poverty line. The reduced competition is more than offset by the smaller user base at present.

Developer Economics 2013 - Revenue distribution by platform

Around 18% of 3,460 respondents in the Developer Economics 2013 survey indicated that they are not interested in making money from apps. Nevertheless, out of the vast majority of developers that are in it for the money, 67% are not making enough to sustain them or their business, i.e. they are below the “app poverty line” of $500 per app per month. For the majority of developers, app development is not financially rewarding.

Overall, less than 1 in 5 Blackberry developers make more than $500 per app-month. The situation is almost as challenging on Windows Phone where just 19% of developers generate more than $500 per app-month, with 61% below the poverty line. The findings of our survey are somewhat better for Android and iOS although these platforms too, are far from a developer paradise: 55% of iOS and 54% of Android developers are below the poverty line. Excluding developers that are not interested in profit, 62% of iOS developers and 67% of Android developers are not making more than $500 per month per app.

HTML seems a surprise here with just 45% of HTML developers under the poverty line, far lower than any other platform. However, there are fundamental differences between HTML and native platforms which are responsible for the differences observed here: developers using HTML for web development have access to a much larger user base comprising desktop and mobile users, irrespective of platform. Among HTML developers, subscription-based revenue models are much more popular than on native platforms pointing to established online content or service businesses that have expanded on to mobile.

[doritos_report location=’DE13 Article – Revenue Distribution’]

Categories
Business

How Many Users Is Realistic?

Users

One of the most common mistakes developers make when planning the business case for a new app is dramatically overestimating the number of users they will be able to attract, particularly for their first app. The typical argument goes something like this: “My app will be compatible with 400 million devices, if I can reach just 1% of those, that’s 4 million users”. The trap here is that 1% sounds like a very conservative fraction of the installed base to target but in reality it is incredibly high. Of the 664 respondents in our latest survey who integrate user analytics and provided us with their information about the active user base for their most popular app, only 6% had over 500,000 users. The nature of store charts and limited promotional space means that those who break the half million user barrier are quite likely to gain many, many more users than that, however, what’s a realistic figure for everyone else?

One of the more interesting findings we published was that, excluding those with more than 500,000 users, the mean average active user base for iOS developers was 70,000 users vs. 51,000 users on average for Android. The median user base, is 27,500 users for iOS and 15,500 for Android. The percentage difference between means is much smaller than that between medians, suggesting that the distribution of active user bases in general is worth further investigation.

As can be seen from the chart above, 200,000 – 500,000 users is the least common user base size, despite being twice as large an interval as the 50,000 – 200,000 option immediately below it. This suggests that there is a threshold level somewhere near 200,000 users, such that if you break that level you’re likely to “get noticed” and end up with significantly more users. There’s a similar bump near the bottom end of the scale where 501 – 2,000 users is more commonly reported than 2,001 – 5,000 users. This is likely to reflect the difference between apps which are not (effectively) marketed and those that are.

In addition to the platform differences noted above, there are also interesting differences in user base size by revenue model and app category. For example, apps using advertising as a revenue model (and therefore presumably free downloads) are more likely to gain over 50,000 users than other models, whilst freemium shows a very similar distribution to paid downloads. The games category is incredibly competitive and developers there are less likely to have more than 50,000 users, whilst developers in the music and video category had the highest probability of breaking both the 50,000 and 500,000 user barriers. The combinations of revenue models and categories are almost endless but the chart above has dynamic filters so you can explore the opportunities in your own app category. Please let us know about anything interesting you find in the comments below.

Categories
News and Resources

Tablets go mainstream, TV apps still niche

Targeting different screens

In our latest developer survey we asked developers about the different screens they target. The results show smartphones are the most popular target, whilst tablets are catching up fast. PCs are most commonly targeted by web developers while TVs are still a niche app market for all developers.

TV development

The majority (86%) of 3,460 developers in our survey develop on smartphones, while a large share of them also develop on tablets, led by iOS developers (76%) indicating the attractiveness of the iPad as a development and monetisation platform. Despite the rise in Android tablet share during 2012, we did not observe a significant increase in the share of Android developers targeting tablets (64% vs. 62% in our Q1 2012 survey) although we believe this is likely to change in the near future.

HTML developers take a more platform-agnostic approach, as they develop across smartphones, tablets and PCs almost equally, according to our survey, a testament to the use of HTML as cross-screen app development technology. At the same time, HTML limitations, such as lack of support for native APIs, tooling and device optimizations, prevent it from becoming a swiss-army knife for cross-platform development.

TV development remains niche, at the same levels reported in Developer Economics 2012, as the hype cycle around the “Smart TV” experience is yet at a very early stage. This seems in line with findings from research firm NPD, who reports that only 15% of HD TVs are connected to the internet (directly or via a set-top box), limiting their appeal to app developers. Additionally, only a small fraction of those connected TVs use apps for anything other than streaming video or music services. There is a much faster growing trend for the TV screen to be used via smartphone or tablet apps “throwing” content to it.
[doritos_report location=’DE13 Article – Targeting Screens’]

Categories
Tools

Cross-Platform Tools – Does it pay to use them?

Cross-platform tools

In our January 2013 Developer Economics Report, we revealed that multi-platform developers are better off. Our survey data also reveals, rather unsurprisingly, that users of cross-platform tools (CPTs) target more platforms than those building separate apps for each platform. Of those interested in making money, users of CPTs target 4.33 platforms (3.1 mobile platforms) on average vs 3.46 platforms (2.57 mobile) for those building separate apps. We also know that the most popular class of CPTs (using web authoring languages) tradeoff app capability to get the increased portability. At the same time, popular opinion on the internet and amongst venture capitalists is that a cross-platform user experience can’t compete with using the platform native frameworks. So how do these tradeoffs translate into revenue for CPT users?

CPT users make more revenue

On average, CPT users make slightly more revenue per app per month than developers not using such tools. With the reduced cost of development provided by the CPT, this suggests that they’re significantly more profitable.

Averages can be deceiving where the distribution of results is far from normal, as with app revenues, so it’s worth examining the details. App revenue is heavily concentrated at the top end of the market, with a large fraction of the (mean) average coming from a small number of very high earners. If we exclude all developers earning more than $50k per app per month then the result holds – CPT users still generate more revenue.

Not all CPTs are created equal

There are also several different types of CPT. Games have been responsible for close to half of all app revenues (at least those generated directly through app stores) and since they typically don’t require many platform-specific APIs or UI elements, they’re a good candidate for building with cross-platform. This suggests that users of primarily games-centric CPTs like Corona, Unity 3D & Marmalade might be responsible for the out-performance of CPTs, while users of the low development cost tools taking advantage of web authoring languages, such as PhoneGap, Appcelerator, Brightcove & Sencha, generate slightly lower revenues. However the data shows that the opposite is in fact the case.  Users of the games-centric CPTs are generating below average revenue, whilst the web-centric CPT users are significantly better off. These results also hold whether or not we include those earning over $50k per app per month.

A plausible explanation for this is that most of the larger and more successful game developers are managing their own cross-platform compatibility or code re-use whilst many smaller independent game developers relying on 3rd party tooling are struggling with the fierce competition in the games market. At the same time it seems that, when it comes to revenue, a fully native user experience and native performance are not as important as their proponents suggest. The very high earners using web-centric tools are most likely to be existing publishers selling their content through mobile app subscriptions and our revenue estimates are probably too low, since the top income band in our survey is everything over $100k per app per month.

Both ends of the revenue spectrum

For several CPTs in our survey we didn’t have enough respondents to be sure differences in revenues for individual tools are statistically significant, however, there are a couple of individual ones worth highlighting. At the low end, revenues for Qt developers were significantly below average – this probably reflects the fact that Qt does not yet have official support for iOS or Android (planned for this year). At the high end, although we only had a relatively small sample, revenues for Brightcove App Cloud users were more than 3 times the average making the difference statistically significant, whether or not we include those generating over $50k per app per month. Brightcove appear to be focussing their solution on a particularly profitable market segment.

Tool selection – do it for the right reasons

Finally, if you’re looking to select a CPT, make sure you do it for the right reasons. Main selection criteria including access to native APIs and the ability to create a native UI look and feel are correlated with above average revenue, whilst the availability of third party extensions and choice of authoring languages are correlated with below average revenue. The former criteria look to minimise some weaknesses of the cross-platform approach whereas the latter criteria focus on reducing one-off costs. The latter are not necessarily bad reasons for choosing a tool but if they are amongst the most important reasons for your selection then it’s worth re-evaluating priorities. Work out what will enable the creation of the best product at acceptable cost rather than simply minimising cost. If the lowest possible development cost is critical to make the app concept viable then it’s probably time to come up with a higher value concept.

Categories
Languages

HTML5 vs Native – What are the tradeoffs?

HTML5 vs Native

In our latest developer survey we asked developers who use or plan to adopt HTML5 why they do so and also what the technology needs to compete with native alternatives. The results show a tradeoff of increased portability and lower development cost against capability, in the form of reduced API access and a poorer development environment. In this scenario, the key to success with web technologies is taking advantage of their strengths in areas where their weaknesses are less of a handicap.

Developer Economics 2013 - HTML5 trades off native optimisation for portability and cost

HTML5 is becoming a viable alternative to native development across a number of app categories. We found that HTML developers mainly focus on specific app categories such as Business & Productivity (42% of HTML developers), Enterprise (32%) and Media apps (28%). On the other hand, Games are not a common category among HTML developers (12%).

We asked developers that use or are planning to use HTML about the reasons for platform selection. The majority indicated code portability as the main incentive for using HTML5. Low cost development is the second driving force for HTML5 adoption, highlighted by 51% of developers. HTML is still an “extension platform” in that only 26% of developers who use it consider it their main platform. We asked developers that use, have used or are planning to use HTML what they think HTML5 needs to compete with native platforms. Access to native APIs is a top challenge with 35% of developers indicating this as a critical success factor. HTML5 will always be a step behind in support for native APIs, given that cross platform tools and browser vendors will always have to implement support for a new API after it is released to developers by the platform vendor. In addition, the HTML5 development experience is subpar, with developers indicating that a better development environment (34%) and better debugging support (22%) are needed. More importantly, optimised HTML5 devices were not seen as important as the native API access or dev environment. This leads us to conclude that HTML proponents such as Facebook, Mozilla and Google should focus on cross platform tools and development environments on at least equal levels as they focus on full platform efforts like Facebook Platform, Firefox OS and Chrome OS.

[doritos_report location=’DE13 Article – HTML5 vs Native’]

Categories
Business Tips

The Costs of App Security

app security costs

The security features of an app are often ignored in the rush to get a new product to market. We naturally tend to focus more on what an app should do, rather than what it shouldn’t. Making sure that an app doesn’t have security issues is a difficult and potentially expensive process. Lately there is evidence that developers are trying at least to face app security costs issues. A recent post from our partners in DZone shows exactly this.

There are no automated tests to ensure user data hasn’t been left vulnerable. This goes for unencrypted passwords as well. Typically this requires a manual audit of the code and some form of penetration testing, with a skilled developer attempting to compromise the app. However, the costs of implementing security features and adding security testing to your development process are much smaller than the potential costs of a major security breach.

Problems with payments

For some types of app the consequences of this are more obvious. There are even standards in place to try to ensure a minimum level of security. For instance, any application which handles payment card details needs to process that data securely as specified by the Payment Cards Industry. However, PCI standards compliance is only audited for large merchants. Smaller merchants self-certify compliance.

If an app or service for a small merchant was compromised, resulting in abuse of payment card data, then any non-compliance discovered could result in significant fines or even liability for any fraudulent payments. Merchants who add interfaces to their existing payments infrastructure to support mobile apps need to be particularly careful. New attacks can be made possible when the payment authorisation occurs on a native mobile client, rather than a website.

Even for apps selling digital goods via in-app purchase there are still payment security issues to consider. Of course stakes are nowhere near as large. However, attackers can still impersonate the official store provider servers and simulate in-app purchases without any genuine payment.

Apple’s system was compromised in this way last summer. Another hack was reported for payments on Google Play just before Christmas. There is no link to this because, although it was only for rooted devices, we’re not aware of a fix in place yet. (Indeed it may even be a scam to get users to install malware).

Losing data can cost you even more

For enterprise app developers, being associated with a major security breach could mean the end of your business.

A harmful loss of data for a client could send valuable market data go to the competition, or even key employees. You would lose trust (and business)! If the breach is sufficiently public, you could lose the trust of all potential future clients as well.

The larger a company the more vital it is that they implement good security practices.

For consumer apps, leaking user data to attackers has direct costs. Firstly, in terms of service downtime whilst fixing security holes (usually in a hurry with the aid of expensive experts), notifying those affected and possible compensation. Secondly, there are serious indirect costs in terms of lost trust and users. Again here, the larger the user base, the more attractive the app is to attackers and the more serious any breach.

Invest in app security appropriately

Investments in security need to be proportional to the risks. How many users are involved and the value of data stored should determine the level of effort required to ensure that data is safe.

Not knowing about the security implications of your application is somewhat like driving without insurance.

Everything is fine until the unthinkable happens. Then it’s likely that lots of innocent people suffer and you get into a lot of trouble.

The technical details of app security are beyond the scope of this post. However, we have prepared a list of top 10 vulnerabilities and how to avoid them. Read on if your app deals with any user data or payments.

Categories
Business

How to Get App Ideas

How do you decide what app to build next? Paul Graham wrote an excellent post about the related problem of finding an idea for a startup. Paul says:

The way to get startup ideas is not to try to think of startup ideas. It’s to look for problems, preferably problems you have yourself.

The very best startup ideas tend to have three things in common: they’re something the founders themselves want, that they themselves can build, and that few others realize are worth doing. Microsoft, Apple, Yahoo, Google, and Facebook all began this way.

However, it should be noted that when Paul Graham says “startup” he does not mean any new company, only the hyper-growth variety that are often funded by venture capital. It should be noted that the vast majority of these companies fail. So, if you’re building a business around apps and are aiming your sights a little lower than “the next big thing” then our survey suggests that solving your own problems might not be the best option. 49% of developers build apps they want to use themselves, but end up generating the least revenue.

Beware survivorship bias

The following data should be interpreted carefully, some of the most successful strategies are only viable for larger publishers, or only available for those who already have a successful app – this creates survivorship bias. However, there appears to be a strong correlation between more carefully researched methods of deciding what app to develop and financial success.

Developer Economics 2013 - Successful developers grow by extending apps into countries and verticals

Business side of apps is harder than the technology

Almost half of developers (49%) in our survey decide which apps to develop based on their own needs. Those same developers end up generating the least amount of revenue per app per month, indicating that they have a lot to learn in how they plan their app business. Naturally, planning a business based on own needs may yield a good customer understanding, but lacks the rigor of market research or of extending proven app recipes into new countries or verticals.

User feedback is effective but hard to get

We find it remarkable that only 24% of developers in our sample plan their apps based on discussions with users, a figure which does not change with development experience or proficiency. This indicates that the bottleneck of the build-measure-learn cycle of lean development is the “measuring”, or listening in to user needs. This highlights the need for a frictionless 2-way feedback channel between developers and users, much like what GetSatisfaction pioneered for web apps, and which now HelpShift is pioneering for mobile apps.

Market research pays off

To decide which apps to build, a sizeable share of developers uses market research and competitive intelligence. Market research and competitive intelligence are well-established practices in business development and we expect that the increasingly business-savvy developer population will, in the near future, invest more effort in these elements when designing a product strategy.

Bigger publishers have more options

Developers that publish more apps per year tend to make decisions based on different criteria than those publishing only a few apps per year. For developers publishing 16+ apps, the decision mainly lies with clients or management – these are mostly professional developers that work on commissioned apps or as employees of larger publishers where the decision on which app to work on is mainly based on a defendable business case. Developers publishing more apps also tend to rely on market research more, whether that is purchased research or own research through app store monitoring and analytics services.

Build on success

The most successful strategies are those that extend an app into markets, either into verticals or different geographies. To some extent these strategies rely on an already established and successful business: these are apps that have been tried and proven in at least one market and are generally less risky options or “low hanging fruit” for developers.
[doritos_report location=’DE13 Article – App Ideas’]