Building towards the non-obvious

There's something I like about building a business, and that's projecting ourselves ahead, thinking about what are today's truths that won't hold a few years from now, or what are new truths that might emerge, and thinking backwards to make sure that as we move forward, we get closer to those new realities. This is something we balance with working on the "obvious", the thing that keeps building a steady income, while the other prepares us to unlock a new market before anyone else.

Mitchell Hashimoto touched on this a few days ago with this post, where he framed it as reactive versus proactive instead of obvious versus non-obvious. A lot of the energy in our industry goes into the obvious, the next incremental step that everyone is talking about on the socials, sandboxes being a good example of it these days. Everyone finds their little corner there, and a business can absolutely sustain itself that way. CI and runners as a service is another one that comes to mind: a new service, a new YAML schema, different pricing models, some performance differences here and there. It's a comfortable place to be, and it's also a place where it's hard for something genuinely new to happen.

We've chosen to spend our energy elsewhere, and it's risky. You are building towards a reality that many might not have seen yet, but you are confident it might happen. When we started Tuist, we built towards teams needing optimizations without wanting to replace their build system. Turns out we were right. Those companies exist, and we built a market for ourselves, building the infrastructure to enable it. And we did not stop there. We have that infrastructure now, and we are seeing people become intolerant to validation through compilation or test execution being slow when agents have built a feature in a couple of minutes. That intolerance is going to keep growing. We are seeing it everywhere, even outside of the tech industry. Everyone is finding their way to productivity, so this will be a priority in many teams' roadmaps.

Now, taking that as a new reality, comes the part of what we need to get there. The first one, and it might sound obvious, is making Tuist, the platform that distributes the solution, accessible to anyone. A solution that can't be tested without contacting a sales team is not accessible. If there's no quick and straightforward path to try it, it's not accessible either. And if a marketing website is designed only for enterprises, you are missing out on those developers that might start using it with their personal projects, and then bring it to their employers. So we are doing a lot of work to change that, from designing an infrastructure model that allows us to offer a plan reasonably priced for anyone to try, to designing a marketing site at the level of Vercel or Supabase, so that people don't feel those optimizations are exclusive to large enterprises that can parse and tolerate a level of ugliness and enterprise facade.

From all of those pieces of accessibility, one that we believe can make a huge difference is bringing the primitives closer to the user without requiring project changes. Adopting our generation of Xcode projects to get access to the module cache is costly. Adopting Bazel is costly too. Less so with agents, but organizations are forking from the native toolchains just for the sake of using a platform's capabilities. This always felt wrong to me. I admire and respect Bazel and everything that it has enabled, but the whole having to migrate piece always irritated me. I'd love developers to tap into our cache and insights primitives without having to change anything in the way they work, and this is the part that got me obsessed about building Once.

Once is where all of this comes together for me: the bet on that intolerance growing, the obsession with accessibility, and the refusal to ask anyone to migrate before they can get any value. It might go nowhere. That's what building towards a reality you can only see the shape of feels like, and it's a part we've made peace with, as long as we get to do it the way we like to do things at Tuist, balancing open source technologies with a business that services some solutions upon that technology. If you don't try, you never know.