Any software startup launching in 2014 has to abide by two rules.
The product must be mobile-first, if not mobile-only. The desktop, at least from a consumer perspective, is on its way to extinction.
Secondly, developers must build native apps for Android and iOS. A few years ago, there was hope that HTML5 would deliver a viable cross-platform alternative to native apps.
The technology, however, has fallen short, particularly regarding speed and support for offline situations. And the major platforms all started to dramatically favor native development by withholding key distribution tools—push notifications, badges, bookmarks and app store distribution—for native applications. Doing so has been in their interests because it generates lock-in for developers.
But the importance of native has created a big tax on developers. While almost every aspect of development has been getting easier and cheaper, the need for mobile native applications has made it orders of magnitude harder for companies to build innovative new services. This is especially true of any sort of networked application.
This explains why the top application charts are generally dominated by older companies, not startups. And it leaves today’s startups trapped by hidden costs not often discussed.
Why Building Native is So Expensive
Building native can seem more expensive because you have to build an app twice (once for Android and once for iOS) instead of just for the Web (leaving aside the fact that the Web isn’t quite standardized).
But the true tax of building native is much greater. First, there is a huge compounding tax in supporting legacy versions of an application. You cannot expect all your users to upgrade to any new version of your application, which means that you either need to abandon your old users or continue to support old features and interactions. Both are hard and make big changes in functionality tough to pull off.
Second, there is a big development speed tax in not being able to push fixes on the fly. Web-based services can run fast because they can update their services on demand, without waiting to release new versions of their app. Not so with native applications.
Pushing a new release and getting adoption is time-consuming, and so bugs and updates are far more expensive on mobile than on the Web. Therefore, developers, have to test more, and more testing means moving less quickly, which is extremely taxing for small companies in an experimental mode.
Third, there is a huge internal coordination tax on companies maintaining mulitple applications. With one main product, it is fairly easy to communicate across teams. But when you have to have multiple teams working on multiple applications on multiple platforms, it’s much harder to ensure that teams are synced up.
The net effect of these costs is that building native apps means a company needs far more than double the number of engineers, product managers, and designers it would if it could rely on the Web.
WhatsApp, Snapchat, and Instagram
WhatsApp, Snapchat, and Instagram—which launched in the window between 2009 to 2011 and have seen skyrocketing growth—appear to be counterexamples that overcame the additional costs of native.
The three provide some clues on how developers can mitigate the challenges around native apps.
All three started on iOS and waited a year or more to build on Android. Despite the fact that all three products are fundamentally networks, that strategy worked back then. But it is less viable now due to Android’s strong market share.
All three services have relatively simple products. WhatsApp is probably the purest example here. The company did something relatively simple from a product perspective—messaging—extremely well and focused the vast majority of its attention on performance.
Third, all three, once they really got their feet under them, continued to double down on the core thing they started with. Outside of the Instagram original pivot from a location-based service, these are companies that effectively got it right the first time, thereby avoiding the challenging tasks of shifting product strategy on native mobile apps.
Today’s developers need to do the same and focus on building a simple app that can “win” from the start, as opposed to evolving over time.
It is always hard for companies to evolve, but it is especially hard in today’s landscape. So, companies that “win” are companies that win early in their history and then refine what they do rather than iterating into success.