The Best API Strategy For A Consumer App
There are three main API strategies for a consumer app: (1) start with an open API that you eventually restrict, (2) create an open developer network that you commit to support for the long-term, or (3) wait to expose an API only to select developers.
Open The API, Then Squeeze It
The biggest reason to have an open API in the early part of a company’s life is to fill in product gaps that can’t be filled by the company itself. By looking at the history of numerous successful consumer internet companies, we can see a clear process: First, the company grows the product development team enough to turn its attention to non-core problems and features. Second, they look at the developer ecosystem to determine popularity of third-party apps, and thus the priority ranking of features to build or acquire. Third, the best in class apps are acquired or built. Fourth, once key functionality is brought in-house, competing apps are methodically pushed out. While this strategy may seem harsh, there are many examples of it being implemented successfully:
- Before Twitter had mobile apps of any kind, consumers used third-party apps. Eventually Twitter bought TweetDeck, then announced that they were no longer allowing new apps for consumer consumption of tweets. Most recently, Twitter gave Meerket 2-hours notice of their expulsion from the API due to their competitive nature (which resulted from Twitter’s Periscope acquisition). They also recently cut of firehose data partners so they can control and monetize data feeds themselves, but that is more akin to an enterprise-facing API, rather than consumer.
- LinkedIn announced in February that they are now restricting API access to a short list of developers who create specific value for LinkedIn.
- Instagram, having originally relied on third-party apps for desktop and Android access, seems to be tightening the noose. In April they banned new third-party apps from liking or following content on behalf of users without an official Instagram blessing. This trend continued with the blocking of Phhhoto for replacing the core Instagram experience.
- Spotify made a splash with it’s App Finder in 2011, but eventually dropped it altogether in late 2014, leaving developers scrambling for exits.
- Netflix stopped issuing API keys back in 2013, after they had developed for sufficient platforms.
Even consumer apps without public APIs have benefited from the reach of unauthorized apps, but they been increasingly blocked for reasons of (1) homogenization and improvement of customer experience, (2) security, and (3) monetization. Snapchat was left holding the bag when a developer, Snapsaved, had been storing snaps, and of course they got hacked and leaked. Snapchat doesn’t have an open API, but third-party apps have popped up nonetheless. WhatsApp has experienced similar issues and has actually been banning users for using such unauthorized apps.
The long embrace of developers
Of course there is a strong opposing strategy, particularly when considering third-party development more broadly, including both APIs and SDKs for native development. This strategy involves creating a consistently supportive environment for third-party developers, usually one that fosters a major revenue stream for both platform and developer alike. Apple, Facebook, Microsoft, and Google are perhaps the most shining examples of this, with the prevalence and support for the App Store, Facebook, Windows, and Android ecosystems. This has resulted in vast access to apps and developers that have greatly increased (and in many ways defined) the value of the original platforms.
Steve Jobs once proudly proclaimed that no native development was necessary for the iPhone, and yet Apple has come to define the modern app store. Since then, Apple has paid out $25B to developers of 1.4M apps. Google’s Android isn’t far behind, having paid out $7B to Apple’s $10B in 2014. These are such massive, broad computing platforms that third-party developers are a necessity. In contrast, the previously mentioned consumer platforms are mostly just platforms within platforms.
Executing this developer-friendly strategy can result in the ultimate in high quality third-party products, and can prevent sour relationships with developers and the consumers who used their apps. However, even these platforms compete with their apps by often creating their own features designed to replace the need for other apps. For example, Apple created Apple Maps to negate Google Maps, and launched many smaller apps like Cards or features like Flashlight, much to the chagrin of certain developers.
The Slow Roll
Pinterest is an interesting example of something that doesn’t quite fall into either of the previous two categories. They have very slowly and methodically opened up API access, focusing on platform-level integrations the likes of which you see with Facebook. This started with brands and retailers wanting to show popular product pins, and has since expanded to include select developers. Other major companies like Uber have also began with slow API rollouts as well, and perhaps these serve as the new model: forego the early-days benefits of using developers to fulfil missing features, then deliberately only allow API apps that serve use-cases you can’t build internally.
Regardless of the strategy employed by a consumer app or platform, a thriving third-party ecosystem is a sign of (or result of) a strong consumer base, and deciding how to deal with API apps is best done earlier in the life of the company. The right strategy will depend on the company itself. While companies with business-oriented APIs and features do not necessarily follow these strategies, among consumer-facing companies, huge networks and computing platforms are probably best served by embracing developers for the long-term. On the flip side, we’ll see fewer open APIs in the future as well-funded consumer apps increasingly value consistent and tightly-controlled user experiences. Their more lean brethren, however may continue to need the help from developers.
