It could drop 1,000 feet from the sky, get tossed into a blender, or take a hit from a rusty sledgehammer, and it would still work. The 2000s-era Nokia cell phone is well-known for its uncanny resilience. In a twist of fate, Nokia’s mobile division—which commanded over 40% of the global market in 2007—suffered a slow, undignified death in the decade that followed. Why? Nokia’s leadership failed to fully consider the needs of developers during a crucial turning point in technology. When more universal ecosystems like Android and iOS were shaping the future, Nokia stuck with its developer-unfriendly Symbian OS—digging its own grave. 

Today, we’re at another key turning point. New tools, including coding assistants and automated workflows, are enabling developers to achieve in days what used to take months. These new tools have not only freed up developers to focus on high-impact work—they’ve also empowered companies to transform their APIs into lucrative products. At this juncture, Nokia’s brutal and spectacular collapse becomes a teachable moment: now is the time to listen closely to developers. 

Smart companies know that their developers are best-suited to determine which tools are must-have versus nice-to-have. They also know that, given the right tools, their developers can unlock massive new revenue streams. Which begs the question: why not just let developers pick out their tools themselves?

Developers have more leverage over purchasing than ever before

As powerful new technologies transform the pace and scope of software development,  adaptation becomes a sink-or-swim imperative—and companies increasingly lean on their developers to navigate these choppy waters. According to an IDC survey, up to 79% of developers feel they have “either significant or complete influence over purchasing and procurement decisions”. So what we’re seeing is a shift in the roles of developers from behind-the-scenes specialists to strategic decision-makers.

Developers aren’t getting more involved in purchasing just to make the company’s IT infrastructure better—they’re involved because their expertise is making the company more money. That’s why today’s most successful companies forge their businesses around developer needs. 

From their inception, Twilio and Stripe have known that developers are the key to their success. They give their developers the desired tools to build highly-integratable APIs not because they’re nice-to-have, but because they form the foundation of their business strategy. That is—to use good APIs to abstract away the complexity of core business functions (in Stripe’s case, payments; in Twilio’s, communication). 

When your API is a product, developers are your customer

Succeeding in today’s environment means taking a by-developers, for-developers approach to technology procurement.  What does this mean in practice?  Developers decide what tools work best for them. And who do these developers have in mind when they make those decisions? Other developers. 

When developers take this approach, they advocate for tools that 1) improve the quality of API documentation, 2) make SDKs more intuitive, 3) offer sandbox environments for testing, among other things. The benefits for developer experience are twofold: on the one hand, developers get tools that streamline their work; on the other, they build products that are easier to adopt by other developers. 

If you are selling an API as a product, that means that other developers are going to evaluate your documentation, SDKs, sandbox servers, and all the other details of your DX. Now more than ever, companies need to equip their own developers with the tools to make a good impression. 

When developers are your customer, intuitive SDKs seal the deal

APIs sell when you provide well-documented SDKs written in the customer’s preferred language. And, again, let’s keep in mind that the customer is the developer. So what would developers prefer not to do? Waste countless hours grinding out how to work your APIs. Instead, your SDK should prevent developers from having to deal with deciphering API docs, JSON responses and guesswork, or whatever else. 

We’d already seen the writing on the wall before founding Sideko, when we both worked at Eigen Technologies. The team used to provide swagger docs—think of these as how-to instructions for an API—which customers had to comb over. This also meant that the customer had to implement each endpoint manually, which took forever. And when it came down to larger, enterprise customers with complex demands, it took even longer. 

Then, Eigen’s Solutions Team had a breakthrough. They built a command-line interface (CLI) that actually did the grunt work for the developer, rather than just showing them how to do it. This reduced integration time ten times over for big bank customers. It also enabled Eigen’s customers to actually make use of their API straight away—rather than wasting resources on deciphering it. 

Companies like Eigen, Twilio, and Stripe prove that prioritizing developer needs doesn’t just result in better IT infrastructure, it builds better products. Particularly when developers are assuming a more strategic, decision-making role, DX is becoming central to the value proposition. Meanwhile, Nokia fell from the very top of the global market into irrelevance in a matter of years—in part because they spectacularly fumbled DX. In short: don’t be like Nokia, because ignoring the needs of developers often means tanking the future of your business.