API First

Alex Meyer
Maximum Tinkering
Published in
3 min readJan 27, 2017

If you’re building a digital product or have built one, you’ve most likely heard of the debate between web first and mobile first. In short, the debate is about choosing which platform to focus on first when building a MVP (minimum viable product). Fred Wilson wrote a good piece about it here when mobile was quickly gaining a lot of attention from product teams.

Mobile has since lost its edge as the platform of focus for a lot of product teams because it has gotten crowded and there are a lot of new platforms bursting on the scene (AI, chatbots, VR/AR, etc.). Google even recently called itself an AI first company. But I think there’s another way of thinking about building a digital product, and that is API first.

What I mean by API first is focusing on building your core API as a product before focusing on another platform. The great thing about focusing on the API first is that it makes it easier to tackle building your product for other platforms and interfaces. Once your team has built an API, you can focus on building your product for whatever other platform potential customers may be using, or whatever the next big thing is. In a sense, it “future proofs” your product because no matter what the next big thing is, your product will be ready for it. You won’t have to rewrite everything in order to support the new platform.

Now, I know there are probably a lot of engineers reading this and rolling their eyes saying you should be building products like this anyway! And you’re right, a smart product team will do this anyway when they build their product for one of the other platforms. However, often these APIs are kept private and not thought of as products themselves, but rather as a component of another product.

All of that is starting to change. Amazon recently announced a way to make it super simple to monetize an API built with their API Gateway product. In addition, 21.co is enabling bitcoin-payable APIs. This means your API can now be a product itself. You make money by charging others who consume your API.

The API as a product isn’t an entirely new idea, some examples include Cloudinary, AWS itself, and Api.ai. But what these new developments do is make it really easy for any product team to monetize their APIs.

I think this could have been an interesting route for Twitter to go in its early days. You could even make the argument this is what they did unintentionally. When Twitter first burst on the scene, there were lots of clients built on top of the Twitter API. But instead of thinking of their product as their API, they thought of their product as their own mobile and desktop clients where they could serve ads and make money that way. In an effort to channel more eyeballs to these products, they cut off a lot of the third-party developers that were consuming their API, and were left with arguably mixed results as a business.

Various Twitter clients (photo cred: Trusted Reviews)

So if you’re on a product team, in the midst of building a new product, or are thinking about building a new product, I encourage you to give the API first approach a consideration. Afterall, having another way to make money can’t be a bad thing for a startup.

--

--