Why to Think Twice Before Founding an API Startup, Or Acquiring One

Back in 2005, when I bore witness to the debut of the first two Web APIs (Google MapsTrack this API and FlickrTrack this API) while working as a journalist for CNET, I knew something big was about to happen. To this day, it is still one of the most dramatic tipping points our industry has ever seen. To the extent that operating systems (Windows, Mac, Linux, etc.) are primarily a collection of APIs, the Web was about to become the next operating system. Only the collection of APIs would be different. Instead of driving internal system value (like an API to paint a window on an LCD monitor), these APIs would drive business value.

What I didn’t even consider back then is how APIs would become the new developer leverage point — or should I say “lock-in” point — of application ecosystems. For decades, purveyors of operating systems and OS-like platforms have made it a practice to addict developers to their APIs such that the cost of switching to another OS or platform is just too unbearable. But middleware and, eventually the Web, pulled the rug out from under such lock-in strategies. Anyone who was depending on system level APIs to trap developers lost most of that leverage. Only in certain circumstances is application availability the deciding factor in operating system purchases.

Today, with the exception of some proprietary hardware-oriented APIs found in iOS and Android (any of the important ones eventually get leveled off by a Javascript/Browser equivalent), system level APIs are no longer the primary building blocks of today’s applications. On the desktop, APIs leveraged by virtual reality and games are also an exception.

One of the beautiful things about Web APIs (and the simplicity of calling them) is that, theoretically, making a substitution is relatively simple. Most Web API calls can be manufactured in a few lines of code involving HTTP verbs like GET or POST. So, substituting Twilio’s SMSTrack this API API for Nexmo's or vice versa — two APIs that do pretty much the same thing — shouldn’t be too difficult. But the dirty little secret is that once code is written, regression tested, and put into production, everyone up the chain from developers to product managers is loathe to change it.

Here at ProgrammableWeb, we are routinely faced with that exact decision. Under the hood, we use Nexmo to text one-time access codes to API providers looking to add or maintain APIs and SDKs in our directories. Over the last few months, Nexmo has emailed me multiple times to notify me of price changes. But, if it ain’t broke, don’t fix it. No matter how easy it is to swap-in a few lines of code, the overall cost and disruption of making the substitution is just too much to even consider it. Unless something seriously goes wrong with Nexmo (or Twilio makes us an offer that’s too good to be true), we’re stuck with Nexmo.

So, it should come as no surprise that many of the old platform providers who depend on similar developer “stickiness” are moving upstack to where the stickiness is; at the web API level. Twilio and Stripe for example (the former of which is public) will not last long as independent players. Traditional platform players like IBM, Microsoft, Google, and Oracle that depend on the lock-in effect will eventually succumb to the pressure by scooping-up these and other promising API providers at a faster clip than is already happening (a trend that IBM may have kicked-off when it acquired AlchemyAPI and absorbed it into its Watson brand).

However, as romantic as this sea-change sounds (and as inviting as it is for all sorts of startups and their backers), such acquisitions may not be slam dunks; something that founders of API startups and any potential suitors need to think about as they venture into these uncharted waters.

One case in point is Wunderlist which was acquired by Microsoft in 2015. Wunderlist was a wunderkind To-Do list manager with a strong following from both end-users and developers. Microsoft may have missed the boat when it came to securing its place in history as one of the top mobile operating system providers. But, with web APIs being the new leverage points that they are, Microsoft and other IT vendors still have an opportunity to stake their claim on the mobile landscape by providing APIs to compelling functionality. For example, functionality like what Wunderlist has to offer.

Based on reports however, this was no match made in heaven due to three somewhat conflated reasons if you try to read between the lines of what Wunderlist founder Christian Reber has said. First, Microsoft’s desire to reproduce Wunderlist’s capabilities in Microsoft own to-do app, (aptly named "To-Do”). Second, migrating the routes for Wunderlist’s Web API to eventually hit To-Do’s corresponding endpoints rather than the old Wunderlist endpoints. And third, to migrate Wunderlist's API (or some morphed version of it) to run on Microsoft Azure instead of the Amazon Web Services-based stack that Wunderlist was originally based on.

Based on what Reber is saying, the project has come off the rails. Reber left Microsoft last year, shortly after To-Do launched, bearing striking similarities to Wunderlist.

According to The Verge’s translation of Reber’s tweet stream:

"There were technical porting challenges,” explains Reber. “Wunderlist’s API runs on Amazon Web Services, and should then be ported to Azure. But that was extremely time-consuming, so everything had to be rewritten.” The process of rewriting an entire app is clearly complicated, and as Reber puts it “easier said than done.” He also reveals that the original goal was to run Wunderlist for a year and then have Microsoft To-Do ready, but the porting from AWS to Azure means Wunderlist has remained online.”

A trained cheerleader of API-led application networks might ask how this could have taken such a turn for the worse. After all, one of the chief selling propositions of APIs is their technical “contracts”; the lingua francas of the conversation between API consumers and providers. For any API, the technical contract is what decouples the concerns of the API consumer like a mobile app from those of an API provider like Microsoft (To help explain this bit of voodoo, I demystify the API contract using electrical sockets, Lego, and shipping containers as metaphors in this video).  Both the consumer and provider should essentially be able to operate in their own bubbles, changing any all or all aspects of how they work, without impacting or imposing on each other.

Be sure to read the next API Strategy article: How to Ensure APIs Drive Everlasting Organizational Value

 

Comments (1)

aweston

Thanks for this article, it's a cool read.  It's kind of ironic too that I think the Outlook Task API is moving to the Microsoft Graph API?  So more pain on the client side there again.  I've seen server side shims or adapters for handling translations like this.  Maybe it's time for client side shims too.  Not as easy as it sounds.  More likely an opportunity to write a whole new client.