The developer tools market is worth $45 billion. That number keeps climbing. And I think a big chunk of it is waste.
Before you sharpen your pitchforks — I'm not anti-tooling. I love a good CLI. A well-configured linter sparks joy. But somewhere in the last few years, we crossed a line from "tools that help us ship" to "tools that help us feel productive while shipping nothing."
The Setup Spiral
You know the pattern. New project kicks off. Before a single feature gets built, someone spends three days configuring the monorepo. Then two more days on the CI pipeline. Then a day on pre-commit hooks. Then someone adds Storybook. Then someone else adds a design system. Then you need documentation for the design system. Then you need a tool to generate the documentation.
Week three. Zero features shipped. But the DX? Chef's kiss.
Meanwhile, your users are staring at the same broken checkout flow they reported two months ago.
The Conference-Driven Development Problem
Here's what's actually happening: developer experience has become a status symbol. Teams flex their toolchains the way people flex cars. "Oh, you're still using Webpack? We migrated to Turbopack. Our cold starts are 200ms faster." Cool. Your users don't care. They never cared. They want the button to work.
Conference talks amplify this. Every major dev conference in 2026 has at least five talks about "improving DX" for every one talk about improving the actual product. We've built an entire ecosystem of developers building tools for developers to build tools for developers. It's turtles all the way down.
When DX Actually Matters
I'm not saying DX is irrelevant. It matters enormously in specific contexts:
- Open source libraries — if your API is painful, nobody adopts it
- Platform teams — making internal developers productive is literally the job
- Onboarding — a new hire shipping on day one vs. day thirty is real business value
But for most product teams? DX is a means, not an end. The end is the user. Always has been.
The Real Cost Nobody Talks About
Here's the part that actually bothers me: DX obsession creates a weird form of technical debt. Not the usual kind — this is process debt. Every tool you add is a tool you maintain. Every abstraction layer is a layer someone has to understand. Every "developer quality of life" improvement is a config file that breaks during upgrades.
I've seen teams where the build system is more complex than the product. Where the testing infrastructure requires its own documentation site. Where onboarding takes a week not because the business domain is complex, but because the toolchain is.
That's not good DX. That's a Rube Goldberg machine wearing a developer advocacy t-shirt.
The Two-Question Test
Before adding any DX improvement, ask two questions:
Will this help us ship user-facing value faster? Not "feel more productive." Not "reduce theoretical tech debt." Actually ship. To users. Faster.
Is the maintenance cost worth the speed gain? A tool that saves 10 minutes per deploy but requires 2 hours of maintenance per month is a bad trade if you deploy twice a month.
If both answers aren't a clear yes, you don't need it. You want it. There's a difference.
The Uncomfortable Truth
The best developer experience is shipping something that matters and watching people use it. No amount of hot module replacement, AI-powered autocomplete, or sub-millisecond builds replaces that feeling.
Some of the best software I've seen was built with "bad" DX. Ugly build scripts. Manual deployments. No design system. But the teams knew their users cold, iterated fast on what mattered, and shipped relentlessly.
Some of the worst software I've seen had immaculate DX. Gorgeous dashboards. Automated everything. The developers loved working on it. The users hated using it. The company doesn't exist anymore.
Ship the Thing
Your toolchain is not your product. Your pipeline is not your product. Your developer portal with the custom theme is not your product.
The thing your users interact with? That's your product. Everything else is overhead. Sometimes necessary overhead. Often not.
Stop optimizing for the people who build the thing. Start optimizing for the people who use it.
Your DX is showing. Your UX should be louder.
Top comments (0)