Quotes from Erik Wilde’s talk at #APIDaysParis
“Nobody wants APIs. They want to get stuff done. Everyone needs APIs, but APIs are not the important thing. The important thing is the capability we wrap in the API.”
“If you wrap something super duper useful in a badly designed API, people will still use it! They won’t be happy, but they’ll still use it.”
Erik reached same conclusion I did about developer experience. #DX is important, but does not matter as much as API providers want to believe.
@jeremiahlee I'm really torn on this one. Of course, the only APIs that matter are useful APIs. If your underlying service doesn't provide value, your DX doesn't matter.
*However*, I have seen far too many times that companies know they have a valuable service so they underinvest in DX. Yes, developers still use the service...but they actively hate it. It slows them down. It's hard.
What developers LOVE is a service that gets both right.
@danciruli Sure, I agree.
My point is DX is not meaningful in the vast majority of enterprise vendor selections. It’s a “nice to have” because CTOs don’t make many vendor choices / engineering happiness is less important than the perceived business benefit of the purchase.
Salesforce? Zoura? Most Oracle products? Absolutely awful DX but it doesn’t matter. They still get purchased for $$$/year.
@jeremiahlee @danciruli This works for dominant players leveraging their position. Another aspect here is operational excellence. Once the API consumer completes an integration, they may never look at the code again. But if that API becomes unreliable, they’ll start shopping. Better DX can help win, particularly when the developer is frustrated by alternatives.
@kevinswiber @danciruli Can you share an example of 2 equally-capable API providers where one was more commercially successful because it had a better DX?
I can’t think of one. All the comparisons I could make were more differentiated by capability, price, or *–ilities.
@jeremiahlee @danciruli You’d have to find the right spot on the timeline, but… Stripe vs Authorize.NET. Twilio vs every other SMS gateway at the time. These are two categories that were integration-led. It’s never _just_ DX, though, for sure.
@kevinswiber @danciruli As a former Stripe, I agree Stripe's DX helps it win sometimes, but I think DX is insufficiently advantageous even for it. Stripe today loses to competitors with worse DX often on cost, response time, US-based, lack of merchant-of-record capability.
PayPal has worse DX, but 2x Stripe's marketshare.
I think Stripe's initial primary benefit over Authorize.net was more not having to do a months-long process of establishing 3 vendor relationships than its DX.
@jeremiahlee @danciruli Technically capable, yes, but harder to use APIs. They required partnerships, legal agreements. Self-service ends up being a major DX feature that wins against competitors, but it has to come at the right moment in time. It can be an industry disruptor.
@jeremiahlee @danciruli I know you're former Stripe! I really wanted your take on this. I work with them from time to time as well as with some of their competitors, many of whom see Stripe's DX as their competitive advantage.
@kevinswiber @danciruli Twilio is an interesting one. It was the company that introduced me to telephony-via-API. Did it have equally technically capable competitors back then?