Developer tools are different than tools for any other profession, and that has some big implications for trying to build a business selling tools to developers:

1. Build vs. buy is a huge hurdle

Whenever we at Stellate meet an organization that needs our GraphQL edge caching, their developers inevitably ask, “Why shouldn’t we just build this?”

That’s a really good question. Truthfully, they could! We build our tools the same way that they build their software, so there’s technically nothing stopping them from building their own solution.¹

2. There will be free, open-source copies

Individual developers have a strong personal incentive to open source solutions to common problems: if one of their inventions becomes popular it can really accelerate their career. (that’s what my career is based on!)

So, if you ship an interesting solution to an important problem, it will almost certainly be copied in the open source world—not out of malice, but because individual developers are incentivized to do so.²

3. It has to be 10x better

Vendor onboarding into medium to large organizations is a nightmare. That combined with the two points above means that if your solution isn’t 10x better, developers will either use the free, open source version or build it themselves—even if that means a slightly worse solution—because the pain of vendor onboarding for a slightly better solution isn’t worth it.

However, “10x better” doesn’t necessarily mean you have to spend years building the highest-quality version of a solution. It can also be 10x better because you, for example, understand the problem 10x better.

But it has to be 10x better in some way that matters in the market.

4. Everything changes all the time

Finally, we are an ecosystem of inventors that can share new ideas with everybody else in a second. Thus unsurprisingly, new frameworks, libraries, and packages are invented that change the way we work all the time (usually for the better!).

In order to sustain a business selling to developers, you need to invest serious resources into just “keeping up with the times,” supporting the latest JavaScript framework du jour that has reinvented how to build components yet again.

So, it’s not enough to build something that’s 10x better. You have to build something that’s 10x better, and then keep reinventing your your solution to keep being 10x better in a constantly changing ecosystem.

The former is really hard.

The latter? Almost impossible.

This essay was prompted by a recent Twitter conversation with Gergely Orosz.

1. The argument for Buy over Build in enterprise sales conversations almost always boils down to “We have spent years building the most advanced version of this that covers your unique use case perfectly” combined with “Our team has unique experience, expertise, and learnings that would be time consuming for you to acquire.” ↩

2. A big blindspot of individual developers that don’t work at one is “the enterprise,” which I think is a part of the reason why we see so many dev tools startups target “the enterprise”: individual developers don’t have good visibility into what it takes to solve a problem at an enterprise. ↩