It's not about what, but how

You might not believe it, but I suffer from a lot of imposter syndrome when building Tuist. When I started it, I was very determined and convinced that the ideas I was playing with in my head could work. It was just me, Xcode, and a GitHub repository where I could push my code for anyone to check and use. Part of me thought, “We are just doing project generation, and there are a handful of other tools out there that do the same thing,” but the other part of me thought, “But there’s something unique in the way we are going to approach it, so why not?”

It takes a lot of determination to build something these days. The moment you share “what” you are building, you’ll face loads of comparisons with other tools that seemingly do the same. And they might be right in that they solve the same problem that we are aiming to solve, but the important question is really “how.” Tuist’s strength lies in how it helps organizations overcome challenges. What makes it unique is the right balance between the value that organizations can get from it compared to the investment that they have to make to introduce it. It’s so well-balanced that even small organizations can afford to have it very early in the lifecycle of their projects.

People ask me what I think about Bazel. I don’t know what they expect, but my answer is always: it’s amazing. And what about XcodeGen? It’s an amazing tool. But I respond to them with another question: “Do you think it’s the right tool for you?” And this is only a question they’ll be able to answer, not me. I can share the pros and cons of Tuist’s approach to solving problems, but ultimately it’s up to them, who know their environment better than me, to decide which tool fits them best.

And why am I talking about it? I recently started thinking about the state of the web and the lack of a standard language for building and sharing components that are weakly coupled to the JavaScript ecosystem, and the reaction of people reminded me of the reaction of people when I started building Tuist: “But isn’t there Svelte, React, Preact, Vue, and the many others that are already solving that problem?” And once again, the problem is the same, but the important point is really the “how.” The lack of a narrow waist in the ecosystem has led us to a fragmentation of solutions and tools in the JavaScript layer and a degradation in DX in other ecosystems that are not JavaScript. This is far from ideal, and the whole ecosystem would benefit from a different approach to how to solve the problem.

It’s terribly challenging to push through it. My personality helps a lot. I pushed hard with Tuist. I pushed hard at Shopify about the idea of having frameworks for apps, which indeed caused a lot of frustration in the end because my idea was only accepted when the CEO mandated it. I’m going to push hard with the idea of a web compiler. Will it work? I don’t know. But I won’t let anyone stop me from finding new solutions to problem spaces that have accumulated an absurd amount of complexity.