The new Tuist, from build toolchains to bare metal

Back when Tuist was purely a command-line interface, we could announce major changes in its direction with a new major version. We went all the way to major version 4, but then things shifted towards server-side infrastructure and technology, and we could no longer use the command line's major versioning to express important direction shifts. If you've been following for a while, you might have noticed that client-side project generation has become just one feature of a much larger platform, one that extends beyond the Apple ecosystem where Tuist was born. Tuist is becoming build infrastructure for productive engineering teams. We act as a virtual platform team: we plug into your build toolchains and optimize everything optimizable, from test runs down to the bare metal where your builds run.

If you've visited our website recently, you might have noticed that there has been an important change in our brand. This all started with this message from Asmit:

What followed is not something we could have imagined at the time. We knew Asmit was excellent at his craft, but pair that craft with the capabilities of coding agents and it started to feel like watching the completion of Gaudí's Sagrada Familia. It was awe after awe. At some point we started joking that Asmit was the Gaudí of pixels, and we meant it. He came up with the designs, translated them into HTML, added animations wherever they belonged, and gave Tuist a visual identity on par with the biggest names in developer tooling, and in line with the ambitious mission we hold as a company today. Navigating what he built feels a bit like wandering through one of Gaudí's spaces: you get pleasantly lost, and every time you look closer another tiny detail reveals itself, always in conversation with nature. If you've seen the show that aired when they finally finished the cathedral, that's the closest reference we have.

We deeply believe in the importance of how technology is presented, more so now that today's large language models push everything toward sameness. Design is why you pick a Tesla or an iPhone over anything else, and we want to match that level of attention to detail for our users.

