Menu

Speculation from a NYC venture capitalist

APIs First

Lots of discussion about whether a service should be “mobile first” or “web first”. I tweeted it actually should be “API first”, and I got a lot of reaction to that comment and asked to expand.

First let me clarify. I believe mobile IS important and a huge emerging channel. Source of traffic has shifted dramatically and I don’t have my head buried in the sand in that regard. Across many of my companies, mobile origination (tablet included) comprises anywhere from 30-50%+ of traffic. I recognize that access patterns have structurally changed.

When I say API first, I mean that an idealized service needs to start with a core infrastructure with robust APIs that is tapped into via any number of “front ends”: web, mobile, and even 3rd party ecosystems. If you look behind many “web first” companies today, including in our portfolio, you’ll see a very clean architectural split between the front end and the back end. The back end exposes a range of services that allows the front end to innovate independently and be re-purposed in interesting ways depending on changing business needs. The rate of change on the front end is usually a LOT higher than in the back; the scale and stability requirements on the back are far more demanding than on the front.

“Mobile first” companies really are just a front end selection accessing a solid API driven backend infrastructure. The use case, the logic, and what the app is optimized for may be a subset or different than Web, and I think this is what Fred Wilson and others are focused on.

But as I look at the world, while point of entry may vary, I believe having all three elements of web, mobile and 3rd party are going to be table stakes in the future. You CANNOT be one only. Users want different experiences for their different point of engagement. Mobile is about speed of access, much more transactional and timely, very much about getting something done. The web is great for researching, deliberating, and exploring. Both are different aspects of the same service, and I’d want both as a user depending. Finally, enabling third parties is a realization of the web services and SOA manifests from the late 90s that allow for programmatic distribution and can launch powerful new economic models.

Facebook has already shown us the above and what a powerful, mature, winning service looks like. They have their core site, their massively used mobile applications, and their various graphs 3rd parties access which gives them tremendous power, platform extension, and plata. Instagram, normally cited as the poster child for “mobile first”, recently announced they intend to move consumption to their core web site.

So to wrap up, sure, there might be some apps that are best started purely in a mobile context. But I’d bet 99% of the services out there will have to incorporate all three elements and that starts with building an incredibly solid foundation. API first, front end second, all screens third.

Nicely written. I have to comment on the mobile first approach. I’ve seen companies go down this route only to end up ripping things out and having to create an API because they could no longer keep base with the number of features they were creating for a wide array of devices without a central contract to dictate what gets added and what doesn’t. Database locked in individual device in their own little islands…. It’s almost like creating the API is the natural series of steps in a mobile app based company.