DX Is Not a Luxury. It Is the Reason You Ship.

There is a moment every engineer knows. You are sitting there, working on your product, and a really good idea hits you. Users would love this. It would actually be useful. Then, two seconds later, your brain starts walking through the implementation and you hit the wall. “Oh god, the amount of tech debt I have to untangle to make this work, the new infra I have to spin up, the framework’s caching layer I am about to fight for three days…” and you just close the mental tab. The idea dies right there, before a single character of code gets written.

That is a DX problem. And it is the single biggest reason most products do not get the features they should.

The Idea Funnel Is Real

I think a lot about how many of my own ideas have died in that funnel. Not because they were bad ideas. Not because they were not worth building. Because the path from “this would be cool” to “this is shipped” had too many landmines on it. Tech debt. Infra setup. Framework gotchas. Build pipeline weirdness. Each landmine subtracts a percentage from “yeah let me just do it.” Stack five of them and the answer is always no.

The flip side is the thing nobody talks about enough. When the tools are good, when the path is clean, you do not just keep up. You actually start welcoming scope creep. You see a feature, you see how easy it is, and you say sure, why not, throw it in. The thing you would have killed in your head three weeks ago becomes a Tuesday afternoon. That is what good DX buys you. It is not “developer happiness.” It is shipped features that would otherwise not exist.

TanStack Start Is the First Time I Have Felt This in Years

I have been building my recent stuff in TanStack Start. I want to talk about why, because it actually matches the point of this post.

I was building a webapp. I thought, you know what would be nice, a simple blog on the same domain. The old me would have immediately gone “okay, spin up a separate static site, figure out the subdomain, set up another deploy pipeline, link the styles somehow, nah I do not need a blog, who is even going to read it.” Idea dead.

Instead, it was basically one prompt. Drop a route, write the posts in markdown, ship. The blog you are reading right now is in the same repo as the rest of my stuff. There is no second deploy. There is no networking nonsense. The whole thing took an afternoon and I did not have to compromise on a single thing. That moment, the moment I realized the blog was just going to exist with no fight, felt incredible.

That is DX doing its job. The idea survived the funnel.

Explicit Magic vs. Implicit Magic

Here is the part where I have to talk about Next.js, because I cannot have this conversation without it.

Next.js had me for a long time. The DX felt good when you stayed on the rails. The minute you wanted to do something even slightly off-spec, the magic turned on you. cookies().set() that type-checks fine and then explodes at runtime. Caching that is on by default and silently changes the behavior of your app depending on which file you put a function in. The whole “is this a server component, a client component, or some hybrid that re-renders in a way I cannot predict” mental tax. The framework knows things about your code that you do not, and when it disagrees with you, it wins.

That is implicit magic. It is wonderful for the demo. It is a footgun the moment you deviate ten degrees from the happy path.

TanStack Start is the opposite. It is also magical, in the sense that the type-safe routing and the loaders and the streaming SSR all just work. But it is explicit. The route tree is generated and you can look at it. The loaders return typed data and you can see the types. When you want to know what the framework is doing, you can find out, in your own code, in a file you can read. There is no hidden runtime that decides things on your behalf. That is the whole difference. Implicit magic is a trap. Explicit magic is just magic.

The Performance Stuff Is Real Too

Quick aside, because it deserves a mention. The thing actually performs. There are real numbers floating around showing it pulling significantly more throughput than Next.js at the same load, with much lower latency. I do not need to litigate the benchmark, but I have felt it in dev too. Vite-based dev server, fast HMR, fast cold starts, deploys to whatever cloud I want without being held hostage by Vercel’s caching behavior. Cloudflare Workers. Whatever. It just goes.

Does it have RSC? Not yet. That is the tradeoff. I have not personally missed it. If you are doing the kind of app that needs RSC today, fine, stay on Next. For everything else, ask yourself if you actually need it or if you have just been told you need it.

The Real Argument

The point is not really TanStack Start. TanStack Start is just the example I happen to be living in right now. The point is that DX is not vanity. DX is not “developers want their tools to be cute.” DX is the difference between an idea that becomes a feature and an idea that dies in your head on a Tuesday afternoon.

When you make developers’ lives easier, they relax. When they relax, they think bigger. They start saying “oh, that is easy, let me just add it” instead of “oh god, not this again.” Your product gets more features. Your users get more value. Your roadmap stops being a list of things you compromised on.

Pick tools that get out of your way. Pick frameworks that are explicit about what they do. The cool ideas are already in your head. The only question is whether your stack lets them out.