Dev Tools Honeytrap
Dev Tools are the hardest business on earth. After building a few, I’m doing some soul searching on why we choose to build it, and why good developers often fail at it.
It’s said that movie people are really good at making movies about making movies. (Once upon a time in Hollywood, The Studio, The Offer). This is because they have the three things in common for a great idea to happen:
- You like it: Movie people like the movie business
- You’re good at it: Movie people are good at making movies
- The world needs it: World is always in dire need of good entertainment
At least 1, and 2 are applicable to dev tools. Devs like making tools / programming. Devs are good at it. However, they tend to extrapolate the usefulness of what they’re building beyond the n=1.
Being a dev is extremely liberating. Not only do you get to wield the tool (computer language) to build things, you get to build things that build things. I’ve seen people quit jobs because they didn’t like the way CI/CD was maintained - so, it’s an understatement to say that (good) devs are very opinionated in their opinions of what the “right” way of doing things are.
Inertia also dictates that they are not willing to change their minds often.
That unfortunately results in two side effects.
- There’s a proliferation of dev tooling, often subsidised by a company, or the sheer enthusiasm of a dev.
- There’s n number of ways to do the same thing - often resulting in narcissism of small differences.
Just look at Infrastructure as Code. Each cloud provider has their own flavour (my sincere condolences if you deal with Cloudformation), Terraform, Pulumi, and if you want to do the least amount of work (like me) there’s Fly.io toml.
Same can be said about background processing frameworks (Trigger, Inngest, Restate), Postgres based managed databases (Supabase, Neon, Crunchy Data) and AI agent frameworks.
Having built things in more than one of those aforementioned categories, I can definitely say that most customer and investor conversations revolve around:
- The other framework can’t do X in Y situation.
- Developers don’t like to do Z in their systems.
In other words, narcissism of small differences and law of small numbers.
This is not necessarily bad. I’m typically in favor of anything that converts VC dollars into dev salaries. But it just means that you can’t get rich by building dev tools. There are too many people building on small differences.
Individual devs don’t like to pay $10 a month because they can “do it themselves for cheaper”, and have fun doing it. Plus, you can’t scale that business unless you have an idea that helps you get a lot of inbound. To get a lot of inbound, you need to have a 10x better experience for the dev, or a 10x better performance for the price - which is incredibly hard to do [¹].
Obviously, all companies eventually try to get rich by going “enterprise”. But in enterprise sales, you’re not competing on the best product. You’re competing on what the sales guy says, whether they were referred by the CTO’s mate, whether the CEO heard them on their “AI podcast” or whether an overpaid consultant recommended them.
Secondarily to this is the rise in the whole dev influencer culture that promotes products, and the “developer relations” class. But that’s a story for another day.
I offer no solutions. Just my observations. I’ll probably build more dev tools, probably to my own detriment.
[¹] In practice, the largest free-tier always wins.