We developers have a unique ability to create things with code, which has been recently accelerated with the proliferation of all sorts of agents. This is great, building solutions with software has never been so accessible, but this ability often leads to a hesitance towards paying for tools that would save them time, unless everyone is talking about those tools, in which case their system just got hacked.

This reluctance to pay for productivity tools despite the clear time-saving benefits is a classic example of what economists call the make-or-buy decision. In our case, developers often suffer from what I'd call "builder's bias" - the assumption that because we can build something, we should. This is closely related to the not-invented-here syndrome, where teams reject external solutions simply because they didn't create them internally.

I see everything as an investment these days, where my goal is to have more time and not less. If there's something that's making me waste time, even if I could build it myself, I prefer to pay someone for the work that they've done. For instance, this blog used to be statically generated and deployed to some infrastructure from a CI pipeline, but it sometimes broke, and did not have a solution that would allow me to capture my thoughts and share them from anywhere. It turns out Ghost has been doing that for ages, they align with my values, and for a tiny subscription, I get a lot of value, and they get to profit too. Deal.

This attitude is our day-to-day reality with Tuist, especially in a very opinionated ecosystem of tools where there's sometimes a distorted version of reality (tools are not as bad as they appear), and a high hope that Apple will fix things sooner or later, so anything that's not an Apple solution is not worth investing money into. This creates what behavioral economists call status quo bias - the tendency to stick with current solutions even when better alternatives exist. Unless the pain is too strong, in which case you have no choice. You can't just go to leadership and say, listen, I understand you want things to move fast, but tooling sucks. Or well, I wouldn't say it sucks because I've always thought it doesn't, but that React Native thing that you mention, that's what really sucks.

It's gotten to the point where I start to ignore that attitude and let them come across the truth by themselves. This aligns with what psychologists call the curse of knowledge - once you know something works better, it's hard to understand why others can't see it. I can talk for ages about how painful things are at a certain scale, but they'll only notice it when they experience it themselves. And those that have started to walk a path of enlightenment, where things are just faster or work more reliably, I'll hold their hands and help them.

The funny thing is that people think we are trying to take them away from the path that has been dictated. And not only that, but we dare to ask for a service, as if our ultimate goal was to profit from them without giving them anything in return. As if they were not giving engineering hours to their employers expecting a salary back. This resistance to paying for developer tools while expecting to be paid for development work is a fascinating cognitive dissonance that's prevalent in our industry.

But this is how things are, and we can't change that except by sharing our vision and letting people decide their journey. We introduced Mise, and people looked at us with hesitation, and now we've got many people who appreciate the tool and have even expanded it to their entire organization. We decided that mapping Swift packages to Xcode targets was a path for optimization and better developer experience, and many organizations find relief from seeing random package resolutions happening at any time, rendering the project unusable. Is this the path I would like to take? Not really, but when tools are closed-source and non-extensible, this is the only path. It turns out companies appreciate it because their pain is suddenly gone. Surprise, surprise.

The truth is, change in developer tooling often follows the same pattern as technology adoption curves. There are always early adopters who see the value immediately, followed by the pragmatic majority who wait until the benefits are proven and widely recognized. Our job isn't to convince everyone at once but to serve those who are ready to move forward and let the results speak for themselves.

At the end of the day, time is the only resource we can't create more of. Whether we spend it building solutions that already exist or investing in tools that multiply our effectiveness is a choice that defines not just our productivity, but our entire approach to creating value in this world.