The two dimensions of application programming experience (APX)

The two dimensions of application programming experience (APX)

imageThis post is influenced by a recent discussion on the Developer Evangelists group on LinkedIn about “What developers want from API providers.” I bring together various trains of thoughts here.

What developers want from API providers ?

There is an upcoming notion of APX – the application programming experience – first described (I believe) by MuleSoft CTO Uri Sarid in his post “APX is to API as UX is to UI” on Wired.

In my view there are two dimensions of APX: First, the APX an API management solution delivers to the asset provider. That is, for instance, how easy is it to encapsulate and describe assets in an API and then expose it. Second is the APX that the API provider delivers to the developer who wants to use that API in her software products. The second dimension is also referred to as developer experience DX (see my earlier post “Developer experience – because developers are people too”). I will focus on the latter dimension in this post.

Generally the purpose of an API is to reduce the friction in getting access to and using a particular asset. Additionally, also the friction in using the API itself needs to be reduced to improve the DX. The notion of TTFAC (time to first API call) comes up. The discussion on the Developer Evangelists LinkedIn group was triggered by a talk of StackMob’s Sid Maestre at the Business of API conference where he presented three things as important for developers to reduce that API usage friction (Sid’s original post):

  1. Allow quick wins (i.e., lower barriers to understanding and using the technology)
  2. Speak developers’ language (i.e., understand the different pain points of different developers and address them accordingly)
  3. Involve the community (i.e., provide blueprints and best practices and be open to allow user-generated evolution)

Based on that, Maurice Sharp made a great suggestion for a model that comprises 5 elements on the road to developer happiness:



If an asset holder decides to externalise these assets through APIs as part of a wider API strategy (embedded in the overarching business strategy), then the first thought must be “which (ideally unique) value can we provide developers?” This can be monetary value but also others such as a way to increase reach, brand awareness, customer base, indirect sales, or the pure joy of using great technology that works. That is why it is so important to understand the profile of an API provider’s developers as I wrote in “What mobile app developers want.”

The technology element refers to how the API is implemented and provided. Is the API provided using, e.g., REST or SOAP? Are the APIs wrapped in SDKs? How functionality-rich is the developer portal? Is open-sourced sample code provided? Are there any testing facilities or API consoles/explorers? All of which will lower the access barriers for developers.

With the marketing element an API provider can help developers being attractive to their customers. Brand awareness and perception plays a role. Many times certain brands or the perception of a solution are not suitable for certain customers. Promotional support for the developers’ products could be provided via the API provider’s portal, for instance, as case studies or developer spotlights/interviews or even functionally embedded in your APIs (for instance, by providing freemium models or recommender algorithms).

The distribution is about how the API provider can support the developers to get the products to their customers and how the revenue model is specified. Depending on an API providers business model there is a wide variety of different revenue models, some of which are described in John Musser’s presentation about “API Business Models.”

Finally, support is about how the API provider supports her developers directly. Examples include forums, FAQs, or real-time chats. Ideally, the API provider can also provide mechanisms where the developer’s customers can get support. The purpose of support of course is to maximise customer satisfaction.

This 5-elements model is generally applicable as a strategy. When it comes to practical execution, the tactics need to be fine-tuned to the particular developer segment and its requirements. As always, a meticulous customer understanding is crucial in shaping the product offering (which in our case is an API plus the whole APX around it). In addition to my post I mentioned earlier, Vision Mobile published a very useful article about “The hierarchy of developer needs.”

I cannot stress enough the importance of understanding what an asset holder wants to achieve by exposing assets via APIs. Sid mentioned a great example of a company having a not yet ready API strategy: The question “What’s in it for the developers”, was encountered as, “we were hoping our Developer Evangelist would figure that out.”


Make sure that there is a purpose in exposing APIs and that this supports the wider business strategy. Then, have your customers (=developers) in mind and try to understand their needs as clearly as possible. Based on that, provide something of value to them. If all that is figured out, do everything to lower the barrier to find and especially use the assets and the APIs. Again, do this with your developers in mind (e.g., don’t write documentation for you but for the developers using it).

This post was originally published on

 Here is another blog post on Pusher talking about DX.

Related Stories

Leave a comment


This will only be used to quickly provide signup information and will not allow us to post to your account or appear on your timeline.