Dev Tools Honeytrap: Why We Can't Stop Building Tools Nobody Buys(substack.com)
substack.com
Dev Tools Honeytrap: Why We Can't Stop Building Tools Nobody Buys
https://substack.com/home/post/p-161145826
32 comments
Ask yourself this: how many dev tools have you or people you worked with actually paid for over the years? I know a couple guys that paid for IntelliJ, back before VS Code got popular.
A tremendous amount I have paid for in the past or still pay for today. Github, Github Copilot, Rider, Reviewable, Lucidcharts, Heroku, Render, CircleCI, Browserstack, Datadog, Launchdarkly, Postman, Sentry, Amplitude, Imgix, Zeplin, Cloudinary, ngrok, dbt, ... the list goes on and on.
Another option to Cloudinary is reimage.dev, which I’m the founder of. Currently have a lifetime deal at lifetime.reimage.dev
https://pinggy.io is a more affordable option than n grok.
Cloudflare tunnels are free.
That part rings true, if slightly hyperbolic.
It’s like opening a restaurant that only serves other chefs. Not easy!
It’s like opening a restaurant that only serves other chefs. Not easy!
Never sell things your customers can build themselves.
This reminds me of Dwight from the office in the episode where he doesn’t tip the delivery driver and says: I never tip for anything I can do myself. I can deliver this if I want to.
He also notes that he does tip the guy who pulverizes his kidney stones.
One nice thing about SaaS is that the “aaS” part is just as important as the “S”.
So with that logic, google shouldn’t ever buy anything from anyone…
Clearly false.
Clearly false.
"Never sell something your customers could build themselves" and "never buy anything you could build yourself" are not the same thing.
? Not really. You can reword it and say that just because google can build it means you shouldn’t try to sell it to them. And google can build pretty much anything at this point if they wanted to.
Google’s budget for software and services I’m sure is in the hundreds of millions if not billions of dollars. So again, obviously false.
Google’s budget for software and services I’m sure is in the hundreds of millions if not billions of dollars. So again, obviously false.
They make their own NICs, GPUs, SSDs and CPUs so you aren't wrong but you also miss the point entirely. I made a statement about customers, not Google. You should have an LLM correct your logic.
Yea, I don't buy that line at all.
AWS is "just dev tools" and it's one of the most profitable businesses in the world.
AWS is "just dev tools" and it's one of the most profitable businesses in the world.
I would categorize that as infrastructure, not a dev tool. Terraform and terraform cloud on the other hand…
AWS most certainly is not just dev tools. AWS is a physical product (servers, drives, cables, networks, switches, cooling, monitoring, redundancy, security...) that you merely interact with remotely. You can't recreate AWS just by writing code.
Exactly. Devtools has had a rather generous number of unicorns in the last 15 years as a tech category. There are many others that can't say the same.
https://www.failory.com/startups/developer-tools-unicorns (unrelated, but thatgamecompany as dev tools? that's a first)
https://www.failory.com/startups/developer-tools-unicorns (unrelated, but thatgamecompany as dev tools? that's a first)
ilrwbwrkhv(1)
A useful analogy is natural selection. The two features, mutation and selection pressure, are present in software. From the inside, the mutations seem rational, controlled, planned, but from the outside they are random. The selection pressure is itself complex, but success can be measured by "number of copies in the world", which is ultimately driven by social success and luck as much as anything. Software also has a (unique?) "win more" mechanic where a popular tool tends to get more popular. The pressure happens recursively at different scales, and sometimes very large branches tend to die off because of big topics like "lack memory safety" or "supply chain attacks".
Interestingly, language diversity seems driven by school curricula, which becomes comfort which becomes hiring practice, the change driven by academic boredom with a given language.
Interestingly, language diversity seems driven by school curricula, which becomes comfort which becomes hiring practice, the change driven by academic boredom with a given language.
> Software also has a (unique?) "win more" mechanic where a popular tool tends to get more popular.
I don't think this is unique at all to software tools and is a general principle.
Rosen had a paper in 1981 talking about "The Economics of Superstars" [0]. I don't claim to have deep knowledge but the idea is that if an individual has limited resources (money, attention, etc.) and wants to ensure the maximum gain from their expenditure, then allocating resources to the superstar is a safer bet. This means that superstars get proportionally larger resources than what they might be valued at.
For example, if 120 consumer has $5 to spend on a song ($600 total), each consumer on an individual level might allocate their $5 on the known good superstar song. The superstar song might only be 2x better than the next best thing, so one might expect that the superstar song might, at most, get $400 of the total, but because of the superstar effect, the superstar song gets all $600.
I just watched an interview with Torvalds about Git. There were a lot of reasons why Git was so quickly adopted, not the least of which was functionality and how it leveraged a changing technology landscape, but a major factor was almost surely Torvalds celebrity status and blessing.
[0] https://pdodds.w3.uvm.edu/files/papers/others/1981/rosen1981...
I don't think this is unique at all to software tools and is a general principle.
Rosen had a paper in 1981 talking about "The Economics of Superstars" [0]. I don't claim to have deep knowledge but the idea is that if an individual has limited resources (money, attention, etc.) and wants to ensure the maximum gain from their expenditure, then allocating resources to the superstar is a safer bet. This means that superstars get proportionally larger resources than what they might be valued at.
For example, if 120 consumer has $5 to spend on a song ($600 total), each consumer on an individual level might allocate their $5 on the known good superstar song. The superstar song might only be 2x better than the next best thing, so one might expect that the superstar song might, at most, get $400 of the total, but because of the superstar effect, the superstar song gets all $600.
I just watched an interview with Torvalds about Git. There were a lot of reasons why Git was so quickly adopted, not the least of which was functionality and how it leveraged a changing technology landscape, but a major factor was almost surely Torvalds celebrity status and blessing.
[0] https://pdodds.w3.uvm.edu/files/papers/others/1981/rosen1981...
There is some truth here but I find this take to be overly cynical.
I built Cronitor in 2014 not because I liked making dev tools or was even particularly good at it, but because in my day job at Zillow my team had a lot of problems with silently-failing cron jobs. I had friends who were developers at other companies so I had the ability to validate this problem with other people in my network.
With any business it’s very important to solve a real problem. Steve Jobs called this approach starting with the customer and working backwards to the technology. So, you build what you know you need, with the belief that you are not as different from your peers as you might think. In contrast we have a lot of people starting with LLM technology and trying to work backwards to customers. I think that’s the real honeytrap.
I built Cronitor in 2014 not because I liked making dev tools or was even particularly good at it, but because in my day job at Zillow my team had a lot of problems with silently-failing cron jobs. I had friends who were developers at other companies so I had the ability to validate this problem with other people in my network.
With any business it’s very important to solve a real problem. Steve Jobs called this approach starting with the customer and working backwards to the technology. So, you build what you know you need, with the belief that you are not as different from your peers as you might think. In contrast we have a lot of people starting with LLM technology and trying to work backwards to customers. I think that’s the real honeytrap.
This is my pet theory, but I suspect that dev tools also get in the way of opportunities for promotion for engineers. Sure, buying an A/B testing tool will solve the problem of needing that tool, but it will add nothing to the resume of half a dozen people trying to get a promotion or an impressive project on their resume that they can then shop around at other firms. Dev tools go against resume-driven-development at larger firms, so in some sense they're doomed to fail. They make a lot of sense at earlier stages of companies where everybody's incentives are aligned around making the company win, and that might be the only opportunity the dev tool has to capture a logo and grow with them upmarket.
I fully believe this to be true as well. Aside from possibly the endless red tape and bureaucratic hoop jumping of making a purchasing decision. "Promotion driven development" is a scourge. Endless waste of time and resources for everyone, including the company, but somehow management and leadership doesn't care. Make it look like you did lots of work instead of the right work and somehow that's what matters? I know growing up I was always told work smarter not harder, but apparently harder not smarter is what management actually wants. Personally I think they're too brain-dead to know the difference and just think hurr-durr more code mean better. It's been a pretty universal experience/observation for me.
The developers and managers alike are rationally responding to the incentives of the current market. If developing a tool no one wants will get you promoted or a chance at a higher paying job elsewhere and your manager gets credit for overseeing a hard working productive team, then why would you expect any different outcome?
Oh I fully understand the incentives from the bottom up. I'm just calling a spade a spade, even if we know the why.
[deleted]
If you want your dev tool to sell, just sell a cloud service along with it.
What I've found motivates this phenomenon is the fact that many companies have a strong aversion to adding any technology of any kind to their tech stack, regardless of how simple. Better to pay an external provider to run it for you, the thinking goes.
So naturally there is a gigantic market for cloud hosting of all kinds of software, even software that is very rudimentary to self-host.
What I've found motivates this phenomenon is the fact that many companies have a strong aversion to adding any technology of any kind to their tech stack, regardless of how simple. Better to pay an external provider to run it for you, the thinking goes.
So naturally there is a gigantic market for cloud hosting of all kinds of software, even software that is very rudimentary to self-host.
This is true to an extent. A recent example that I witnessed unfold (we were a customer) is Earthly. They had a great core product that they offered a hosted version for, but most people just ended up hosting it themselves, and the idea never took off. Towards the end, they even tried to jump on the "BYOC" hype-train where they literally ran the product in your own cloud (B2B style) and couldn't make things work.
Of course, there are other factors to consider, but it's just a tiny anecdote that confirms what the author said: Companies don't like to pay for dev tools.
Of course, there are other factors to consider, but it's just a tiny anecdote that confirms what the author said: Companies don't like to pay for dev tools.
But Earthly is still in business, which sort of proves my point. Something which would never make money on its own (Earthly) can make money with just some cloud-hosted value add.
They've certainly pivoted their product in various ways, as any business does - my point was not to suggest that cloud devtools get free money and don't have to worry about the natural challenges of B2B product development. My point was just that, completely nonviable businesses can at least become viable by selling the cloud.
They've certainly pivoted their product in various ways, as any business does - my point was not to suggest that cloud devtools get free money and don't have to worry about the natural challenges of B2B product development. My point was just that, completely nonviable businesses can at least become viable by selling the cloud.
Don't most people say that about their niche of the tech industry? Healthtech. Online dating. Edtech. Game dev. You name it.