Why do developers choose not to use your product?

Introduction 

Adoption of 3rd party tools is a big step for developers. Apart from functionality, our decision is based on many other factors, like estimating how long it will take to integrate or how easy it will be to implement the solution. 

Let's explore why developers might not choose your product. test

Initial Expectations

In 2018, I was given the opportunity to implement a 3rd party REST API Payment gateway into our company web application. I was eager to start because I was given absolute freedom in choosing the provider. Back then the process of choosing a 3rd party could be done only by googling. I found about 30 solutions that promised to solve my problem. Free trials, freemium, or paid subscriptions were the first things I was looking at. Price and user-friendly design were the main deciding factors, though. Later, I realized my mistake. 

Integration Complexity and Documentation Issues

I found a good enough solution. Signed up, logged in, and started the integration process. I was provided with a “.doc” document that served as a guide (documentation). Step by step, I followed the instructions. Even though the instructions were sometimes unclear, I managed to get everything done with the help of my senior colleagues. I was excited to see how the output of many hours of struggle will look. I pressed F5, and there it was, a beautiful payment gateway… But it didn't work. The documentation in the form of a Word document was 9 months old, so I thought maybe some changes in the product were not reflected there. This misalignment led to numerous failed API calls and invalid data parsing, further impeding our integration efforts. What was initially scoped as a couple hours of work took me the whole day.

Poor Developer Support

Let's begin with troubleshooting. Googling, YouTube guides, Reddit. Nothing solved my problem, but I was used to that. I called the support line, spent some time in the queue, and was connected to a “very eager to help” person. He had just started working there, and with the help of his colleagues, he managed to give me the help I needed. Finally, it worked the way it should have. For some time anyway. 

Limited Functionality

After a couple of months, our customer wanted to derive more data. Back to the support line, asking them to provide them in responses. The rigidity of their system did not allow that for us. It would be too expensive. We had no choice but to start again to look for another solution, which we eventually found. It was more expensive but worked relatively better. Although the friction points during integration were almost the same. We stayed with that provider for a year until we bumped into one of their competitors, who had a totally different approach to their API product. 

Developer Experience

Finally, I found it! Their API ecosystem went through rapid change in a span of a couple of years. Comprehensive documentation with interactive endpoints and request/response examples. There were even SDKs (Software Development Kit) in three languages. Which meant that I could use my favorite language, JavaScript, and on top of that, the integration was done in minutes, not hours or days. It just took a couple lines of code. Guides and tools were up-to-date. The amount of time we saved during implementation and later with maintenance was game-changing for us. Finally, somebody started to take care of developers' time and joy from work. Same as UX is making users happy. DevEx is making developers happy. 

“We don’t know what we don’t know.” This saying goes a long way regarding Developer Experience. The biggest improvement is to realize that and start acting towards discovering friction points and bottlenecks. 

How to do that is uncovered in this article. 

The common issues companies are facing are usually these:

1. Outdated Technologies and Technical Debt
   Legacy technologies that have not been upgraded lead to a growing backlog of technical debt, making adaptation difficult.
2. Outdated Product Usability
   Essential product elements, like APIs, SDKs, and documentation, lag behind current standards, reducing product value.
3. Repetitive Tasks Reducing Efficiency
   Many tasks are still manual, which increases workload and leads to delays.
4. Manual Processes
   Lack of automation in workflows introduces errors, compounding inefficiencies and requiring rework.
5. Technical Debt Due to Poor Project Planning
   Without structured project kickoffs, technical debt builds up, making projects harder to maintain over time.
6. Inadequate Task Definitions
   Poorly defined tasks lead to confusion and incomplete work, slowing down the workflow.
7. Insufficient System Design and Technical Analysis
   Weak technical analysis and outdated system design practices prevent optimal implementation and scaling.

Conclusion

The API ecosystem is going through a full-scale shift. Providers of 3rd party services are differentiating themselves based on the quality of documentation since nowadays that's the main decision point for developers, who are tasked with the integration of APIs. To provide us with everything we need in one place all the time so we can do what we were meant to do. Develop the best possible solutions. 

The adoption of new technologies is mandatory for those who want to have competitive products. I have chosen a cheap and obsolete provider who was struggling due to its own rigid solution. For individuals, small teams, and especially corporates, it is essential to adopt solutions that offer tools and workflows that help us get rid of repetitive tasks and improve our output. That way we will succeed in overcoming struggles of inefficiency not only while developing but also maintaining and improving our projects.