A little over 18 months ago, I launched a developer tool called Bearer.sh.

Recognizing the lack of tooling for API integration to be a major pain among developers, I wanted to solve this problem through a developer tool. But, to be honest, I didn’t entirely realize what building such a tool meant.

A developer knows what to build

What is amazing when starting a developer tool, is that being a developer yourself, it’s very easy to reflect on your product; it’s thrilling. However, it’s both a blessing and a curse, as you need to constantly challenge your own perceptions and experiences, to make sure your points of view always reflect those of your audience.

We started with what I call “the positive arrogance of founders”—knowing what others need. This is illustrated well with the famous Steve Jobs quote:

"...customers don’t know what they want until we’ve shown them."

While this may be true, it does not preclude you from conducting in-depth discussions, asking questions, and eventually summarizing the different pains, personas, and opportunities of your clients. All these enable you to craft well-fitting solutions for your customers; these will become your products.

To this end, I strongly suggest doing a customer discovery*; we eventually did one, thanks to our great advisors!

What is a developer tool?

You have probably heard the terms low-code and no-code a lot lately, but don't mistake them for developer tools!

No-code solutions are for building software without coding. Some of the best examples are Zapier, Airtable, and Bubble. Most of the time, they are targeted, by design, at businesspeople that don’t have the technical skill or time for coding, setting them free from those barriers.

A low-code solution enables the building of software by coding using a simplified tool, for a fraction of the time and resources a traditional approach would take. These solutions are all about simplified code and they mostly appeal to IT professionals, releasing them from the need for engineering resources. Some examples are Appian, Salesforce App Cloud, etc.

Developer tools are about helping people build software by providing better application development ecosystems. They focus on core business problems instead of reinventing the wheel. Whether Algolia for search, Sqreen for security, or Bearer for API integration, each tool is all about helping engineering teams.

As “software is eating the world", given the increasing shortage of engineers, at every level of the pyramid, the industry is pushing for more abstraction.

And as you can imagine, both low-code and no-code solutions rely on developer tools :)

Simplicity vs Complexity

To build a great product, user experience is paramount; it especially has to be as frictionless as possible, even more so in the early days of use.

When we started, I thought it was about building something complex; we got as far as building a framework. Our intentions were great, but I forgot something very important, most people don't have time to learn something new, at least not right away.

Compared to SaaS or no-code solutions, developer tools, in particular, need to be versatile. Indeed, developers have different use contexts and cases, so the tools have to be appropriately adaptable, despite lack of prior knowledge of each individual set of requirements.

What we've seen is that most developer tools tend to add complexity over time, requiring increasing levels of user input. Developer tools are built around complexity layers. The first layer has to be attractive and easy enough to encourage a user to invest a little of their time and energy. Then, with further use, additional layers are added, handling more complex use cases.

This simplicity vs complexity is the biggest challenge when working on developer tools.

In the end, perfecting this mix, of simplicity and complexity, creates the secret sauce that makes a developer tool successful. It's also the most exciting challenge for me 💪

I'm happy to answer any question you might have below or on Twitter