Hola 
,
As you might know, we’ve completed the second cycle of the year. We’re meeting next week to share the work we’ve done, and I wanted to share our plans for the next few weeks before we get there.
Automation evolution
Teams have requested more flexibility in the area of automation, so we’ll iterate our foundations to give teams a language to describe their different automation needs. The long-term plan is to have a programmable interface that can run more sophisticated workflows, where Tuist brings the data and the ability to evaluate the logic in it. Think less “configure a CI step” and more “describe what should happen when a threshold is crossed.” This cycle is about laying the groundwork to get there.
Webhooks
Connected to the above, we’re also adding webhooks. One of the actions developers can configure in their automations will be sending a webhook to an external service. But beyond that, teams will be able to use it to ingest Tuist data into their own infrastructure, whether that’s building a custom dashboard, wiring into their own pipelines, or feeding data into whatever observability stack they already have. We want Tuist to be something you can build on, not just something you use.
Cache node sharding
We’re going to invest in the placement of tenants in our cache infrastructure and the allocation of resources to them. Right now we don’t have the control we want over those decisions, and it limits our ability to give meaningful guarantees around performance. With better placement, we’ll have the signals to decide when to scale, where to scale, and what SLOs we can actually commit to.
Visual identity redesign
We noticed that our visual identity is still tied to what Tuist was a few years ago: a project generation tool for Xcode. That’s not what we are anymore. We’re building toward something that works across build systems and programming languages, and the visual identity should communicate that. We will work on this as part of the cycle and start executing on a direction that reflects where we’re going.
Cost observability
We’ve reached a point where understanding our cost structure properly is important. Not just watching the numbers, but knowing which parts of the platform are expensive, how that maps to our tenants, and whether our pricing model is positioned to cover costs while staying competitive. We’ll centralize this in Grafana, pulling data from our various infrastructure sources into one place. We’ll also be working with a sales mentor to think through a longer-term pricing strategy.
Documentation information architecture
After moving our documentation to Elixir and refreshing the design, we want to continue with the information architecture. How our content is organized, what’s missing (we’re particularly aware that tutorials and guidelines are underrepresented), and making sure everything is accurate and up to date. Parts of the documentation still assume Xcode is the only build system we support, which is no longer true and gives a poor impression to teams coming from other ecosystems.
Compute
We couldn’t make much progress on compute last cycle, so we want to come back to it with focus this time. The first use case is providing CI runners for companies, but compute is also foundational for the agentic workflows we’re building toward, where we need environments we control end to end. Getting the basics right now opens more than just runners.
Looking forward to seeing everyone next week. As always, if any of this connects to something you’re thinking about, feel free to jump into the community discussions linked above.
Pedro