As I mentioned earlier, we can't call this a major version of a piece of software, because Tuist is several surfaces now, so I settled on the boring "new Tuist". Maybe in a few years we'll have a new new Tuist. The point I want to get to is that there's a direction that's been implicit over these past months, one that Asmit has already put into the design (please click around and, while you're at it, land on one of our error pages to find the little easter egg he tucked in there), and it felt like my role as chief executive officer to put it into words. We owe everyone who's followed us since the beginning, and everyone finding Tuist for the first time, a bit of direction here.

Beyond one ecosystem: Xcode, Gradle, and Bazel

As we shifted from the command line to the server side, we stopped being an exclusive tool for the Apple ecosystem. We now support Xcode, Gradle, Bazel, and soon a build system of our own, Once. The product has grown well beyond Apple, but most people still think of us as an Apple tool. That's not a bad thing: the Apple community has been kind to us. They've watched us grow from a tiny project into something much bigger, and many want to support us on the journey, which is heartwarming to see. What we're working toward now is for people to also know us for the other ecosystems we serve. If anything has become clear over these years, it's that no matter how fast you can ship software today, people's mental model of what you are as a product doesn't change nearly as fast, and as we all know, people don't love change. But we saw the opportunity to take Tuist's value to more places, and it was hard to resist the temptation.

Today Tuist is the technology and infrastructure that augments what build toolchains can do. Doing that well takes a mix of technology and, more importantly, infrastructure, for example to close the gap of physics and reduce latency, or to provision environments quickly so organizations can run their workflows. We expect that set to be it for a while, but we don't close the door to extending to others. Our goal is a single productivity platform that spans every build toolchain an organization uses, instead of one solution and one contract per toolchain.

For every build system we support, we go deep. Deeper than anything else out there, within the limits of what each build system's data lets us surface. And once we have that data, we expose it through as many interfaces as we can offer, from a dashboard to our REST API to our MCP, so you can pull it into whichever workflow fits you best.

Down to the metal: owning build infrastructure

We want to bring the best experience to our users, and as soon as we got closer to build systems with more granular cacheable tasks, we realized compute and cache servers had to be physically colocated. That meant infrastructure, something we thought we'd only need much further down the line, when cost control became a concern. Our first instinct was to partner: could we colocate our cache servers with providers already running compute? What we ran into was a familiar dynamic from the internet's own history. The companies that laid the pipes and the companies that built the products on top became different businesses with different economics, and every time one tried to become the other, it worked for neither side. Bazel is a version of that same story in our corner: the folks running the build system rarely turn into good compute businesses, and the compute providers rarely turn into good build-system businesses. The proposals we explored fit their side of that split more than ours, and we understood why. Along the way, a couple of people gently suggested we stay out of compute altogether. For most companies that's probably right, and we spent real time asking whether it was right for us. Renting bare metal was the next candidate, with a focus on Mac environments since that's what most of our customers need. The monthly price didn't add up: we'd amortize the cost of a Mac in about three months of rent, and we'd still depend on someone else's rack layout, so we couldn't do things like colocating cache servers the way we needed. At that point we just asked ourselves: why not do it ourselves? We know it sounds scary if you haven't done it before, but the how isn't private knowledge. Doing it well will take a few iterations, and we've been there before. We ran the numbers, and the reasons people are cautious about this domain turned out to be the exact reasons it made sense for us. Economically, it's the most attractive option for us, more so than selling compute alone, because people aren't used to paying for it. We don't pay for Google Drive, and Amazon Simple Storage Service is generally cheap, so trying to scale a business around storage is tricky unless you have a strong proprietary layer, which we don't. The shift made sense.

So we're going straight into the bare metal: owning the hardware, deploying it into data centers we partner with, getting cache and virtualization technologies into the rack, and managing them for organizations that need this for continuous integration, agents, or just to make their builds faster with remote execution. The deeper we get into it, the less daunting it feels and the more eager we are to keep going. First, because vertical integration is what will let us reach the developer experience we want to provide. Think of Apple owning hardware and software: when you control both, beautiful things become possible, and we're embracing that same model. Second, it's the most sensible path business-wise. Companies are used to paying for compute, and that demand is only going to grow in the years ahead; the margins are healthy; and running Mac infrastructure is genuinely hard, so we're happy for teams to hand that off to us. Also, winters are rough here in Berlin, and doing something physical, with trips to the data center, sounds fun. And software is getting cheaper to build and replicate, so the closer we are to the bare metal, the safer we hope to be. We're already seeing this ourselves: we've replaced most of our support, error tracking, sales, and other operations tools with software we built internally. The cost of building it was days of work, and running it costs a few bucks.

Once: a build system for existing projects

Large language models and coding agents are showing us how many things that used to be expensive aren't expensive anymore, and how much that opens up. We've felt it ourselves. A team of four now runs an operations engine for the whole business, and that same team engineers a product that goes all the way down to the bare metal. What a time to be alive. We're obsessed with engineering both the product and the company, and that means we can run with far fewer people than a traditional company would expect.

Another consequence of things getting cheaper is that Bazel itself is easier to adopt and maintain, so if you're limited by the capabilities of your build system, you might just be a prompt away from improving your setup. That's part of why we moved in that direction, and we're starting to see the same appetite in our customers. It also means you, as an engineering organization, no longer have to choose between a couple of vendors that happen to have deep Bazel expertise and connections to Google, or a provider that supports the same build system but can't sell you that expertise. The knowledge is accessible to anyone now. Rules are open source. Bazel is open source. The other day I needed something the Rust rule I was using didn't provide, and OpenAI Astra went ahead and replaced the test runner, and voilà, everything worked. It's wild, isn't it?

While working on supporting other build systems, and getting to experience the pros and cons of each, I couldn't help but think: what if teams didn't have to migrate their projects? What if a build system loaded their projects as they are and brought Bazel-level remote caching and execution to them? What if we solved that by building a build system? I won't lie to you: it sounded as intimidating as deploying our own racks, but as I started working on it and seeing impressive results fast, I kept going. On the side, I was also working on supporting Bazel so I could distill from it what I liked, and take a different stab at what I didn't. Once is a build system that loads existing projects as they are and connects them to remote caching and execution. It's beautiful to see once cargo build and once cargo test running against a Cargo.toml workspace with remote caching and insights working seamlessly. And once login --provider tuist logs you in without the copy-token-from-dashboard-paste-it-here dance. Building on Apple's vertical-integration playbook, Once is the operating system for the infrastructure we're building. Owning both lets us maximize the value our users get, and minimize the steps they have to take to get it.

Openness

Openness is part of how we build trust. Have you ever been to one of those bakeries where you can see how they bake the bread, and even smell it? Isn't it fascinating? There's really nothing to hide aside from sensitive data. With code getting cheaper and faster to produce, the real value is in shipping a top-notch product, building a brand around it, and building trust with customers, the kind of trust that turns into word of mouth, and into new organizations reaching out because they're curious about how we work. Our users can see the pull requests that address their feature requests or bug reports, follow the deploys to production, and take a look at our code to learn from it. With Tuist, we not only want to build a thriving long-term business, we also want to inspire others to do the same, and who knows, spark ideas that benefit the industry as a whole.

Some people might read this and think, this guy is crazy. Like one chief executive officer told me once: dude, I have to build a business. But once you get past the fear, and once you've figured out the right model, it just gets more fun from there. As we shift more of the value to paying for managed infrastructure, we'd like to revisit our license models towards something more open-source-friendly, to give our users more freedom while keeping the business safe. This is something we aspired to from the moment we started building a company, and we knew we'd have to cap the freedom a bit to make that possible. Now that we're approaching that model, we think it's time to make some changes.

We're also exploring how to shape, build, and release products in the open. It's no secret the way we build software is changing. We write and review code with agents. We stopped doing planning, because ideas can go from prompt to production in days. We added support for GitLab and Buildkite in our runners in a couple of days. The early version of what this might look like is Hive, and our own instance is public too. The idea is that when we work with agents on something, whether that's a Grafana alert, an error, or a feature request, you can subscribe to it and see every session, pull request, and release tied to it. We recently added error tracking to Hive too, because errors are one of the richest sources of actionable signals to improve the product, and keeping them next to the sessions and pull requests closes the loop between what breaks and how we fix it. We're also building mobile apps so anyone on the team can keep their sessions going beyond a single computer. Fun fact: part of why we want to productize our bare-metal environments beyond runners is so Hive can build on top of them. For now, Hive is a product we use ourselves, shaped as open source in case anyone else wants to embrace the same model. And who knows, down the line we might end up running this kind of infrastructure for other companies too. Time will tell.

We'll also double down on openness in this blog, extending beyond product announcements. For example, now that we're going to deploy our own hardware, we'd like to capture the journey and share it with all of you. These are the stories I love reading about, because they're usually the ones that get kept as secrets. These days, if organizations ask us about managing macOS environments, we point them at our repo and suggest using it as a reference; if they have ideas for how to improve it, they're more than welcome to contribute. We're not sending rockets to space. We're building integrated technology and infrastructure, and packaging it into something people can pay for.

Storytelling

Code is cheaper and faster to produce, but marketing still isn't, and it's equally necessary if you want organizations and developers to use your product and pay for it. Every company approaches the problem differently. Based on what we've learned from coding with agents, from Asmit's design work, and from the patterns we're seeing in how people want to be told about ideas today, we're going to go hard on video.

Every time I've handed a blog post to an agent, the drafts come back cheap, careless, and looking like every other post out there. I've caught myself doing what I now do as a reader: the moment I sense that pattern, I close the tab. In a world where everyone is competing for attention, and where more and more of what's out there is slop text (engineering blog posts where you can read the prompt between the lines), we think it's more important than ever to invest in writing good content. That means going deep into the day-to-day conversations and decisions we have inside Tuist, like I'm doing here, and treating large language models as a reviewer rather than a writer. And, just as important, complementing that with short videos that capture in a few seconds what something is all about.

Have you watched those video ads Apple produces? Only they can pull off that level of craft. But we've been playing with tools to generate video, and we've built a few of our own for video storytelling, and it became instantly obvious that the cost of producing great video stories is much lower than it used to be. When we saw Asmit working on the rebrand and the animations for the site, we asked him if this was an area he'd want to explore. Guess his answer: yes. So here we go. Long term, we'd like to have a corner of the site for videos, starting with these product stories, and eventually an in-person podcast where we can interview and share the fascinating stories we come across while working on Tuist.

The bet

We want faster builds and faster tests to be accessible to everyone, from the solo developer running their first project to the largest engineering organizations in the world. That goal spans multiple layers. First, a model where anyone can sign up and get dedicated resources, either to use permanently or to evaluate the product for their team. The economics and the experience of that only work if we own and deploy the hardware ourselves. Then, once the pieces are in place, we need to minimize the amount of work a developer has to do to go from zero to Tuist. That's what pushed us to build a build system that embraces the diversity of projects out there, bridges those projects with infrastructure without asking them to change, and becomes the foundation for a developer experience we've always dreamed of and can now shape directly. On top of all of that, openness and better video-based storytelling, so you can immediately see the value of everything we're building.

The timing is right to build Tuist. Development is getting concurrent: developers now spawn multiple agents, locally or across remote environments. Remote environments are a good first step to break past the compute ceiling of a single laptop, but they aren't enough on their own. We're providing those environments, which you'll be able to use conveniently from anywhere, and we're going the extra mile by distributing build compute across a much larger, always-warm fleet, shifting work over the network. We want to democratize access to those capabilities beyond Bazel, and we have both the momentum and the position to make it happen. The other day I was reading Shopify's blog post about moving back to native from React Native, and I couldn't help but think: the more companies peel back the dynamic runtimes and abstractions, the more important distributed build compute becomes, and that's exactly the infrastructure we're building.

On the side, we keep an eye on every trend, careful not to spread ourselves too thin. Software factories, coding harnesses, object-storage-backed source control... it's tempting to chase some of them, but we believe it would be a mistake. So we're staying focused on build toolchains, an area that isn't getting the attention it deserves, and we're here to make some noise with Once and our infrastructure. Stay tuned.

We've assembled what we believe is the best team to help organizations return to native without giving up the speed of iteration they were used to. That's the four of us below, gathered for an offsite in Tavertet, a small mountain village north of Barcelona, to align on this and start executing. It's such a special place that we're naming our first piece of hardware after it. If you ever get the chance, go visit.

I could ask you to sign up, but honestly I'd much rather jump on a call, understand your setup, and see if there's a way we can help you optimize your workflows.