Every tool earns its place.

I like experimenting with new technologies. Trying a different runtime, framework or library helps me understand what's out there and question the choices I've already made. But experimentation doesn't have to lead to adoption.

I've explored Bun and Deno without finding a compelling reason to move away from Node. SvelteKit caught my attention too, but switching from React would have meant giving up an ecosystem my teams and I already knew well. Interesting alternatives, just not better answers to the problems I was solving.

That distinction mattered when I had to choose a CMS for a client project running on Cloudflare Workers. My initial preference was Payload: TypeScript-first, self-hosted, developer-friendly. It was exactly the kind of tool I wanted to work with.

But the decision wasn't just about the developer experience. Using Payload in that architecture would have introduced a separate PostgreSQL database, another service to maintain and another responsibility for the client. Sanity offered a simpler operational setup, and its editing experience worked well for the client's team.

And the evaluation doesn't stop once a tool is adopted. I initially used Zustand for server data because it was familiar. As the application evolved, React Query handled fetching, caching and invalidation more effectively. I moved server state there and kept Zustand for what it did well.

At Quely, I proposed migrating from GraphQL to tRPC. After evaluating the effort against the expected benefits, we decided against it. The migration cost more than it would have delivered. My colleague's argument was better, and I changed my mind.

TypeScript is perhaps the closest thing I have to a constant. Strong contracts across the API, client and data layer have repeatedly made changes easier to reason about. But the broader lesson isn't about any particular technology.