Scaling Your Developer Community Platform

Last week I attended Endpoint Conference in Amsterdam with the intention to gain more insights on the proper way to scale our API and Developer Community Program. The conference, set in the beautiful Tuschinski movie theatre, brought me much more, as its laid-back atmosphere was the perfect environment to start great discussions, brainstorm on new ideas, and make new friends!

I was particularly excited to hear Kamyar Mohager’s keynote speech (LinkedIn) but also see David Hu (Foursquare), Mehdi Medjaoui (, Phil Nash (Twilio), and Steve Klabnik (

Here are some cool mottos I’m bringing back to the office with me:

“Be transparent”

Your developers should not be the last ones to know when an endpoint is down. Your platform should reflect which endpoints are working both internally and externally. It is not ideal that your own team the last one to know when something is down, with developers emailing you in panic because they have no idea what is going on. Set up internal and external monitoring tools that are available to everyone so that you and your developers all are kept in the loop!

“Eat your own dog food”

Kamyar’s idea of the best way to scale a developer program is to base your internal tools on your API. Use it, love it, hate it, and get into bed with it! Basically, become your own API user so you know first hand what’s great and what’s terrible. This way, you will provide a better user experience for the product.

“Be API First”

Kamyar’s look back at the old way LinkedIn built its API hinted an API that did not reflect what key partners were looking for. His advice: Instead of going with the “build it, then they will come” strategy, try revolving the API and its documentation around key partners, their use cases, and what they expect from it.

“Don’t build what you can buy”

A lot of times you want to jump straight into developing cool monitoring tools for your developers though you don’t know whether there are already great tools out there. The trade-off in build vs. buy is obviously tech debt vs. cash/customization. Here are some great tools: Apigee for REST console, for API monitoring, Mashery for overall API management, and there are a lot more to be explored. (Share your favourite tools in the comment section!)

And now some great tips:

Reduce the time to 1st Authenticated Call:

It is straightforward yet it’s never given enough attention! The idea here is to focus your documentation and naming conventions (in URIs, parameters,etc.) to make sure your developers just get it and can start making calls right away. Foursquare does a great job at this.

Handcraft your SDKs:

Phil Nash from Twilio gave a very inspired speech on creating libraries for your developers. Though it requires more time and resources, manually writing SDKs rather than having them generated alleviates a lot of potential frustrations and adds so much more value to your product.

Overall I’m convinced API really is a product and the need for UX designers for API and documentation is confirmed. Hello developer evangelism!