Developer-first
Make your product as easy as possible to integrate
While I was doing my Ph.D. my research group was working on an obscure technology; I remember only a few people all over the world were into this technology and it was quite hard and difficult to use; it required special hardware, and the tools and development libraries available were very rough. One day, we decided to develop some software using that technology; the software was quite straightforward, but it required to do a certain number of tasks on the Linux shell, to patch OpenSSL, and to do a few things at the same time on different shells, in a particular order. We worked very hard to make a readme with the instructions structured so that it was enough to copy and paste commands to have the code working, eventually.
Want to read this story later? Save it in Journal.
Writing the code was relatively easy, compared to writing the readme. We used a trial and error approach to get the set of instructions right and when we had a draft version we decided to test it in a clean environment. It was a spectacular failure. None worked the way it was supposed to. We learned that the trial and error approach left a dirty environment each time we had an error and we choose another path. We spent the next few days rewriting the readme with a slightly different approach: every time we encountered an error, we cleaned the whole system and started from scratch. This ensured an almost perfect readme but took a considerable amount of time and effort (compiling our patched version of OpenSSL took a long time and it was one of the first steps, so we recompiled it a number of times in those days)
As a developer and as a user I hate when I find tools that deliver great value, but they are hard to integrate or difficult to use.
Building a great tool that is difficult to use is not making it right for your users. It means that you didn’t spend some extra time to optimise the user experience, to smooth the rough points, to make operating your tool quicker and easier. You are asking your users to fill the gaps you left behind, like your time was more valuable than theirs.
I understand that in our society velocity of execution is a key point of success, but I still think that your main asset should be your users and that users’ satisfaction and happiness is the most valuable thing to seek. I also know that thinking developer-first takes a lot of time. One must try over and over what he wrote, keep testing to ensure the instructions still work, verify if all the little corner case still applies. Of course, it is possible to write automated tests for this, but often this type of integration is not easily tested. But the time spent pays off largely; developers will feel that you put a lot of love into your product; every rough point removed is a new client that will use your code.
Tools and frameworks meant to be used by developers usually must be integrated with some type of code. When integration is not easy it is difficult to integrate, developers get frustrated, lose momentum and fail to deliver a great experience to their customers. This is why at Saasform we always design each new feature thinking about how it will be used and integrated and we spend some time trying to smooth the roughest points and making the overall experience better.
We did this since the beginning, making a developer-first product; we made sure that testing our demo is just one single standard command (docker-compose up), that integrating it is a matter of minutes (less than 30 lines of code, ready to be copied from our examples), that documentation grows together with the features. We also applied the same approach to the development of Saasform itself; being an open-source product we always made sure that it was straightforward to contribute to the project with some issue report or some PR; we also try to be as available as possible in our Discord server, so that potential user can have a chat with us and can find support if they are blocked.
We are proud of our work so far, and the ease of integration that our firsts users reported made us even prouder, even if this meant to be slower in the release of each new feature.
📝 Save this story in Journal.
