Why You Shouldn’t Build A Business On An API Call

Next Story

Report: Europe Inching Closer To Fining Microsoft Billions Over Failure To Offer Internet Explorer Alternatives

Editor’s note: Joseph Puopolo is an entrepreneur and startup founder of Printchomp who blogs on a variety of topics, including green initiatives, technology and marketing.

I am constantly amazed by the number of startups that build applications and take a huge business risk by building their company on an API call. Countless apps, particularly social apps, have popped up through the last 24 months that have taken data from other systems and re-displayed it in their systems. While there is widespread usage of APIs (and not for a moment am I suggesting that people not use them at all), I just think that start-up founders consistently underplay the business risk.

The risk is clear, if the data dries up so does your business. For all that have created apps based largely on API calls, consider what would happen if that information fire hose wasn’t there anymore. The companies who provide these APIs may not disappear, but it will definitely be a game-changer. The changes to Twitter’s API should serve as a warning sign and an important reminder. Countless third-party Twitter apps have found all their hard work rendered useless by the latest release of their 1.1 API, as the vital flow of data has come to a halt or slowed greatly. Some might blame Twitter and say how dare they shut down the fire hose to the community. I think a lot of responsibility needs to be placed on the developers who consciously build on an ecosystem they knowingly can’t control.

Two examples cited directly by Michael Sippey on the Twitter blog are Tweetbot and Echofon. In the words of Sippey, “Nearly eighteen months ago, we gave developers guidance that they should not build client apps that mimic or reproduce the mainstream Twitter consumer client experience. And to reiterate what I wrote in my last post, that guidance continues to apply today.” I am not here to parse the he said she said, just to offer a warning to startups building their business on an API.

If your startup could have its throat cut by a TOS (Terms of Service) change or API change, you shouldn’t just brush inherent risks to your company under the carpet. Moving beyond the risks to your company you should also consider what the true value you are providing to your users. In many cases (especially in the case of social), apps merely have a new UI on top of the information of Twitter or Facebook.

On the contrary, there is something amazing to be said for companies who build into the ecosystem and allow their functionality to be seamless across a broader group of applications. The best example that comes to mind is 37 Signals universe and the way they have built and integrated into countless other useful applications. They allow vital business information to flow freely flow between systems.  The trouble I have with many other companies and apps that have emerged is their sole dependence on other ecosystems to drive data into their systems via an API.

Perhaps I have an old-fashioned view of the Internet when I propose the following.  Your application needs to be able to offer some additional value beyond what you can drive via an API call and the subsequent data derived from it. There are definitely edge cases for this statement, but there is an underlying problem in how people are approaching the creation of a new business. Create your own mechanism for your users to contribute data into your system and encourage them to be active users with their own accounts in your system. Your system needs to be able to able to stand on its own two legs. For many young startups, API calls have become a crutch in lieu of generating their own data.

Some soul searching needs to occur for a lot of young entrepreneurs who are trying to create something people will find interesting and use. Just because you can make an API call and slap a slightly new UI on it doesn’t make it a business.

[Illustration by Bryce Durbin, based on Zimbbos]