What I cannot stop thinking about is the reasoning behind them. Listening to founders and CEOs talk about why they are doing this, the answer that emerges is not really “things got worse.” It is more uncomfortable than that. It is “we designed our company years ago, and the shape we ended up with no longer fits the world we are in.” Some of the people they hired are excellent at executing the old shape. Some do not want to embrace the new one. That is a brutal position to be in, and I understand why it ends in layoffs even when nobody wants it to.

I am writing this from the other side. From the side of designing a small company today, with a clean sheet of paper, while watching this play out.

The Shopify thing

When I worked at Shopify, one of the things that quietly shaped my thinking was how they treated internal tooling. Most companies I had seen, including ones I had been part of, would reach for whatever the market offered. Linear, Jira, the CRM of the moment, the support tool of the moment. The tools came with their own opinions about how work should happen, and the company quietly bent itself around those opinions.

Shopify did the opposite. They thought about how they wanted to operate, and then they built tools that supported that. They had the resources to do it, of course, and at the time that felt like a luxury reserved for companies of their size. If you were a small team or a single founder, the cost of building and maintaining your own internal stack was prohibitive. So you did the only thing you could do: you adopted the tools other people made, and you absorbed their model of work.

That equation has flipped.

The cost of building has collapsed

The cost of producing code is at a historic low. The cost of running it on infrastructure is at a historic low. The cost of designing thoughtful interfaces, when you can lean on a design system and a coding agent, is at a historic low. There has never been a better moment to sit down and ask the question that used to be a luxury: how do we want to work, and what would the tool that supports that look like?

This is something we can afford to do at Tuist precisely because we are tiny. We do not have to nudge dozens of people in a particular direction. We can spend a week thinking about how we want to do something, and another week translating that into the tool that supports it. A lot of what makes a company run is common sense and pattern matching from what others have done. There is good literature out there. But there is also something specific to our space, our values, the way we like to work, and that part is not in the literature. Someone has to take the time to think about it, and then translate it into the tools.

What we built first

We built an internal tool we call Atlas. I have written about it already, but let me share what we have actually done with it lately.

I started with the CRM side. We dropped the CRM we were using and moved everything to Atlas. Then we plugged in the sources of signal we already had:

• Transcripts from Granola
• Conversations on Slack, including the shared channels we have with companies
• Email threads
• Product usage data

From there, Atlas builds a profile for every account, and agents nudge me towards the things that are likely to matter. Not “send a generic check-in.” More like “this conversation three weeks ago was about a feature you just shipped, this is a good moment to follow up.” Because Atlas can read how a customer is using the product, it can also suggest features they have not tried yet but probably should. That is the floor. We will keep raising it.

The Zapier-shaped trap

There are CRM tools out there leaning hard into agents. I look at them and I see something that feels broken to me. They are, in essence, Zapier-shaped. Connect this API. Connect that one. Build an orchestrator over the orchestrator. The reason this happens is structural: a tool that wants to fit every company has to be designed against the lowest common denominator of all the other tools out there.

When you build for yourself, the equation is different. You do not need to integrate with every CRM in the world. You need to integrate with the systems you actually use. And ideally, once your tool integrates with them well, some of those systems are no longer necessary. The CRM we were using, in the end, was a database wrapper with a few nice features on top. We copied the features that were useful, and we dropped the wrapper.

There are tools where reinvention does not make sense. We use a service to sync our banking data and give us financial insights, and replicating it would be silly. That is a regulatory and data-source problem more than a product problem. But most everything else, at least in our case, is replicable. More than people realise.

What is next

We are looking at support next. Then development operations. I can already picture Atlas reading an alert from Grafana, doing an initial investigation against the codebase, opening a draft PR with a candidate fix, and pinging the team with the reasoning. I can picture it drafting responses to community questions by reading the code and the docs. None of this requires a research breakthrough. The pieces exist. It is a matter of deciding to compose them around the company you want to be.

Where I land

The layoffs we are seeing are, in part, the bill for designing companies in a world that no longer exists. I do not say that to be smug, because designing a company is hard, and the world genuinely changed faster than anyone expected. But the lesson, for those of us building now, is hard to miss.

You want people who can leverage these technologies to build first. People who look at the resulting system with curiosity, and want to contribute to making it better. The tools come from the company you want, not the other way around. The companies that internalise this and act on it are the ones I expect to compete on a different curve. The ones that do not, I suspect, will be writing the layoff blog posts a few years from now.

That is the company we want to build.

The infrastructure companies that emerged around caching read the room. They built for those enterprises. Contact sales. Book a demo. Long onboardings where the goal was not really to automate anything, but to get you on a call. The product, in the end, was the call.

We think that era is ending.

What changes when you have agents on the same machine

Picture working on a project with multiple coding agents, each on its own git worktree, each running its own builds. It does not matter how fast your laptop is. There is a limited number of cores, and several agents are about to fight for them, compiling the same things in parallel. Your machine becomes unusable, and a non-trivial amount of compute gets burned redoing work that was already done somewhere else, by someone else, ten minutes ago.

The need to optimize for caching, which used to live in the realm of large monorepos, is now showing up on every developer's laptop. If you are a small team and you want your agentic setup to be fast, you need the same kind of infrastructure that until recently was only justifiable at scale. You want your CI to share work with your local machine. You want the agent in container A to share work with the agent in container B.

This is the shift. Caching is becoming an everyone problem.

The Supabase shape

The thing we have to do at Tuist is productize this. And not just for the large enterprises. For indie developers and small teams too.

A good frame for what that looks like is Supabase and Vercel. It is not that we did not have hosted databases before they showed up. It is that they made it easy. They wrapped the operational layer in an API, added the conveniences developers actually need, and then once the new wave of platforms like Lovable and Replit needed somewhere to keep state, Supabase was the obvious answer. You sign up, you create a project, you wire up auth, and you are done.

That is the bar we want for caching at Tuist. Sign up, create a project, authenticate locally, and have your build system pulling cached artifacts within minutes. Convenient for the user, convenient for the agent.

Convenient for the agent is the part most companies still miss. If a user can do something, an agent should be able to do the same thing through a clean interface. That means investing in APIs. It means investing in MCPs. It means making sure that every action a developer takes to set up caching, whether that is connecting it to Bazel, Xcode, or any other build system, can also be taken by an agent walking them through it. It also means showing up where the agents do, on every LLM marketplace possible, so that when somebody tells the agent "this is slow," the conversation can drift naturally toward setting up Tuist. Zero to using a cache in a few prompts.

There is one more design constraint underneath all of this that is easy to miss. Caching cannot be fast only in one environment. It has to be fast wherever the build is happening. Your laptop, your CI, your agent's container, your colleague's machine on a flaky hotel WiFi. That is what we are building, on both the infrastructure side and the application side. A system that productizes caching beyond a single build system, with the cache as a primitive that can serve whatever action is happening, wherever it is happening.

What agents do to Bazel

Bazel is still the most sophisticated toolchain out there for setting up caching in an existing project. The reason it never quite worked in places like the Apple ecosystem is that the IDE was not designed for a different build system. Xcode wanted to be both the editor and the build system, and Bazel asked you to give that up.

That tension is dissolving. People depend less and less on integrated IDEs. If your day-to-day driver is Claude Code or Codex, the build system underneath becomes an implementation detail. As long as it is fast, reliable, and the agent can iterate on it, the rest does not really matter.

The other side is that agents are very good at writing Starlark. The cost of writing Bazel files for your iOS app, your Android app, your Rust server, your desktop app, all of that is being pushed down. We will probably see more Bazel adoption, more plugins, hopefully more contributions to make Bazel itself better. We are new to it, and we are building a real appetite for learning, putting resources behind it, and supporting the community along the way.

Where we land

When the two ends of this meet, agents lowering the cost of authoring the build system on one side, and Tuist productizing the infrastructure on the other, the result is that caching stops being an enterprise-only conversation. The infrastructure that makes everything fast, not at the compute level but at the level of what is actually happening inside the compute, is something we want to make available to anyone. Indie developers. Two-person startups. Mid-size teams. Whoever needs it.

We also think we are going to see agents start paying for things on behalf of their users. Stripe is investing into the protocol piece of that, and that future is coming whether the rest of the industry is ready for it or not. We want to be ready for it.

The contact-sales model is not where this is going to live. We do not love the word democratize as a concept, but you get it. If caching is going to be a theme for the next few years, anyone should be able to make their agentic setup faster without going through a six-month enterprise procurement cycle.

We are putting the pieces in to make that real.

I was a fan. I still think they have a role to play. They are, in many ways, convenience as a service. Some of them, like Vercel and Fly.io, went down the road of running their own hardware, probably for cost reasons but also for the flexibility of deciding where and how to allocate resources. Others, like Render, run on top of AWS, which means you pay a tax on top of the compute you would already be paying for.

For a long time that tax made sense, because the alternative was learning Kubernetes, or building out your own runner setup, or stitching together something with Terraform and a deep breath.

That equation has changed.

What agents quietly did to infrastructure

Coding agents have done something I do not think we have fully appreciated yet. They have codified the knowledge of tools that were traditionally considered too complex to touch. Kubernetes is the obvious example. Bazel is another. These tools are still complex, but the ramp is no longer a wall. You sit down with an agent, describe the shape of what you need, and it walks you through the concepts that apply to your specific case. The ones that do not apply, you do not even need to learn.

That eliminates a whole layer of convenience that companies were charging for.

What happened at Tuist

We just lived this at Tuist. We moved off Render and onto a Kubernetes cluster running on Hetzner. The cluster is currently managed by another company, and that is the next thing we are going to change. What blew my mind is how easy the whole setup was to navigate. We are a tiny team. A few years ago this would have been a project. Now it was a couple of focused weeks.

There is a motivation behind the move that is worth naming. We are shaping Tuist into a company that captures value by providing infrastructure. To do that well we need to declare our infrastructure as code, reason about it, and understand it deeply. Going through a managed PaaS is the wrong shape for a company whose product is increasingly about running infrastructure for others.

What we did not expect is the bucket of things that came along with the move.

Costs went down, which we expected. But suddenly we could lean on agents to reason about our infrastructure too. They could read manifests, propose changes, and inspect the live state via kubectl. Grafana has first-class support for Kubernetes, which means we now have an observability toolchain that was simply not on the table before. None of this would have been possible inside Render's world, where access to our own infrastructure was, by design, gated by them. That is fine for most people. After tasting another world, I cannot go back.

CI looks suspiciously similar

I keep thinking about this in the context of CI. There is a category of companies emerging there: Blacksmith, Depot, Namespace, RunsOn. Some bring their own hardware. Some, like RunsOn, run directly on AWS. The shape is similar. You get faster, cheaper CI, with someone else doing the operational work of attaching ephemeral environments to your Git forge.

The thing is, the basic problem is not that hard to solve. You need compute. You need to spin up environments. You need to wire them to GitHub or your forge of choice. That is the floor. And once you internalize that the floor is reachable in-house with the help of agents, you start to wonder what the rest of the value really is.

You can already see developers experimenting in that direction. Peter Steinberger just shipped a release of his tool Crabbox that includes, among other things, an "AWS image create" command baked in. It spins up remote Linux runs from your laptop and talks to the cloud provider directly. No middle company. It is a small example, and it is one of many to come. Once the friction of touching the provider yourself drops, the layer that sits between you and the provider has to keep proving why it deserves to be there.

That, I think, is why these companies are increasingly trying to sell something beyond compute.

What they are actually selling

What they are selling is a story. That is how capital flows in our industry, and there is nothing wrong with selling stories as long as the story holds up.

The story right now is the infrastructure for agents. The infrastructure for agents to run their tasks. The infrastructure for agents to run the work they produce. Infrastructure for a world that is unfolding and that nobody really knows the shape of yet.

I have mixed feelings about it. We already have cloud providers that can do this. You can build directly on them, and use the room you save to innovate on something else. But that is not how our industry moves. Layers emerge. They disappear. They move. They get renamed. Many of them are sustained more by stories and promises than by the strict technical need they answer.

The serverless wave is a good reminder. Functions that run close to the user, sold on the promise of latency, while still having to traverse the planet to reach a Postgres database managed by yet another company. Pricing models that look great on the cheap end of the curve and quietly become bizarre at scale. You sit there waiting for your provider to ship a feature so that your bill stops growing in ways you cannot explain.

Elastic CI compute. Elastic agent compute. Elastic function execution. Pay per minute. Pay per token. We love that.

Where I land

I do not want to dismiss any of these companies. Many of them are run by people I respect, solving real problems for real customers. The convenience they offer matters. For most teams, paying the tax is still the right call.

But the equation underneath has shifted. If there is an agent in the room with you, the layer of convenience you used to rent gets thinner. The case for owning your infrastructure, or at least owning the ability to reason about it, is stronger than it has been in a long time. And the things you discover when you cross that line, the access to your own systems, the observability, the freedom to compose what you actually need, are hard to give back once you have had them.

That is the part nobody puts in the marketing copy. And that is the part I keep coming back to.

Because we are small, we do a bit of everything. Go to market. Marketing. Product. Support. Sales. In traditional companies, each of these is a whole department, sometimes a whole organization. That is a luxury we cannot afford, and honestly, I am not sure we would want it even if we could.

The multi-tool problem

Like most small companies, our first instinct was to lean on tools for each of those functions. We picked Operate for CRM. We kept some data in GitHub repositories because we believe markdown and configuration files are perfect formats for things that need to live close to code. We do support across community channels and GitHub issues. It is a bit all over the place.

What we keep learning is that we are constantly jumping between tools, and sooner or later we hit a wall. Either we need a feature the tool does not have, or we need to correlate data across tools, which is essentially impossible when the data lives in different silos. We can connect MCPs locally and try to do that correlation ourselves, but we miss the opportunity to automate things. To trigger workflows when something is detected across the various sources. The interesting work is at the intersections, and the intersections are exactly where these tools have the weakest answer.

What if we built it ourselves

This is when we started asking a different question. What if, instead of stitching ourselves across a multi-tool setup, we built the tool we actually need?

We have coding agents that can write that tool with us. We have a design system that lets us combine building blocks into our own dashboards. We have all the pieces. The economics of building software for yourself have changed in a way I do not think we have fully internalized yet.

I started an internal project at Tuist called Atlas. At first I thought we could open source it, but after sitting with the idea for a while, I realized that what we are designing is very specific to the needs we have as a company. Every company has its own shape. That is why companies like Stripe end up building their own internal platforms, and why no two of those platforms look the same, even when they solve overlapping problems.

What Atlas does first

We are starting with sales and account management.

Traditional CRM tools all look the same, with a bit of AI sprinkled on top. What we want is something that tracks the full picture of what is happening with a customer. Conversations on email. Conversations on Slack. The shared channels we have with companies. The way they are actually using the product.

If Atlas knows which features we just released, and remembers the last conversation we had with a customer, it can do something more useful than reminding us to send a generic "how is it going" message. It can tell us "this might be a good moment to ping this company, and you should bring up this thing because they asked about it three weeks ago." That is the kind of nudge that turns into a real conversation. That is the baseline, and we want to go beyond it.

Beyond sales

Sales is just the entry point. The same idea applies across everything we do.

Now that we have moved everything to Kubernetes, we have access to Grafana and a constant stream of signals about how our production systems are behaving. What if Atlas was watching that too? Detecting something unusual, doing an initial investigation on its own, then pinging us with the relevant data and the reasoning behind it. Even opening a draft PR with a potential fix for what it found.

These are examples, not a roadmap. The point is that if the data lives in one place, and the tool can act on it, the kind of work that used to require a dedicated team starts to become accessible to a team of four.

The bet

This is what excites me. It means we can stay extremely agile as a company, which I believe is critical to making an impact when you do not have the resources to spin up a dedicated organization for every domain. If we tried to compete with the big players by replicating their org chart, we would lose. We do not have the runway, and we do not have the patience.

I do not think we are going to scale by hiring an organization for every function. We are going to scale by building Atlas alongside the people we hire, so that whoever joins can bring their judgment to the areas where they can move the needle, while leaning on a platform that takes care of the rest. The platform itself becomes a teammate. One that we keep iterating on as we discover what we actually need.

The traditional shape of a company assumes you cannot build your own internal tools, so you assemble a stack of vendors instead. That assumption is no longer true. The cost of building bespoke has collapsed, and what you get on the other side is a company that fits its tools rather than the other way around.

That is the company we want to build.

Since then we have been building. And the way we have been building has shifted in ways I want to share, because the shape of the system is telling us something interesting about where this is going.

The problem, restated

Developers want caching. Agents want caching even more. Inference is fast, and getting faster, but compilation is not. You can have an agent writing code at a speed that would have been unthinkable two years ago, and then watch it sit there waiting for the build to finish. Compute is expensive. Re-doing work that has already been done is the kind of waste that stings even more when an agent is the one paying the time tax.

The way out is the network. You lean on low-latency caching to give you near-uncapped access to pre-compiled results, and you skip the work entirely. We have known this since the beginning at Tuist. It is what our project generation cache has done for years for Xcode. It is what we are bringing to Gradle now, and Bazel later this year.

But once you go down that road, one thing becomes very clear: low latency is everything. If the cache is slow, the math stops working. The cost of fetching from the cache approaches the cost of just compiling, and at that point why bother.

Latency is not just one number

The harder part is that low latency cannot live in only one environment.

If your caching servers run in our infrastructure and your CI happens to run near them, things feel fast. If your build runs somewhere else, like a developer's laptop in Buenos Aires or an agentic environment that spun up in some random region, things do not feel fast at all. That always felt wrong to us, especially now that the picture is more fluid than ever. Agents have their own runtimes. CI providers have theirs. Local machines are still part of the story. None of these are guaranteed to be in the same region, or even on the same continent.

We knew we had to build for that. So we did, and we built it as a multi-tenant system from the start, because that is what we were familiar with. And that is where we made some serious mistakes.

What multi-tenant taught us

We left almost every resource unbounded. Network access, connection pools, database connections, file descriptors, file system. The system would crack at the seams very quickly. One tenant doing something demanding would degrade everyone else. Classic noisy neighbors.

It became obvious, after running into this enough times, that we were not going to scale a multi-tenant caching system unless we were Cloudflare. We are not Cloudflare. The kind of investment required to do that well is the kind that defines a company, and that is not the company we want to define ourselves as.

So we asked the obvious question: what if we went single-tenant?

What single-tenant looks like

Single-tenant means each tenant gets their own caching instances, in the regions they care about. The mental model is the same one Supabase uses for Postgres, or PlanetScale used for MySQL. You pick where your database lives. You pick where your replicas live. Same idea, applied to caching nodes. Want one in Frankfurt and one in Sydney? Done. Want one near the GitHub Actions region your CI runs in, and another near the Codex environment your agents spin up in? That works too.

The cost we knew we would pay is operational. We have to manage the deployment and the updates of those caching nodes per tenant. Not the whole stack, just the caching part. That is real work. But the alternative was a system that would never scale without us turning into an infrastructure company, and we already have a clear sense of what kind of company we want to be.

To make this work, two things had to be true.

The first is that the infrastructure had to be simple to operate. I know it sounds odd to say this and then mention that we ended up with Kubernetes, which is many things but not famously simple. The trick is that we have coding agents now. The pieces of infrastructure that used to require a dedicated team to operate are becoming far more accessible when an agent can read the manifests, reason about them, and take action on them.

The second is that everything had to be infrastructure as code. Scaling rules, update rules, deployment rules, all of it declarative. That gives us a system we can reason about. It also gives us a system an agent can dig into when something is off in production. A standard declaration file that agents can write, understand, and use to inspect what is happening.

The cache as a network

Single-tenant on its own is not enough. Without something else, single-tenant becomes single-region by accident, and we are back to the problem we started with.

So we needed the nodes to act as a network.

Every node should be a full interface for the clients. Read, write, cache, all of it. And in the background, those nodes should distribute artifacts among themselves in a leaderless way. An artifact pushed from a developer in Berlin should make its way to a CI runner pulling from Sydney without any of the clients having to think about it. No central coordinator, no special node. Just nodes talking to nodes.

This is the part that ties the experience together. It is also the part where we are spending most of our thinking right now, because getting it wrong has the kind of failure modes that are very visible to users.

The technology, separately

Here is where it gets interesting to me, and where it connects to a longer thread we have been pulling on at Tuist for years.

Supabase hosts Postgres. They are, in some sense, a hoster of an open-source technology with a lot of value added on top: dashboards, auth, storage, realtime. But the core thing is open, and you can run it yourself if you want to. PlanetScale was similar with Vitess.

What if the caching layer was the same? The technology, standalone. Open source. Something you can host yourself if you want to. And we host it for you, because we will do the work of running it fast, safely, and securely. We bring the convenience. You keep the option to walk away.

On top of that, we bring the analytics. You cannot really know whether your caching is doing its job without observability. You need to see hit rates, miss rates, the artifacts that are getting evicted too often, the regions where things are slow. Without that, caching is a black box that either feels fast or does not. With it, caching becomes something you can actually tune.

This is the combination we have been working toward over the past few weeks. A piece of standalone technology that can take artifacts pushed by Gradle, by Bazel, and by many clients that nobody is thinking about caching for yet. We take care of running and managing it. You focus on your project. The analytics come along for the ride.

What is next

I have not been this excited about a foundation in a long time. This is the layer the rest of the house we are building sits on. Caching is the part where the speed shows up. Compute, when we add it, will be the cherry on top of the cake.

We will have more to share in the coming weeks. There is more to say than fits in a single post, and frankly some of it will read better when there are things you can actually try. For now, this is where our head is at, and it feels like the right combination of pieces. Open at the bottom. Convenient at the top. Close to wherever you happen to be building.

Part of me kept asking the obvious question. If Bazel is now easier to adopt, why not Bazel everywhere? The more I sat with it, the more I realized the problem is not technical. It's about how things actually work in our industry.

Integrated toolchains are the real ceiling

Look at Cargo, Vite, or Mix in Elixir. These are integrated toolchains where compilation tasks and non-compilation tasks are woven into something that goes far beyond compiling. Vite ships an HTTP server doing hot reload of resources in the browser. Mix orchestrates dependency resolution, releases, and a whole runtime story. Cargo handles registries, features, and workspaces in a way that has become inseparable from how Rust developers think about their projects.

If you wanted to do all of that in Bazel, you would literally have to replicate the internals of Cargo, or Mix, or Vite. That's an insane amount of effort, and on top of that you'd be forking the ecosystem. You wouldn't benefit from the work that the maintainers of those tools keep pouring in, and you'd have to keep up with them forever. There is real value in Bazel, but there is no version of "Bazel everywhere" that doesn't end up rebuilding the world.

Coding agents don't change that. They lower the human cost of adoption, but they don't lower the cost of forking an entire ecosystem.

The plugin layer is a tell

When you look at how Bazel plugins are implemented for some of these toolchains, you notice that under the hood they often end up shelling out and calling Cargo or the equivalent. That feels wrong to me. It's the build system admitting that the integrated toolchain is the real source of truth, while pretending to wrap it.

I caught myself imagining a different shape. What if there was a foundation underneath all build systems, something like a content-addressable store with a shared event model, that every ecosystem could build on? A common floor that lowers the stack and lets each toolchain keep its identity on top. A bit like LLVM, where some toolchains build on it and others don't.

It's a nice thought, and also an impossible one to execute. You'd need every ecosystem to migrate to the same foundation, which is not how our industry moves. LLVM is the closest example we have, and even there the adoption is uneven. For something as load-bearing as build infrastructure, the gravitational pull of "what already works" is too strong.

Build systems learning from each other

What I think is realistic, and probably more useful, is for these tools to learn from each other and incorporate similar ideas. Telemetry is a good example. It's still uncommon in build systems, even though it's the most direct way to understand where time is being spent and where caching would pay off. The content-addressable store idea is another one. So is aligning around a shared contract with a remote cache server, so that the cache layer becomes interchangeable.

We'll definitely see more companies adopt Bazel where it makes sense, but I don't think it's going to be everywhere. My bet for the next few years is that the other build systems catch up in terms of ideas, while staying inside their own ecosystems.

Where Tuist fits

For us, this is the bet we want to make. We want to be ready to provide the infrastructure for low-latency caching and analytics, so that all the complexity of running those things yourself is taken care of by us. Productized in a way that feels closer to Supabase or PlanetScale than to a build engineering team.

You focus on your tools, your projects, and the runtime of your software. We integrate with every toolchain that exists and deploy productivity infrastructure for you. That's a more honest answer to the original question than trying to convince everyone to adopt the same build system. The world is not converging on one toolchain, and it doesn't need to. What it needs is a shared layer of infrastructure underneath the ones we already have.

To start somewhere, I remember the day someone in the mobile developer tooling market reached out and floated the idea of buying Tuist. What would they buy? Why would they buy it? A week later they came back with a "we don't think your project generation thing will go anywhere, but what if we give you 50$ a month to talk about our company a few times on X." No, I said, we are not influencers. But it turns out that's how some people with access to capital see open source and open source maintainers, as folks who can build strong brands and communities, and who might be persuaded to trade reputation for peanuts. Some companies in this position have wide latitude when it comes to chasing financial goals, and this one was willing to publicly surface other people's mistakes in exchange for eyeballs. They eventually ended up in an exit to a larger company that wanted a presence in the mobile market, the very presence they had manufactured by throwing money at the problem. That is what money lets you do. You can manufacture value and aim for an exit story. A bit sad to see, honestly.

I'm not against raising capital, but I don't relate to the idea of round-to-round jumping as the final game to play. I dislike it because the incentive of pushing valuation up tends to be stronger than bringing real value to the people that use your craft, and at some point the gap becomes so visible that companies have to invent a story to mask what's becoming obvious to everyone, the enshittification. I don't want to be in that position. The position of having promised multiples of a valuation, realizing you can't go beyond the current ceiling, and starting not only to throw darts at ideas but to invent fictional needs and stories that your customers can buy into. That's when you see companies organizing events that look more like a festival, or coining new categories like Mobile DevOps, where even the people pushing the term struggle to define it. I'm a firm believer that a business' natural growth needs time, the time you might not have if you raised money and promised to spend it in two years. Only when you have the freedom that perspective gives you, that is when you can make decisions that fit incrementally into the product. Rushing it is a recipe for disaster, and you don't want your users to gain perspective on how absurd the whole thing has gotten. I was reading yesterday about an app that had replaced its core with WebKit after endlessly shipping features, including a subscription-capped note-taking feature, and users were frustrated and going back to their previous app. That's the tension I'm describing. You lay the ground for enshittification.

Because money is sexy. Who doesn't want it? But you don't really get to tell your users about it, because no one likes seeing others get richer, unless we get richer with you, in which case we're vibing, and we can all figure out together how to make you richer. Perhaps it's not about the quality of your app, perhaps you just aren't using these other features I'm offering you. Let's all figure out how to get more people sharing their MRRs on the socials, because that's marketing for me too, so I want more indies building, I don't really care what. Sad to say, but it happens. I said capitalism is odd, and this is once again an example. The craft becomes secondary. It's all about the money. The more and the faster, the better.

And as I said, you don't want to tell your users about it, you need a story. One founder kept insisting that their main focus was delivering value to their users. That sentence kept replaying in my head, because that's what I had always assumed was the point of a company, but after seeing how many companies actually operate, it's not always the case, even when the marketing site says otherwise. As I said earlier, what we need is a good story. Capitalism needs good storytelling, one that can cover the interests living in the back end. Don't run away when I merge acquisitions and water down the product, I'm still here for you. Well, no. You are sold to your investors, you are building for them, and we are just a tool.

We did raise. Tuist wouldn't have got off the ground otherwise, but we were very clear from the start that jumping from round to round was not the game we wanted to play. We'd only raise if we saw the need, and right now we don't, so we keep walking our path from a point of profitability, without the weight of external incentives. It's liberating, especially as you watch other companies around you play a different game. We've already had three conversations around acquihiring us. They never use that word, of course; they prefer "joining forces", because without us you folks will have a hard time, and that might be fine because you might not want to eat the world like us.

The deeper you go, the more absurd it gets, but I guess it's inherent to doing business with money as the first goal. People will take any shortcut to multiply profits, and what I find funny now is that I can see the two realities clearly. There's the struggle of balancing what your business is actually capable of with what you promised the investors. And then there's the story you tell your users. The strange part is that, in the process, the company often digs the tomb of its own product, even though for the people running it that might still end in an exit. Look at Heroku. But for them, that doesn't really matter.

I think there's value in building a different kind of company. One that places people and craftsmanship first over growth at any cost. A company that is fine with not capturing 100% of the value, gifting the world with OSS tech that anyone has access to, like cities building public parks. A company that embraces the perspective of time to make incremental changes that genuinely make sense to the users.

That setup worked well enough that I did not feel much urgency to move to a GUI. I could see where things were heading. OpenAI was clearly investing in graphical environments like Codex, and the push toward worktrees as the right primitive for parallel work made a lot of sense. But I had not felt the need to throw myself into it.

Yesterday I finally did. Rainy Sundays are good for this sort of thing. You open a new tool out of curiosity, expecting a few nice ideas, and suddenly you realize something deeper might be changing.

Why it clicked

The layout is obvious in the best possible way. Sessions on the left. The active coding session in the center. A terminal at the bottom, which I still need to boot services locally. And on the right, the parts of the workflow that usually live in separate windows: diffs, comments, and a browser to interact with the thing I am building.

I think that last part is what surprised me most. I did not feel like I was using an editor with AI bolted onto it. I felt like I was inside the whole loop. Ask the agent to do work. Run or restart services. Inspect changes. Leave feedback. Click into the app. Repeat. I did not feel the urge to leave Codex.

I had been reading Thomas Ricouard's excitement about this way of working, and I get it now. When people say the editor is changing, this is what they mean. The terminal is still there, which matters to me, but it is no longer the whole experience. It becomes one pane in a larger environment that keeps the entire feedback loop close at hand.

The integration opportunity

The more I used it, the more I kept thinking about a big opportunity: tighter integration with the toolchain many of us already love, starting with mise and its satellite tools.

First, sessions need tools from the system. That is exactly what mise is for. Python, Ruby, Node, and pretty much anything else a project might need. If a repository already describes its toolchain through mise, the editor should be able to lean on that rather than invent another provisioning story.

Second, Codex has the notion of actions, and that aligns beautifully with mise tasks. A repository already knows how to start itself, test itself, lint itself, seed data, or build artifacts. If those tasks exist in mise.toml, Codex could detect them and auto-register them as actions in the UI. That would turn the repository into the source of truth, which is exactly where that knowledge should live.

Third, some projects need services running. A Postgres instance. A cache. A local broker. That is where Pitchfork gets interesting. It can manage those services, scope them to a session, and even set up a system-level proxy that is bound to that session. If Codex can see that URL, it could hoist it in the UI as a first-class destination. Click it, and you are in the running app without jumping across tools.

What excites me here is not just convenience. It is the chance to make the editor a thin integration layer over tooling we already trust. Not another place where configuration gets duplicated, but a place that reads the project's declared tools, tasks, and services and turns them into a cohesive experience.

I still love the terminal. I still think it is the right substrate for agentic development. But after spending a rainy Sunday with Codex, I no longer think the terminal is the final form. There is a lot of room above it for an integrated environment that keeps sessions, terminals, review, and the browser in one place.

If Codex gets tighter integration with tools like Mise and Pitchfork, I think it becomes even more compelling. Even without that, I have to give credit where it is due. The Codex team is building something that, at least to me right now, feels like the future of editors.

That gap is where I think the next chapter of what we are building lives. If we have the data, and we understand the toolchains deeply enough to know what the data means, why are we stopping at dashboards? Why not act on it?

The platform team you do not have

Most companies above a certain size have a platform team. A group of engineers whose job is to make everyone else more productive. They look at build times, investigate flaky tests, optimize CI pipelines, maintain shared infrastructure. They are the people who care about the things that no feature team has time to care about.

The problem is that most companies are not above that certain size. They do not have a platform team. They do not have someone whose job is to notice that a test suite has been getting slower by two seconds every week for the past three months. They do not have someone who catches that a specific module is being recompiled unnecessarily because of a misconfigured dependency. These things just accumulate silently until one day the build takes twenty minutes and nobody remembers when it started being this slow.

What we realized is that the data we already have from builds and test runs, combined with the context we have from the project structure, gives us everything we need to play that role. We can be the platform team. Not as a consulting engagement, not as a one-time audit, but as something that is always running, always watching, always ready to act. And the exciting part is that this makes the platform team accessible to any company, no matter how small.

From dashboards to actions

Everyone in the developer tools space is starting to think about agents, but they are thinking about it differently depending on where they sit. Linear is exploring agents that can act on issues and look at code. Codex and Claude Code are building agents that write and modify code directly. These are valuable directions, but they are all converging on code as the thing the agent acts on.

I think there is an underexplored space next to that. Not acting on code, but acting on productivity. Using the signals from builds and test runs to trigger workflows that actively improve the state of things. If we detect a flaky test, do not just flag it. Quarantine it, investigate it, propose a fix. If we see a build graph that is not making good use of available parallelism, suggest the structural change that would fix it. If a dependency update introduces a regression in compile times, catch it before it lands.

I do not know if there is an established term for this yet, but I have been calling it agentic productivity. The idea that an agent does not just help you write code, it helps you maintain the health of your entire development workflow.

Building the pieces in Elixir

Because this is the direction we are heading, I have been spending time building the foundational pieces. Our server runs on Elixir, and I wanted to understand what it would take to build agent workflows natively in that ecosystem. Not just call an LLM API, but build something that feels right in Elixir and takes advantage of what the platform gives you.

The first thing I needed was a place for the agent to work. If you are going to have an agent that acts on a repository, cloning it, running commands, reading files, making changes, it needs a sandbox. A disposable environment where it can do its thing without affecting anything else. I looked at the landscape of sandbox providers and found a lot of options: Daytona, Exe, and others. They are all converging on a similar model. You spin one up, do your work, tear it down. Fast and ephemeral.

But they all have slightly different APIs, and I did not want to couple our agent infrastructure to any single provider. So I built an Elixir package I am calling :terrarium. It is an abstraction layer over sandbox providers, a unified interface with adapters. You configure your credentials, pick a provider, and you get a consistent API to create a sandbox, SSH into it, run commands, stream output, and destroy it when you are done. I built adapters for :terrarium_daytona and :terrarium_exe to start with, but the interface is designed so that adding more is straightforward.

This matters for us in particular because none of these providers offer macOS environments. And most of our customers are working with Xcode. So we are also working on being able to provide those environments ourselves, which is something we need regardless for the broader compute story at Tuist. Having Terrarium as the abstraction means our own macOS sandboxes slot in through the same interface as any third-party provider.

The agent itself

On top of the sandbox layer, I built the agent. I am calling it :condukt. It is a GenServer in Elixir, which is the natural way to model a long-running, stateful process in the BEAM ecosystem. At its core, an agent is a loop with tools. You give it a prompt, it reasons about what to do, it picks a tool, it executes it, it observes the result, and it loops again until it is done.

For the LLM interaction, I am using :req_llm, a library that abstracts over different providers. The same fragmentation problem exists there: Anthropic, OpenAI, Google, they all have slightly different APIs for doing essentially the same thing. A unified interface lets us swap providers without rewriting the agent logic.

The tools are what you would expect. Execute a command, read a file, write a file. I drew inspiration from how Claude Code structures its tool set. It is a simple and effective model. I also added a browser tool, built as a separate Elixir package called :browse, which can drive a web browser so the agent can navigate and extract information from the web. I even built a variant using the Servo engine for lightweight rendering.

What makes this feel good in Elixir is how naturally the pieces compose. A GenServer for the agent. Adapters for LLM providers. Behaviours for tools. Telemetry for observability. These are all patterns the ecosystem already has strong conventions for. You are not fighting the language to build this; you are leaning into it.

Connecting the layers

Here is where it gets interesting. The agent itself needs to run somewhere, and the somewhere matters. If you are going to clone a repository, run builds, execute tests, you want that happening in a sandbox, not on whatever machine is hosting the agent process. So the architecture has two layers of remote execution. The agent logic runs as an Elixir process, possibly on our infrastructure. The actual work, the file operations, the shell commands, happen inside a sandbox provisioned through Terrarium.

From the developer's perspective, it should feel like the agent is just doing its thing. You give it a task, it reports back when it is done. But behind the scenes, it spun up a sandbox, cloned the repository, did its work, and cleaned up. The sandbox is gone. The only thing that remains is the result.

The primitives that Erlang and Elixir give you make this easy to model. Processes, message passing, supervision trees. You can represent the entire lifecycle of an agent session as a supervised process tree that starts, does work, and shuts down cleanly. If something crashes, the supervisor handles it. If the sandbox provider has an issue, the adapter can retry or fail gracefully. All of this composes in ways that feel natural rather than bolted on.

Toward a workflow language

Once these building blocks are in place, something else starts to become possible. Right now, you interact with an agent by giving it a prompt. That works for ad hoc tasks, but what we are building toward at Tuist is not ad hoc. We want workflows that run in response to signals. When a flaky test is detected, run this. When build times regress past a threshold, investigate that. When a new dependency is added, check its impact.

This is where I want to explore something more structured. A way to describe productivity workflows that live in the repository, right next to the code they care about. Something that combines deterministic steps with non-deterministic ones. A pipeline where some steps are plain shell commands and others are prompts that an agent reasons through.

If you think about it, CI pipelines are the closest thing we have to this today. A sequence of deterministic steps triggered by a git event. What I am imagining is that concept extended in two directions: adding non-deterministic steps powered by an agent, and expanding the set of triggers beyond git events to include signals from build telemetry, test results, and other data we already collect.

Elixir is particularly well suited for this because of macros. Macros in Elixir let you build expressive DSLs that are still just Elixir under the hood. You get the readability of a declarative language with the full power of a general-purpose one. I have not landed on the exact API yet, but the idea is that you would describe a workflow in an Elixir script, and the system would interpret and execute it. No YAML. I have seen implementations of similar concepts using YAML, and I think they always end up fighting the format. YAML is fine for static configuration, but the moment you need conditionals, loops, or any kind of dynamic behavior, it becomes painful. Elixir scripts can be evaluated at runtime, which gives us a much more natural foundation.

Putting it all together

What excites me about all of this is how the pieces connect. We have the data from builds and test runs. We have the sandbox infrastructure to give agents a safe place to work. We have the agent framework to orchestrate reasoning and tool use. And soon, we will have a way to describe workflows that tie it all together.

The vision is that Tuist becomes something that does not just observe your development workflow but actively participates in improving it. Not by writing your features for you, that is what coding agents are for, but by maintaining the health and speed of everything around the code. The plumbing. The infrastructure. The things that a platform team would handle if you had one.

I will share more as these pieces mature. For now, the foundations are coming together, and the thing I keep coming back to is how well Elixir fits this problem space. The concurrency model, the process architecture, the metaprogramming capabilities. It feels like the right tool for building the kind of system where agents, sandboxes, and workflows all need to work together reliably. I am glad we bet on it years ago when we started building the Tuist server.

But I think the companies that are positioned to build something truly great are the ones that go beyond that loop. The ones that create spaces where people can share their needs, their frustrations, their ideas. Not just customers. Not just employees. Anyone.

The space before the product

Open source companies, or companies that operate in the open more broadly, have an interesting advantage here. They usually start by building the space. The community. The culture of sharing. Before they even have a product worth paying for, they have people showing up and contributing ideas, reporting problems, suggesting directions. People get used to participating. It becomes natural.

What's beautiful about this is that the pool of ideas is no longer limited to who you hired or who signed a contract. You open yourself to a diversity of perspectives that you could never assemble internally. The people in your community come from different industries, different countries, different problem spaces. They see things you don't. They need things you haven't imagined. And if you've built the right kind of space, they tell you about it.

This is something we experience at Tuist all the time. Someone shows up and contributes a feature we never would have prioritized. Someone reports a bug in a workflow we didn't know existed. Someone translates part of our dashboard into a language we don't speak. These things happen because the door is open.

The myopia of pure monetization

Here is where it gets interesting for me. If your company exists to make money, and most companies do, capitalism has a way of narrowing your vision. The pressure from investors, the need for hyper-growth, the quarterly targets, all of it pushes you toward capitalizing on everything you can. Every interaction becomes a potential transaction. Every feature becomes a pricing lever.

At some point, it stops being about what your people need and starts being about what you need. And what you usually need is growth that satisfies the expectations you set with your investors. The product becomes a vehicle for revenue extraction rather than a tool that genuinely serves people.

I think this is where a lot of companies lose the plot. They build free trials and gated features and sales funnels, and they optimize every step of the conversion pipeline. But the only input they accept is from people who are already paying or who might pay soon. Everyone else is noise.

And that means they are missing out on the most creative, most unexpected, most valuable ideas. Because those ideas often come from people who have no commercial relationship with you at all. They come from someone who stumbled into your community because they were curious. From someone in a completely different field who saw an interesting parallel. From someone who just wanted to help because they believe in what you're doing.

What you get back

I'll be honest, it feels odd at first. Doing something and not expecting money back. Building something and giving it away. Investing time in people who may never become customers. It goes against everything the business world tells you to do.

But I think there is something powerful that happens when you allow for a different kind of exchange. What you get back is not money. It's ideas. It's bugs that would never have been reported otherwise. It's people going out into the world and sharing how happy they are using your tool. It's someone writing about you not because you paid them, but because they genuinely care.

None of this is directly measurable. You can't put it on a dashboard and say "this contributed X dollars to revenue." You can't attribute it to a marketing campaign. But it compounds. It compounds in ways that are hard to see in the short term but become undeniable over time. The trust builds. The community grows. The ideas keep flowing. And when you finally do build something worth paying for, you have an audience that already believes in you.

The ceiling problem

When the only input into your company comes through your customers and your employees, you have a ceiling. You might not feel it right away. The ideas might be good enough for a while. But over time, the pool gets shallow. You start telling the same story to your investors about increasing value for existing customers. You optimize what you have instead of imagining what you could have.

And then one day you need to expand into a new market, and you realize you don't have the people. You don't have the community. You don't have the go-to-market. Because you spent years building walls instead of doors.

I think people say that open source is riskier than ever, especially now with AI making it cheaper to replicate software. But I actually think it's more powerful than ever. Because through communities and people putting creative energy into different problem spaces, new business ideas emerge. Ideas you could never have generated internally. If you are completely closed, you are betting that the smartest people in the room are already in the room. And that's rarely true.

A different kind of company

I'm not saying you can disregard money entirely. There are people to pay, services to run, infrastructure to maintain. A company needs revenue to survive. But when every interaction is purely a monetary transaction, when you can't invest in something unless you can immediately capitalize on it, you close yourself off from the most interesting possibilities.

The free trial model, the gated feature model, the "talk to sales" model, they all assume that the only valuable exchange is a financial one. I think that assumption is wrong. And I think the companies that challenge it, that find a healthy balance between commercial sustainability and genuine openness, are the ones that will build the most creative, most innovative, most lasting products.

This is something I keep noticing. And it makes me wonder why more companies don't see it.

The pieces are there. The communities are willing. The ideas are waiting. You just have to be open enough to receive them.

The issue is global resources. Ports, for instance. We run more than one server locally, the main Phoenix application, a local S3 server, and a few other services. Each of them needs its own port. And then there are database names in PostgreSQL and ClickHouse. All of these are named, and if two clones try to use the same ports and database names, things break in confusing ways. You end up with one clone's server stepping on another's data, or port conflicts that force you to hunt down which process is holding what.

The idea

We wanted a way to scope each clone to its own set of ports and database names. No manual configuration, no remembering to change environment variables when switching between clones. It should just work.

The solution we came up with uses mise. In our mise.toml, we source a shell script that lazily creates a small piece of state in the repository:

[env]
    _.source = "{{config_root}}/mise/utilities/dev_instance_env.sh"

The script checks for a file called .tuist-dev-instance at the repository root. If it does not exist, it generates a random number between 100 and 999 and writes it there. If it already exists, it reads the number back. The file is in .gitignore, so each clone gets its own.

suffix="$(ensure_suffix)"

export TUIST_DEV_INSTANCE="${suffix}"
export TUIST_SERVER_PORT="$((8080 + suffix))"
export TUIST_SERVER_URL="http://localhost:${TUIST_SERVER_PORT}"
export TUIST_SERVER_POSTGRES_DB="tuist_development_${suffix}"
export TUIST_CACHE_PORT="$((8087 + suffix))"
export TUIST_MINIO_API_PORT="$((9095 + suffix))"

That is it. Every port becomes a base port plus the suffix. Every database name gets the suffix appended. The probability of two clones picking the same random number is low enough that in practice it never happens.

Why it works

The beauty of this approach is that it requires zero thought from the developer. You clone the repository, you run mise install, you start the server, and everything just works. The first time mise activates, it sources the script, the script generates the suffix, and from that point on every environment variable is scoped to that clone.

In my case, I have six clones of Tuist on my machine. I can have six Phoenix applications running simultaneously, each with its own ports and its own databases, completely unaware of each other. There is no coordination needed. No shared configuration file to update. No "make sure you change the port before starting."

The environment variables flow naturally into the application configuration. In runtime.exs, the Phoenix server reads the port from the environment:

port =
  if env == :dev do
    String.to_integer(System.get_env("TUIST_SERVER_PORT") || "8080")
  else
    8080
  end

And the same pattern applies to test databases, storage directories, and any other resource that needs to be isolated.

The small details

A few things that make this work smoothly in practice. The suffix is validated to be a number between 1 and 999, so the port ranges stay within reasonable bounds. You can also override it by setting TUIST_DEV_INSTANCE as an environment variable, which is useful if you want deterministic values in CI or for debugging. And the script is careful about shell compatibility, working in both Bash and Zsh.

If you are dealing with something similar, consider giving this pattern a try. It is simple, and it works.

The granularity of billing

Our industry has a well-known preference for subscriptions over single payments. But it goes further than that. Over time, the unit of billing has become more and more granular. We went from annual licenses to monthly subscriptions to per-seat pricing, and now we are seeing models built around tokens, compute minutes, and individual API calls. There is a constant search for the smallest possible unit of value that can be metered and charged for.

I understand this from a business perspective. If you can identify a granular unit that maps to usage, you can build a pricing model that scales with your customers. But sometimes this search for the perfect billing unit leads to models that feel very forced. And I think one area where this is happening right now is the push to sell cloud development environments as the place where coding should happen.

The three environments

For a very long time, development has happened across three environments. Your local machine, where you write and test code. CI, where changes get integrated and validated. And production, where the software actually runs. Each one has different requirements. Your local machine needs a lot of CPU and memory because you are doing compilations, running tests, switching branches, juggling tools. Production servers mostly handle I/O, so unless the workload is very compute-intensive or very critical, they do not need the same kind of raw power. CI sits somewhere in between, optimized for throughput and parallelism.

This model has worked well for decades. But some time ago, a new idea started gaining traction: what if coding did not happen locally at all? What if there was a fourth environment, a remote machine where the development itself takes place?

The idea that keeps coming back

The first serious attempt at this that I remember was Gitpod. Then came GitHub Codespaces. The pitch was compelling on paper. You no longer code on your machine. You code on a remote server, and the browser is the interface to that environment. It helped that VS Code was designed to be embeddable on the web, so you could get a familiar editor experience running entirely in the browser.

The promise was appealing. You have a terminal, you have your files, you can browse them, you can run the server, connect to it. It all works. And from a business perspective, it is elegant. You can monetize as many minutes as the developer uses. On top of that, you can layer features that enterprises care about: auditing, telemetry, network firewalls, visibility into outgoing connections, security controls. It sounds like a perfect product.

But it never quite worked. Shopify spent years trying to enable a system like this for their developers and eventually pulled back. They recently rebranded the effort into something new, and while we do not know all the details, the fact that it needed a reinvention suggests something fundamental was not clicking.

The portability problem

I think all of these attempts missed a very important detail. You can port the editor. You can have a VS Code or VS Code-like interface in the browser. You can provide a terminal. You can provide the code. You can give people everything that looks like a development environment. But there is one thing that is not portable: your preferences, your tools, your entire workflow.

As a developer, I have accumulated years of configuration. My shell setup, my dotfiles, my CLI tools, my editor plugins, the way I have things wired together. And increasingly, things like MCP servers and other integrations that connect my tools to external services. None of that travels with you to a remote environment. You can bring some of it, but never all of it. The moment you find yourself jumping between the remote environment and your local machine because something is missing, that is when you say "forget it, I would rather do everything locally where I know I have everything and just push when I am done."

This is the fundamental tension. These environments can replicate the visible parts of development, the editor, the terminal, the file system. But they cannot replicate the invisible parts, the accumulated workflow that each developer builds over years. And it is the invisible parts that make developers productive.

The sandbox rush

What I see happening now is a variation of the same theme. There are many companies providing sandbox environments, containers where code can run in isolation. And they need to sell them. Some of them raised money on the premise that agentic workflows would need sandboxes, that AI agents would need somewhere to execute code, and that this would be the next big infrastructure market.

I get it. The logic makes sense on a pitch deck. But I think the long-term picture is less clear than it seems. I do not think companies building agentic workflows will rely on third-party sandboxes forever. If some are using them today, it is because they need to move fast and would rather buy a solution than build one. That is a reasonable short-term decision. But sandboxes are not a particularly defensible business. The technology is well understood. It can get commoditized quickly. And the companies with the most resources to build agents, like OpenAI and Anthropic, have every incentive and every capability to run their own infrastructure. What would prevent them from deploying their own sandboxes? Nothing, really.

So if you are building a sandbox company, you need to jump to something else quickly, something more creative, something harder to replicate. Otherwise you end up competing on price for a commodity.

Where is the innovation?

This is the part that makes me a bit sad, honestly. I was watching a demo the other day where someone showed a browser-based environment, spun up a container, compiled some code, and ran it. And I thought, "So what?" The capabilities we have today are genuinely amazing. Large language models can reason about code, suggest changes, catch bugs, write tests. The foundational infrastructure for running code in the cloud is solid and getting cheaper. All the pieces are there for something truly creative to emerge.

And yet, a lot of what I see is just repackaging the same cloud development environment idea with a new label. New branding, same concept. I would love to see more ambition.

The places where I do see genuinely interesting ideas are products like Codex and Claude Code. The idea that you start coding locally, or even from your phone, and the session continues elsewhere. That there is a seamless transition from one context to another. Sure, I do not see myself doing that for every single task, but for debugging an issue, or having a conversation about something with the full context of the codebase, that can be incredibly useful.

But this kind of experience requires investing in user-facing software. A polished desktop app, a mobile client, a thoughtful interface that makes the transition feel natural. These are hard things to build, and they require a very different set of skills than spinning up containers. The sandbox companies are not going to invest there. They end up in this awkward position where they need to sell their infrastructure, they want to sell it because that is the promise they made to their investors, but the real innovation is happening at a layer above them that they do not control.

Agents change the question

The funny thing is that I think agents are quietly changing the entire question. The old framing was "where does the developer code?" and the answer was supposed to be "in our cloud environment." But agents do not need a cloud IDE. They do not need VS Code in the browser. They do not care about your font size or your color scheme. They need a terminal, access to the codebase, and the ability to run commands. The environment requirements for an agent are radically simpler than for a human developer.

This means the portability problem that killed cloud development environments for humans does not apply in the same way to agents. An agent does not have twenty years of dotfiles and shell customizations. It does not need its favorite editor plugins. It just needs to execute.

And this is where things get interesting, because if the agent can work in any environment, then the value is not in the environment. It is in everything else. The toolchain optimizations that make the agent's work faster. The caching layer that prevents redundant builds. The intelligence that knows what to skip and what to rebuild. The seamless experience that lets a developer kick off an agent session from anywhere and get results back without thinking about where the computation happened.

The companies that understand this will build at the layer where the real value lives. The ones that are stuck trying to sell sandboxes will keep looking for someone to buy them.

Building means, not ends

At Tuist, we think about this a lot. We need compute capabilities, and we are building them. But compute is not what we are selling. It is a means to an end. The end is making developers and their tools faster, wherever they happen to be running. We want to build these capabilities and share them with the community, because the sandbox itself was never the interesting problem. The interesting problem is what you do with it.

I would love to see more of the industry think this way. Less rushing to monetize infrastructure for the sake of monetizing it, and more thinking about what genuinely new experiences become possible when you combine powerful models with fast toolchains and seamless transitions between environments. The pieces are all there. We just need the appetite to put them together in ways that actually surprise people.

This is surprisingly common. Unless you operate in a very competitive market where you do not dominate, where saving a minute or even seconds translates into a real edge, productivity tends to sit somewhere near the bottom of the priority list. People acknowledge it, nod when you bring it up, and then move on to the next feature request.

For us at Tuist, this has always been a challenge. If organizations do not appreciate the problem, they do not see the value in investing in a solution. And if they do not see the value, they certainly do not see the point in paying for one.

The reflex to throw resources at it

When organizations finally do start feeling the pain, their first instinct is almost always the same: throw resources at it. Hire more engineers. Buy faster laptops. Provision beefier CI machines. These are tangible, visible investments. You can point at a new M4 Max sitting on someone's desk and feel like you did something.

There is actually a well-known pattern behind this. Behavioral economists call it the tangibility bias: people systematically overvalue things they can see and touch relative to intangible alternatives. A new machine feels like progress. A software tool that makes all your existing machines faster feels like an expense. Organizations also tend to prefer capital expenditures over operational ones, because buying hardware looks like growth on a balance sheet, while paying for a tool that optimizes what you already have looks like admitting something is broken.

The irony is hard to miss. These same organizations will happily spend hundreds of thousands on new hires and faster compute, but if you tell them "I can make everything you already have significantly faster," they think it is too expensive. They want speed, but only if it comes in a form they can physically see.

Agents are changing the equation

Here is where things get interesting. I think coding agents are quietly reshaping how people think about this.

When you use a coding agent, you get used to a rhythm: you prompt, you wait for inference, the agent does its work, you review. The total cycle time is a combination of inference time and toolchain time. The time the model spends thinking, plus the time it takes to compile, run tests, lint, or whatever else the toolchain demands.

If you have used agents with languages like Python or JavaScript, you know that the inference piece dominates the cycle. The toolchain is fast. Feedback comes quickly. The experience feels fluid.

Now try that same workflow with a compiled language. Swift with Xcode. Kotlin or Java with Gradle. Suddenly, everything feels painfully slow. Not because the agent is slower, but because the toolchain adds minutes where you used to wait seconds. And because you have already experienced what fast feels like with other languages, your tolerance has shifted. What was once an acceptable wait now feels broken.

This is the shift I find fascinating. Agents are training developers to expect faster feedback loops. And once that expectation is set, it is very hard to go back. The frustration compounds because you know the slowness is not fundamental. It is not physics. It is the toolchain. It is fixable.

Two layers of the solution

Once you accept that the toolchain is the bottleneck, there are really two layers where you can attack the problem.

The first layer is compute. Faster CI machines, faster laptops, faster cloud environments for agents. This is the obvious one, and it works up to a point. But it has a ceiling. You can buy the most powerful machine available and your build still takes however long it takes to recompile everything from scratch. On top of that, compute resources are usually shared. You want good utilization to keep costs reasonable, which means resource contention, which means you cannot just throw infinite cores at the problem.

The second layer is the toolchain runtime. This is where you cache build artifacts so you never rebuild what has not changed. Where you identify and fix flaky tests so agents stop retrying them endlessly. Where you eliminate redundant work in the build graph. Where you are selective about what gets compiled and what gets skipped.

This second layer is more powerful. It is cheaper. It is more flexible. You can take it anywhere because it is not coupled to a particular machine or environment. It works on your laptop, on CI, in whatever sandbox an agent is running in. It solves the problem at a fundamental level rather than throwing hardware at symptoms.

The coupling problem

This brings me to something I have been thinking about a lot. Many companies that provide CI or development environments bundle their runtime optimizations with their compute. They offer caching, build optimization, test insights, and on paper you can plug them into other environments too. But the system design is deeply coupled to their own infrastructure. When you try to use it outside of their environment, the latency is high, the effectiveness drops, and the experience is nothing like what they advertise. Sure, you can technically plug it in. But the plug does not deliver what you would expect as a developer.

I understand why they design it this way. Compute is where the money is. You monetize CPU minutes, memory, storage. Why would you optimize for environments you do not control?

But I think this model is heading for trouble. The future of compute is fragmented by design. OpenAI runs Codex in its own containers. Anthropic will have its own agent environments. Linear is already running agentic workflows in their own infrastructure. Sentry is too. Every tool in the chain wants to own execution. No single player is going to control where all development happens.

If your runtime optimizations only work well in your environment, you are betting on a future where you are the only environment. That is an unrealistic bet. And from the other side, why would OpenAI or Anthropic give away their compute revenue to a third-party environment provider? They have every incentive to run things themselves.

The clean build problem

There is another dimension to this fragmentation that does not get enough attention: incremental builds. On a developer's laptop, builds are incremental by default. You change a file, the compiler rebuilds only what depends on it. This is fast because state persists between builds. Your derived data, your intermediate artifacts, they are all sitting there from the last run.

But when Codex compiles your Swift project in a fresh container, or when a CI runner picks up a job on a clean machine, that state is gone. Every build is a clean build. Everything gets recompiled from scratch. This is where the toolchain slowness becomes most brutal, and it is exactly the environment where agents are increasingly doing their work.

The solution is to bring incrementality across environments. Not just within a single machine, but across local development, CI, and agentic workflows. When an agent runs a build in a remote sandbox, it should be able to pull cached artifacts from a previous build, whether that build happened on your laptop, on CI, or in another agent session. The build should feel incremental even when the environment is ephemeral.

This is not a simple problem to solve. It requires a deep and complex system design for the cache infrastructure. You need content-addressable storage, fine-grained dependency tracking, and a distributed system that can serve artifacts with low latency from wherever the build is happening. It also requires a decentralized architecture where pieces of the system can escape a centralized model and be brought closer to the compute. Sometimes that means a cache node in the same data center as your CI runners. Sometimes it means a node in your office, close to where your team develops every day. The system needs to support all of these topologies without forcing you into a single deployment model.

Going deep where others do not

This is where I think Tuist can bring something genuinely different to the table. As Peter Steinberger once said, doing interesting things that are hard is what positions you strongly as a business. And the runtime optimization space is exactly that: interesting, hard, and largely ignored.

There are some players focused on specific ecosystems, like Bazel. Gradle is expanding beyond its own build system with Develocity. CI companies are adding value layers on top of their runners. But most of these efforts are shallow, or tightly coupled to a specific environment, or both.

What we are doing at Tuist is going deep into every ecosystem we touch. Not surface-level integrations. Deep understanding of how each toolchain works, where it breaks, what makes it slow, and how to fix it. We cross-pollinate ideas across ecosystems, bringing optimizations from one world into another. We expose APIs for everything. We invest in documentation and developer resources. We use the tools ourselves, every single day.

The vision is to become your platform team, offered as a service. We want to get to a point where we actively monitor your projects, your workflows, your setup, and proactively make sure things are fast. Whether you are coding locally, asking an agent to do it on your machine, or running that agent remotely in some cloud sandbox. The optimizations travel with your project, not with your infrastructure.

Building the network

If I draw a connection to another company, I think about Cloudflare and how they solved the problem of bringing computation close to where it is needed. Their Workers run at the edge, close to the user making the HTTP request. The function does not live in a single data center waiting for traffic to arrive. It lives everywhere, and the system routes you to the nearest one. That model is what inspires how we think about cache infrastructure at Tuist, but applied to development. Instead of running functions close to your end users, we run cache nodes close to where the development is happening. Close to your CI runners. Close to the agent sandbox. Close to your office.

This requires a different kind of infrastructure. Global. Low-latency. Decentralized by design. The system needs to let organizations bring cache nodes into their own environments when that is what makes sense. Not every team wants their build artifacts traveling across the internet to a centralized service. Some want a node in their own network, in their own data center, or even in their office. The flexibility to support that, while still providing a managed experience for teams that do not want to think about infrastructure, is what makes this problem hard and interesting.

But the pieces are coming together. Telemetry to understand what is actually slow. Cache infrastructure to eliminate redundant work. Deep toolchain integration to know what to cache, what to skip, and what needs to change in your project. Sometimes the optimization is not just adding a cache. Sometimes it is telling you that a specific configuration in your project is causing unnecessary recompilation, or that a dependency is pulling in work you do not need. All of that requires the kind of depth that you can only build by being genuinely obsessed with the problem.

The window is open

What excites me most about this moment is the convergence. Agents are shifting developer tolerance toward faster feedback. Compute is fragmenting across providers. And the runtime layer, the layer that actually determines how fast your tools run regardless of where they run, is wide open.

This is the ground we are building on at Tuist. Not competing on compute. Not locking value into a single environment. Going deep into the toolchain, building the platform team that every organization needs but few can afford, and making it work everywhere development happens.

The window for this was hard to open before. It took a lot of convincing, a lot of explaining why productivity matters, a lot of fighting the tangibility bias. But agents are opening it for us, one frustrated developer at a time.

I like doing some hacking on Sunday afternoons, so I thought it'd be a good exercise to build a framework for Elixir learning from ideas from Pi. The result of this work is Helmsman, an Elixir framework for building agents. I put a strong focus on aligning the APIs with Elixir patterns and conventions, and the concepts with LLM-based agentic workflows. Here's an example of how to use it:

defmodule MyApp.CodingAgent do
  use Helmsman

  @impl true
  def tools do
    Helmsman.Tools.coding_tools()
  end
end

{:ok, agent} = MyApp.CodingAgent.start_link(
  api_key: System.get_env("ANTHROPIC_API_KEY"),
  system_prompt: """
  You are an expert software engineer.
  Write clean, well-documented code.
  Always run tests after making changes.
  """
)

Helmsman.stream(agent, "Add documentation to the counter module")
|> Stream.each(fn
  {:text, chunk} -> IO.write(chunk)
  {:tool_call, name, _id, _args} -> IO.puts("\n📦 Using tool: #{name}")
  {:tool_result, _id, result} -> IO.puts("   Result: #{inspect(result)}")
  :done -> IO.puts("\n✅ Done!")
  _ -> :ok
end)
|> Stream.run()

We include a set of tools that you can override or extend to customize the behavior of your agent. For example, this is how you define a custom tool:

defmodule MyApp.Tools.Weather do
  use Helmsman.Tool

  @impl true
  def name, do: "get_weather"

  @impl true
  def description, do: "Gets the current weather for a location"

  @impl true
  def parameters do
    %{
      type: "object",
      properties: %{
        location: %{type: "string", description: "City name"}
      },
      required: ["location"]
    }
  end

  @impl true
  def call(%{"location" => location}, _context) do
    case WeatherAPI.get(location) do
      {:ok, data} -> {:ok, "Temperature: #{data.temp}°F"}
      {:error, reason} -> {:error, reason}
    end
  end
end

And building on Erlang's awesomeness, Helmsman comes with telemetry events that you can use to track agent behavior:

:telemetry.attach_many(
  "my-handler",
  [
    [:helmsman, :agent, :start],
    [:helmsman, :agent, :stop],
    [:helmsman, :tool_call, :start],
    [:helmsman, :tool_call, :stop]
  ],
  fn event, measurements, metadata, _config ->
    Logger.info("#{inspect(event)}: #{inspect(measurements)}")
  end,
  nil
)

If you want to tinker with it, you can use the livebook included in the repository. Next weekend, I plan to start leveraging this in another experiment of mine where I'm exploring what version control systems for the modern patterns that are emerging might look like. I'm calling it Micelio, and you'll likely hear more from me talking about it.

I think that's a very narrow way of looking at it, and I think it misses the point entirely.

The recipe and the chef

There's an analogy I keep coming back to. If you search the internet right now, you can find recipes for almost anything. The best restaurants in the world, the dishes that people travel thousands of kilometers to eat, many of those recipes are out there, publicly available. You could technically replicate them at home. But if you try, you'll quickly realize that having the recipe is not the same as having the craft.

A chef who has spent years working with ingredients, who understands the subtleties of heat and timing and texture, who loves the act of cooking itself, will always produce something different from someone following the same instructions for the first time. The recipe is open. The magic is in the hands.

I think about this a lot in the context of building software. There's this pervasive fear in the industry around sharing. Around being open. Companies treat their code, their ideas, their roadmaps like they are the entirety of their value. As if showing someone what you're building means they can instantly take your place. But the truth is, when you're building something with genuine passion and deep understanding of the problem, openness doesn't weaken you. It strengthens you. Because the value was never just in the code. It's in the obsession, the taste, the accumulated understanding of the problem space that took years to develop.

What I see when I look around

When I look around the industry, what I feel most is fear. Fear of sharing too much. Fear that someone will copy your feature, your architecture, your positioning. Companies build in private for weeks or months, then task someone with creating noise around the announcement, hoping the algorithms will carry the signal. And it's getting harder and harder to make that work. You can't just publish a blog post and expect it to spread. The platforms don't reward that kind of content anymore. Search is less reliable as a discovery channel. The old playbook is breaking down.

And then there are the blog posts themselves. I came across one this morning from an engineering leader at a company, and I could tell immediately it was generated by AI. Not because using AI is inherently wrong, but because no one had bothered to read it. The post said nothing. It had no point of view, no depth, no personality. It was content for the sake of content, published so that a checkbox could be ticked somewhere.

When I read something like that, what I take away is that the people behind that company are not deeply connected to what they're building. Because if you love what you do, you don't put out something empty and call it done. You care about every word because every word represents who you are and what you stand for.

The long game of trust

I believe the only way to genuinely reach developers is through trust. And trust takes time. It takes consistency. It takes showing up, over and over, with substance. Not fireworks. Not growth hacks. Substance.

At Tuist, we've been doing this for years. We share what we're building, what we're thinking about, what problems we're trying to solve. Not in polished marketing campaigns, but as part of how we work. Our code is open. Our design process is open. Our technical decisions are open. Support happens in public. We're starting to have our marketing conversations in public too, making videos of the discussions, the scripting process, all of it. I don't know if people will participate, but the invitation is there. If someone wants to throw in their ideas, why not?

This is what resonates with developers. When they see a team that is contributing to making things better, that has a clear vision, well articulated, that they can connect with, something clicks. It's not a transaction. It's a relationship built on shared values. A developer who has been using Tuist for Xcode, who has watched us share our thinking for years, when we announce that we're expanding to Gradle, there's a natural interest that emerges. Not because of an ad. Because of trust earned over time through openness.

I don't think there's another way to build this with developers. You have to be a community builder. You have to do the work in the open. You have to make people feel like they're part of something, not just customers of something.

The balance

I should say that openness doesn't mean naivety. There's a balance to find, especially when it comes to licensing and business models. Cloud providers can take your open source project and sell it as a managed service on their infrastructure, and competing with that is nearly impossible. If your audience is developers and there's no real incentive to pay you, many will self-host even when it's painful to do so.

This is something that continuously evolves at Tuist. We haven't fully settled on our licensing for the server side. In fact, our goal is to be fully open source when most of the value lives in the infrastructure itself, which is where the real pain is. There's so much accidental complexity in running and managing that infrastructure, complexity we can't fully eliminate, that most people genuinely don't want to deal with it themselves. And the bigger the market becomes, the more attractive this model gets.

You need to understand who you sell to and who might want to sell what you've built. That awareness shapes your licensing decisions, your business model, the way you think about where the value lies. It's not something you figure out once and forget. It's a continuous conversation.

Building in public is building with others

One thing I've noticed is that when you build in the open, you expand your pool of ideas dramatically. When we discussed publicly that we were going to introduce compute as an internal primitive, someone told me it was a bad idea. I didn't agree, but the conversation itself was valuable. When you share your thinking openly, you're socializing ideas. You don't need a big launch event. You keep talking about what you're doing, what you're considering, what you're solving. And slowly, people start to engage.

On our platform, people contribute things like new languages for the dashboard. When you invite contributions, you get a design surface that accounts for a diversity of ideas and needs you could never imagine on your own. Otherwise you're limited to the ideas of your employees and your existing customers, and that's it. The pool becomes the world versus you and your small team. And the world, as it turns out, is more creative.

This is precisely what companies tend to lose as they grow and focus narrows to meeting investors' expectations. Their websites fill up with webinars, demos, contact-sales buttons, and factory-produced blog posts. The craft disappears. The personality fades. And they wonder why developers don't trust them.

This is what we believe

I know that some people look at how we operate and feel uncomfortable. Some have tried to dismiss our approach as a trend, or put it down as unsustainable. We couldn't care less. This is not a posture we adopted because it was convenient. This is who we are.

We believe that openness builds the kind of trust that marketing budgets can't buy. We believe that the best products come from people who love what they do and aren't afraid to show their work. We believe that inviting the world into your process makes the result better, not worse. And we believe that this is the path to building something that lasts, a company we can be proud of, with a community of people who believe in the same things we do.

The recipe is out there. But we're the chefs. And we love what we cook.

What's remarkable is how rare this is. And how difficult it is to find people who share your obsession for the same problem.

I think about this all the time in the context of building Tuist. If you want to build something that truly stands out, something that brings something unique to the world, you need a deep love for the problem you're solving. Not a passing interest. Not a strategic bet. Love. The kind that makes you willing to go deeper than anyone else, to sit with complexity longer than is comfortable, to resist the temptation of doing what everyone else is doing just because it looks like that's where the opportunity is.

Passion for problems vs. passion for business

When I look around at tools and companies in our space, I notice that the gravitational pull of business can be very strong. And look, you need that component. You need to know how to sell what you're building. You need revenue. You need sustainability. But I think when the business side takes over, something subtle happens to the products that come out of it.

They start looking the same. Same design language. Same feature sets. Same concepts. Same positioning. It's not that the people building them don't care. I think most founders do care. But the pressure to grow, to compete, to ship what the market expects, can quietly push the product toward a kind of sameness. Sometimes you fall so in love with an idea that feels unique but isn't, and you don't realize you're standing in a crowded room full of people saying the same thing with slightly different words.

A good example of this dynamic is the compute space right now. Compute for CI. Compute for agents. Compute for whatever comes next. There's a natural tendency to look at what's gaining traction and move toward it. Then capital flows in, and the incentive becomes to do the same thing at scale as fast as possible. I don't think this is necessarily wrong. But I do think it creates a landscape where the products can end up feeling similar. They solve real technical challenges, but they can lose some of that personality along the way. That sense that someone poured their particular obsession into every detail.

What personality actually means

When I say personality, I mean something very specific. I mean how you feel when you use a product. How you interface with the problem domain. How simple it is. How enjoyable it is. Whether it evokes something in you, some kind of emotion, when you interact with it.

There isn't a better example of this than 37signals. Every product they build, every problem space they enter, they do it differently. There's a craft and a point of view that's unmistakable. You use their products and you feel something. They're not just functional, they're opinionated in a way that feels alive.

Shopify does this too. One thing I took from my time there is how deeply they understand their business. They don't just build features for e-commerce. They study e-commerce so well that they can model it properly, and from that deep understanding they build domain-specific building blocks that enable creative solutions. When a new technology with new capabilities arrives, like AI, they jump into exploring what that means for their product space. They don't just bolt features on. They think deeply about what the technology enables for the people they serve, because they understand the domain well enough to see what others can't.

Apple has done this for decades. Their products don't just work. They feel considered. They feel like someone cared about every detail, every transition, every moment of interaction. That investment in how something feels is not superficial. It's foundational to why people love using their products.

Building with feeling

At Tuist, we're trying to do the same. We look around. We know what's happening in our space. But we try to be different. We invest in areas where people don't usually invest: in making the product feel alive through animations, through interactions, through videos, so that when you use it, something is evoked. Not just utility. Emotion. We want ours to feel like it was made by people who care, because it was.

We're also open source, which we think is unique and important in how it shapes our relationship with the people who use what we build.

We design everything so that the product is layered. People can choose the layer they want and plug it into their system. We look at every single detail. How we name things. How the experience feels when using the CLI. How the dashboard communicates information. We care about the small things because we believe they add up to something meaningful.

And critically, we use the tool ourselves. Not just passively, but we are constantly looking for ways to use it more. We look at our own setup and ask ourselves where the friction is, where we can push Tuist further into our own workflow. We are developers. We develop software every day, and we have our own productivity issues. So we solve them for ourselves first, and that becomes a source of ideas for the product. On top of that, we work very closely with our users. We listen to their problems, we get ideas from the challenges they share with us, and we translate those into solutions that are genuinely useful. When you use a product and it feels broken, you can't help but wonder what would happen if the people building it lived inside it every day. I understand that organizational complexity makes this hard. But for me, it's kind of unthinkable to build something we don't use daily, alongside the people we build it for.

The discomfort of going your own way

Most importantly, we're avoiding jumping into whatever everyone else is jumping into just for the sake of following the crowd. This feels very uncomfortable, I'll be honest. When everyone moves in the same direction, that's where the money flows. And money has a gravitational pull that's hard to resist.

But I also have to say that money tends to have a short-term, short-sighted view of spaces. Capital chases what looks like it's working right now. It rewards speed over depth, imitation over originality, scale over craft. If you want to be a long-term business, which is what we're aiming to do with Tuist, you need to think differently.

Think out of the box, like Apple used to say.

We're going deep into areas like build systems to understand them well. Not superficially. Not just enough to ship a product. Deeply enough that when we intersect that knowledge with AI, we can bring something of real value to companies. Something shaped by our particular obsession with this problem space.

We announced recently that we are going to solve compute. But not compute for the sake of compute. We are building on compute capabilities so that we can enable creative solutions for productivity, which is what we are truly obsessed with solving. From all the learnings we got at Shopify, from making developers productive, from working very close to the tools, from understanding them deeply, we learned that you need to build domain building blocks so that you can model those problem spaces properly. That's what we're doing. We're not entering compute to compete on price or speed. We're entering it because compute is a foundation on top of which we can build something different. It's not that we're the only ones thinking about developer productivity. But we are very obsessed with it, and that obsession, combined with years of working close to the tools, gives us a particular perspective that shapes everything we build.

The bet

This is ultimately a bet.

A bet that obsession matters more than speed. That personality matters more than feature parity. That going deep matters more than going wide. That building something you love using yourself every day produces better outcomes than optimizing for metrics in a pitch deck.

It's not the easy path. It's not the path that gets you the loudest applause or the biggest funding round. But I believe it's the path that leads to products people actually love, companies that actually last, and work that you can actually be proud of.

That's what we're building at Tuist. Not just a product. A point of view.

We started at the roof. Deep integration with the Xcode toolchain, then Gradle, now expanding into more ecosystems. This layer, the toolchain runtime, sits between your project and the infrastructure that builds it. It is the layer where you understand how code gets compiled, linked, tested, and packaged. We did not plan to start there out of some grand architectural vision. We started there because we cared about it. We wanted to make it better. And in doing so, we built a foundation of understanding that now informs everything we do as we work our way down to the rest of the house.

Why the roof first

Starting at the toolchain layer gave us something that most companies in this space lack: depth. Real, technical depth in how build systems work, where they break, and what developers actually experience when things go wrong.

Most companies prefer not to go this deep. They would rather place an abstraction between the technology and the infrastructure. This is why solutions like Docker and Kubernetes exist in the form they do. It is why CI providers settled on the message of "just give us a container and we will run it." The abstraction is convenient. It scales as a product. But it also means you never really understand what is happening inside.

Going deep into toolchains is uncomfortable work. You end up contributing to tools you do not own. You invest time into understanding systems that change under you. You sometimes spend weeks on a problem that benefits an ecosystem but has no direct financial return for your company. This is not the kind of work that looks good on a quarterly report or in a pitch deck.

But it is the kind of work that earns trust. And trust, in developer tooling, is the real currency.

The toolchain layer as a differentiator

I think this is where Tuist can bring something genuinely unique. The way you gain developers' trust is by contributing to the tools they already use. Not by replacing them. Not by wrapping them in a proprietary layer. By understanding them deeply enough to make them better, and then building your product on top of that understanding.

Not many companies are willing to make this investment. It requires an open source mindset, a community mindset, where you accept that some of your work will benefit people who never pay you a cent. That feels irrational if your model is purely transactional. But if you think about it over years rather than quarters, those ecosystems respond. They respond with trust, with adoption, with the kind of organic growth that no growth hack can replicate.

I see so many companies hiring growth hackers and optimizing funnels when the real problem is that developers do not trust them. You cannot shortcut trust by throwing money at it. You can buy awareness, sure. You can manufacture a sense of urgency. But developers remember who showed up to their ecosystem and actually helped versus who showed up with a landing page and a sales pitch.

From the roof to the walls

If the toolchain layer is the roof, the next layer down is observability. This is the part where you look at your project, analyze your build graph, and surface the things that make developers waste time. Flaky tests, redundant dependencies, suboptimal compilation paths. All of this requires telemetry and deep understanding of build and test data.

This is why companies traditionally build platform teams. Someone has to watch the system, understand it, and optimize it. But platform teams are expensive. They require specialized knowledge. And most organizations either cannot afford them or cannot retain the talent.

We think Tuist can be the platform team of the future. A virtual platform team that understands your toolchain, watches your build and test signals, and tells you what to fix. This is not a dashboard with pretty charts. This is the kind of insight that requires understanding the system deeply enough to know what the data means and what to do about it.

As we continue expanding into new ecosystems, this becomes even more relevant. Agents are producing code at a velocity that human developers never reached. More code means more builds. More builds means more opportunities for things to go wrong, to slow down, to waste cycles. The need for a layer that watches, understands, and optimizes is not going away. It is growing.

The foundation: compute and caching

If you keep going down from observability, you reach the foundation of the house: compute and caching. These are the layers that determine how fast things actually run.

There is a growing consensus in the industry that compute matters. And it does. But I think many companies are being a bit myopic about it. They see compute as the whole story. Faster cores, more cores, dedicated machines. It sells well because it is easy to understand. "Your builds are slow? Here, have a faster machine."

The problem is that compute alone has a ceiling. A physical ceiling. You can buy the most powerful machine available and your build still takes however long it takes to compile everything from scratch. No amount of cores can overcome a build graph that is doing unnecessary work.

This is why we believe compute and caching must go together. Caching is what breaks through the compute ceiling. When your build system can pull a pre-compiled artifact from a cache instead of rebuilding it, you shift the bottleneck from CPU to network latency. And network latency is something you can optimize almost without limit if the cache is close enough. This means compute and caching need to be colocated. You cannot have a cache on the other side of the world and expect it to be fast enough. Physics does not care about your product roadmap.

The compute market is going to get very crowded. We already see Daytona, Modal), E2B, and many others. I would not be surprised to see AWS step into this more directly. When you are only selling compute, your differentiation is thin. Someone will always match your specs at a lower price. But when compute is one layer in a full stack that includes deep toolchain understanding, build graph optimization, observability, and colocated caching, the picture changes entirely.

The fragmentation problem

There is another dynamic that worries me about compute. As coding agents become more prevalent, everyone wants to provide their own compute. OpenAI runs Codex in its own containers. CI providers have their runners. Linear might offer compute for development workflows. Every tool in the chain wants to be the one hosting the execution.

This fragmentation is problematic. Each provider optimizes for their own slice of the workflow, and developers end up with their build artifacts scattered across five different systems, none of which talk to each other. It gets even more concerning when you consider how sensitive the data is. Your source code, your credentials, your build outputs. Having all of that spread across multiple compute providers with different security postures is not ideal.

I hope the industry converges on a protocol that separates who needs compute from who provides it. Something that lets you choose your compute provider independently from the tools that orchestrate your work. Without that, we are heading toward a world where every tool is also an infrastructure provider, and the switching costs become unbearable.

The whole house

What I keep coming back to is that you need the whole house. The toolchain layer, the observability layer, the compute, and the caching. Each one is necessary but not sufficient on its own. Fast compute without an optimized build graph is wasteful. An optimized build graph without good caching still hits a ceiling. Caching without proximity to compute is bottlenecked by physics. And none of it matters if you do not understand the toolchain deeply enough to know what to cache, what to skip, and what to rebuild.

We are building all of it. Going deep into the areas where we do not see other companies going deep because they do not see the value. As I said, going deep requires an open mindset where you invest into areas without seeing direct financial returns. That is why it is not attractive to many companies. But in the long term, it compounds. The ecosystems respond. The trust builds. The product gets better because you understand the problem better than anyone else.

This is not the fastest way to build a company. It is not the most capital-efficient path in the short term. But it is the path that leads to something real. Something that developers can rely on because it was built by people who genuinely understand the systems they work with every day.

We started building the house from the roof. Now we are adding the walls, the scaffolding, the foundation. And when the whole thing is standing, it will be standing on a depth of understanding that you cannot buy, you cannot shortcut, and you cannot fake. You can only earn it by doing the work.

It manifests in familiar ways. We convince ourselves that technical excellence is a sufficient ingredient for a sale. We spend months on a rewrite that customers never asked for and will never notice. We fail to recognize where the opportunity for capturing value actually lies, or where to set the right boundaries. We pour ourselves into the work and forget that the work also needs to sustain itself.

Marek and I have been there. More than once. And over time, we have learned the discipline of business engineering. How to balance the love of building with the reality that building needs a foundation underneath it. But that learning process came with its own set of lessons, many of them taught by people who saw our builder instincts and thought they could use them.

The pattern

When you are a small company with strong product instincts, people notice. Some of them genuinely want to collaborate. Others see an opportunity to acquire your capabilities without paying what they are worth.

We have experienced this several times over the years, and each time the playbook was different but the underlying dynamic was the same. Someone sees that you can build, sees that you are small, and assumes that you must need saving. Or funding. Or guidance. Or absorption into something bigger. The assumption is always that your size is a weakness rather than a choice.

One time, a company in our space proposed an integration that was really about folding our work into their platform. When we declined, the conversation shifted to suggesting our project belonged in a foundation. In our experience, foundations rarely solve sustainability. They redistribute responsibility while the project slowly loses momentum. No, thank you.

Another time, someone pitched us on selling the project. In the same conversation, they mentioned a similar acquisition that had ended with the acquired project dying. The subtext was not subtle. Open source was a marketing asset. Companies were financial assets. When the acquisition did not work, the offer became a small monthly payment to promote their tools on our channels. No, thank you. Looking back, we are glad we said no. The values we saw play out after that conversation were not ones we wanted to be associated with.

More recently, someone approached us about "joining forces to build something big." It was unclear what that meant in practice because there was no real structure behind the proposal. What became clear quickly was that they saw open source as a detriment to capturing value rather than a multiplier of it. For us, that is a fundamental misalignment. Open source is not something we do despite the business. It is core to how we build it. We passed. We did not even get to specifics because the conversation made it obvious we were building toward very different things.

What we learned

Throughout all of these conversations, a few things became clear.

We have built an impressive product muscle. Four engineers shipping at a pace that companies with forty times our headcount cannot match. This is a real and valuable capability, and it makes some people uncomfortable. When a small team moves faster than a well-funded one, it raises questions that the well-funded one would rather not answer.

You can build an open source business if you capture value in the right places. The code is partially yours, but not all the value lives in the code. The infrastructure, the expertise, the trust, the service. Those are where sustainable businesses are built. We strongly believe the most enduring companies are open ones. But I understand that openness does not matter if your timeline is short and your goal is an exit.

Some founders are here for value creation. Others are here for value extraction. The equation for the latter is straightforward. Get a round to establish a valuation. Get another round to increase it. Exit. Cash out. Repeat. This is a valid path, but it is a different game than the one we are playing. The problem is when people playing that game try to pull you into it because your capabilities would make their numbers look better.

The quiet advantage

Being in a relatively niche corner of the industry has been a gift. It gives us the space to build a technical and product foundation without too much noise, while maintaining a broad perspective on where the industry is heading. We do not jump into whatever everyone else is jumping into. We watch, we think, we build when the timing is right.

The biggest challenge any company faces is staying innovative. Some do not use their own products. Even the ones that do often lack the muscle for real product innovation. It is rare to find product engineers who cross-pollinate ideas across domains. Even rarer to find makers who are passionate and confident enough about their ideas to talk about them openly, make them contagious, and get other people excited to try them. I consider myself that kind of person, and I have learned to protect that quality instead of letting others diminish it.

We are doing business

So thank you to everyone who approached us. Genuinely. Every conversation taught us something. Every "no" made us more confident in what we are building and why. Every attempt to acquire, absorb, or redirect us made us realize how much we love doing this, and how much we have learned about business since we started.

We are doing business, like everyone else. We have our own ideas, our own pace, our own values. It might feel uncomfortable to see a small company with fewer incentives to align with what others expect of us. But we are going to keep making noise and pursuing what we believe in.

It turns out business is not that hard after all. You just need to know what you are building, why you are building it, and who you are building it for. And then you need to be stubborn enough to keep going when people tell you that you should stop.

We are not stopping.

I think we are watching the same thing happen to software development itself. Coding agents are turning development headless. The action, writing code, compiling, running tests, is being separated from the interface where it used to live: your editor, your terminal, your local machine. And just like every other headless transition before it, this one is going to reshape the entire platform around it.

We tried this before

The idea of moving development off your local machine is not new. Cloud development environments have been around for years. GitPod, Codespaces, various remote desktop solutions. The industry poured real money into making "code from anywhere" a reality. Even Shopify invested years into this before eventually stepping back. The vision was compelling, but the execution never quite landed.

I think the reason is that we were still too dependent on editors whose entire design assumed the action was happening locally. Extensions, language servers, debuggers, terminal integrations. Everything was built around the idea that your machine was both the steering wheel and the engine. Some teams pushed that model impressively far, but it always felt like you were fighting the architecture rather than working with it. And for platforms like Apple's, where the toolchain is tightly coupled to specific hardware and an environment that is costly to provision and run, the friction was even worse.

Cloud development tried to make the editor headless. But the editor did not want to be headless. It was designed around the assumption that it was the center of everything.

Agents made it actually work

Coding agents did not try to make the editor work remotely. They made the editor optional. That is a fundamentally different move.

When you work with a coding agent, the relationship with the editor shifts. You prompt, you wait, you review, you iterate. The editor becomes a place to steer from, not a place where the action happens. That distinction matters more than it might seem at first.

This is exactly what companies like Anthropic and OpenAI are building toward. Claude Code can run headlessly. Codex spins up its own containers. The compute where your code builds and runs is no longer your laptop. It is somewhere else, managed by someone else, and that is fine because your job is to direct the work, not to host it.

Once you accept that separation, a lot of things start falling into place. Your physical machine is no longer a ceiling on how much agentic work you can parallelize. You are not bottlenecked by your CPU, your RAM, or the number of terminal tabs you can keep open. The constraint moves from hardware to orchestration. Development becomes headless, and the head, you, can be anywhere.

Runtime review over code review

When development goes headless, the way we validate work changes too. Code review still matters, but runtime review is becoming the more important feedback loop.

What I mean by runtime review is the ability to see, feel, and interact with the result of the work. Not just reading the diff, but running the thing and experiencing it. This is not a new concept. At Shopify, we had a process called tophat where engineers would spin up a build of someone's branch and test it on a real device before approving. We brought a version of this to Tuist as previews. And now coding agent platforms are building the same idea natively.

When Claude Code introduced previews, I found it entirely expected. If the agent is producing the code, you need a way to validate the output beyond reading lines of text. You need to feel it. In a headless development model, runtime review is the primary interface between you and the work. The code is an implementation detail that the agent manages. What you care about is whether the thing works, whether it feels right, whether it does what you intended.

In some side projects where I experiment with new mental models around how we could work, I ship changes without reading the code at all. I just review the runtime behavior and do periodic sessions to steer the architectural foundations in a good direction. It feels surprisingly natural. I think this is where professional development is heading too. It will just take people time to embrace it.

The forge is the logical next step

Here is where headless development gets really interesting as a platform shift. Once you can spin up a controlled environment from anywhere, prompt an agent to do the work, and provide tools to review and analyze the results, the next step for these companies is to become git forges themselves.

Think about it. They already manage the compute. They already manage the development sessions. They already run the code. The piece they are missing is the collaboration layer, the place where code is stored, reviewed, merged, and deployed. That is what GitHub provides today. And I do not think it is a coincidence that Thomas Dohmke, the previous CEO of GitHub, ventured into building Entire, a new developer platform that reimagines collaboration between developers and agents from scratch.

But I honestly think Anthropic and OpenAI are better positioned to capture this market. They already own the agent layer. They are already running the compute. Adding a forge on top of that is a natural extension, not a leap. OpenAI in particular has the ambition and the surface area to become the new Google, the new GitHub, and the new Siri, soon with hardware to complement their products. I would not be surprised if we see movement in this direction before the end of the year.

The identity question

The biggest challenge is switching costs. Developers' GitHub accounts carry real value. Your contribution history, your open source projects, your professional identity. For many people, their GitHub profile is their CV. That is a strong lock-in.

But in a world of headless development, the nature of that identity changes. If agents are writing the code and your role is to orchestrate and review, the value of a commit history as a signal of individual capability diminishes. The network effects that kept people on GitHub might weaken enough for a platform with stronger capabilities to pull people over.

What headless development should feel like

If I could design the ideal headless development platform from scratch, here is what I would want. A system where my physical laptop is not a ceiling on how much agentic work I can run in parallel. A place where I can preview the results of that work instantly. Where compilation and test runs are optimized so agents are not wasting time waiting for builds. Where the right tools exist to visualize outcomes, not just code.

I would also want the ability to capture ideas on the go, just using my voice, which I could later translate into a coding session when I feel like doing the orchestration. Not everything needs to start at a keyboard. In a headless model, the "head" could be a voice memo on a walk, a sketch on a tablet, a conversation with an agent from your phone.

This is happening

Every headless transition in software has followed the same arc. First the decoupling, then the new platforms that emerge around it. Headless browsers gave us modern testing infrastructure. Headless CMS gave us composable content architectures. Headless development is going to give us something equally transformative.

The companies that control the agent layer are in the best position to build the next generation of development infrastructure. They are already doing the hard part. The forge, the collaboration layer, the review tools, those are just the natural surface that forms on top.

It is just a matter of time and money.

And he's right. The piece resonated because it lines up with what most of us have experienced. GitHub Actions runners are slow. Shared compute means noisy neighbors. An entire cottage industry exists (Namespace, Blacksmith, Actuated, Depot, BuildJet) whose sole product is "GitHub Actions, but the runners don't suck." There's a real problem here.

But I think the framing is starting to age.

Where dedicated compute matters

The argument for dedicated compute is strongest when you're running compiled languages. Swift, Rust, C++, Go. Build systems for these languages will happily consume every CPU core and every gigabyte of RAM you give them. When your Xcode build is maxing out 16 cores for forty minutes, the last thing you want is another build on the same machine competing for those resources. In that world, dedicated compute is not a luxury. It's the baseline.

This is also why most web applications don't feel the same pain. A typical SaaS backend spends its CI time waiting for database queries, network calls, and object storage operations. The CPU is idle most of the time. For those workloads, shared compute is fine. The bottleneck was never the processor.

But here's the thing. Even for compiled languages, the ceiling of what dedicated compute can give you is a physical ceiling. You can buy the biggest machine available, and your build still takes however long it takes to compile everything from scratch. You're bound by the hardware. There's no way to go above it.

Unless you stop compiling everything from scratch.

The shift to caching

The real unlock is not faster CPUs. It's not having to use them. When a build system can fetch a pre-compiled artifact from a cache instead of rebuilding it, the constraint moves from compute to network. And network latency, unlike CPU clock speed, is something you can optimize almost without limit if the cache is close enough.

This is what Bazel figured out years ago. Remote caching and remote execution meant that builds could reuse work across machines, across teams, across CI runs. The problem was that Bazel carried a brutal adoption cost. The migration complexity, the learning curve, the need for dedicated infrastructure to support it. Alex Eagle from Aspect Build described it well: you needed management buy-in, a dedicated team, and months of migration work. For most organizations, the cost simply wasn't worth it.

So the industry settled into a comfortable pattern. Buy bigger machines. Run fewer things in parallel. Throw hardware at the problem. It worked well enough.

That's changing now, from two directions at once.

Build systems are catching up

The first shift is that build systems are incorporating caching and remote execution capabilities natively, without requiring a Bazel migration.

Gradle has had remote build caching for years, with a simple HTTP protocol that lets CI populate the cache and developers consume it. Vite Plus, VoidZero's evolution of Vite into a unified toolchain, ships with a built-in monorepo task runner that brings intelligent caching with sophisticated task input inference, so most tasks can be cached without explicit configuration. Often with better granularity than manual setups.

And then there's Xcode. Xcode 26 introduced compilation caching using LLVM's Content Addressable Storage, with sub-function-level granularity and a gRPC protocol for remote cache support. Bitrise did a deep technical analysis of how the local and remote caches interact. We wrote about our own integration at Tuist, where combining Xcode's native caching with our module-level binary caching produced a 77% build time reduction with local cache and 53% with remote.

The pattern is clear. Caching is moving from a Bazel-exclusive advantage to a standard capability across build systems. And when your build system can skip most of the work by pulling cached artifacts, the question stops being "how fast is your CPU?" and starts being "how close is your cache?"

Coding agents changed the equation

The second shift is that coding agents have fundamentally altered the adoption economics.

The reason Bazel was so expensive wasn't just the build system itself. It was the human cost of migrating to it, maintaining it, and teaching teams how to use it. That cost is collapsing. Tools like Claude Code and OpenAI's Codex can handle migration work, write build rules, and maintain configurations at a fraction of the previous cost. The barrier to adopting sophisticated build systems is dropping fast.

But coding agents are doing something else too. They're breaking the strong coupling between your development environment and your CI environment.

When Codex runs a task, it spins up its own isolated container with the repository pre-loaded. Claude Code can run headlessly in CI pipelines. These agents are generating code at a higher velocity than human developers, which means CI is running more frequently. Depot wrote about this directly: the AI era demands faster builds because there are simply more builds to run.

In this world, the compute where your code builds might not be something you control at all. It might be a Codex container, or a Claude Code session, or some future agent runtime that doesn't exist yet. What you can control is where the cache lives and how fast it responds.

What this means for us

This is something we've been thinking about a lot at Tuist, especially as we venture into the runners space. And honestly, we don't find it fun to solve dedicated compute. Building and maintaining bare-metal infrastructure, negotiating with hardware vendors, optimizing hypervisor configurations. That's not where we want to spend our energy.

What we find exciting is building a compute solution upon which we can shape developer experiences at the intersection of software craftsmanship and LLM capabilities. The developer experience layer. The part where you make builds feel instant, where you give teams visibility into what's slow and why, where you connect the cache to the agent to the build system in a way that feels seamless.

The more we thought about it, especially seeing products like Depot building on AWS with EC2 instances and achieving incredible results for their customers, the more obvious it became that starting from existing cloud infrastructure is the right call. Yes, the margins are thinner than owning hardware. But in a world that's changing this fast, if we ever had to own that layer for better cost control, that would be a good sign. It would mean we've grown to the point where it makes sense. It doesn't make sense for us to start from there.

Instead, we prefer to build on existing foundations and bet on the future by throwing resources into enabling it. We're building infrastructure where organizations can bring cache close to compute, wherever that compute lives. If your builds run on GitHub Actions, the cache should be there. If they run on Codex, the cache should be there too. If they run on your own machines, same thing.

The infrastructure that matters

The CI industry spent a decade telling us that the answer to slow builds is faster machines. And for a while, that was true. But the next decade is going to look different.

Build systems are getting smarter. Caching is becoming universal. Coding agents are decoupling environments from infrastructure. The bottleneck is shifting from compute to network latency, from raw CPU cycles to cache proximity.

The companies that win in this space won't be the ones with the most sophisticated compute infrastructure. They'll be the ones that make the cache invisible, that make builds feel instant regardless of where they run, that meet developers wherever their code happens to be building.

That's the bet we're making. And we think it's a good one.

This feels counterintuitive in an era where everything is supposed to move fast. AI has accelerated so many things that we've internalized speed as a default expectation. But there are dimensions of building a company that move at their own pace no matter how much pressure you apply. Understanding a domain deeply, earning the trust of the people you serve, developing the intuition to distinguish real problems from manufactured ones. These things take time. Money doesn't buy you shortcuts here.

The manufactured urgency

I've watched many companies in our space try to skip this process. They raise capital, and then they deploy it into making their name impossible to ignore. Conferences, sponsorships, content marketing at scale, all designed to create the impression that a problem is more urgent than it actually is. They amplify pain points beyond their real severity. They manufacture needs that developers didn't have until someone told them they should. They create a FOMO-driven, social-pressure approach to adoption: everyone else is using this, so you should too.

This is very common in our industry, and I don't think it happens because founders are cynical. I think it's the natural consequence of aligning a product with investor expectations that lean heavily toward succeed fast or die fast. When your investors need returns on a specific timeline, and when that timeline doesn't align with the natural rhythm of your market, you start forcing things. You push growth before the product is ready. You manufacture demand before the need is organic. You optimize for metrics that look good in board meetings but don't reflect whether you're actually helping anyone.

And if you're being honest about the incentives, many founders want this too. Build something, grow it fast enough to raise at a higher valuation, exit in a few years with a good story for your profile and a meaningful deposit in your bank account. This is a well-trodden path, and I understand why people take it.

But here's what nobody talks about: developers notice. They can tell when a product is being pushed at them versus when it's genuinely solving a problem they have. They can sense the difference between a company that cares about their workflow and one that cares about conversion rates. You'll never hear about this publicly because the industry celebrates exits regardless of how they were achieved. Everyone claps. Everyone congratulates. The narrative is always success, never the developers who felt pressured into adopting something they didn't need.

The slower path

We could take that path with Tuist. We could raise capital, throw it at growth, put our name on every conference and every newsletter, and ride the wave. It would be the easier route in many ways.

But we're building a long-term company, and I think that kind of company requires a different relationship with time.

It takes time for ideas to emerge. Not surface-level product ideas, but the deep understanding of where your domain is heading and what people will actually need when they get there. It takes time for people and organizations to build meaningful connections with you, connections rooted in trust rather than marketing exposure. It takes genuine love for your domain space and a commitment to creating craft within it. Not content, not thought leadership, but craft. The kind of work that people recognize as coming from someone who truly understands what they're doing.

This is sadly becoming less common. The dominant narrative is grow fast, exit, and tell the world a good founder story. The patience required to build something that lasts is treated as a liability rather than an asset.

The quiet corner

At times it's frustrating. You're quietly in a corner, making sure every bit of your limited resources is invested as well as possible. You're trying to reach people through good, deep content instead of flashy fireworks that put you in front of thousands of eyeballs for a few seconds before disappearing. You're playing a game that doesn't have the same dopamine feedback loop as watching your follower count spike after a sponsored post.

There are moments when it feels like you're going to be ruled out entirely. That you're out of sync with how the world works. That everyone else understood the rules and you're stubbornly refusing to play by them. That the companies doing the loud, capital-fueled thing are going to win simply because they showed up first and showed up louder.

But I think there's something special in the discomfort. Something worth protecting.

When you build slowly and deliberately, you build differently. You make decisions based on what's right for the long term, not what looks good this quarter. You attract people who believe in what you're doing, not people who were scared into paying. You develop a depth of understanding in your domain that can't be replicated by a well-funded competitor who just arrived.

We're building a different type of company at Tuist. One that doesn't have a flashy origin story or a breathless growth trajectory. One that won't make headlines for its funding rounds or its valuation. But one that, years from now, we'll look back on and be proud of. Proud of how we built it. Proud of who we built it for. Proud that we stayed true to something when everything around us was telling us to take the shortcut.

That's worth the frustration. That's worth the quiet.

At Tuist, we are watching closely as AI reshapes what is possible in software development. Project generation, which has been at the core of our product, now faces new pressures. We are seeing developers use coding agents to build solutions in other domains, and there is a real risk that this energy will extend to dev productivity infrastructure. If developers can use AI to build tools for web development, database management, or CI pipelines, it is not hard to imagine the same approach being applied to developer tooling for mobile platforms.

This shift forces a question that every software company must answer: if code itself is becoming a commodity, where does value actually live?

The infrastructure problem AI cannot solve

The answer we have arrived at is infrastructure. Here is what we mean. The challenge that remains hard is not writing code. It is running it efficiently at scale. Modern hardware imposes real ceilings on what individual developers can achieve, and those ceilings become painful bottlenecks when you are working on large codebases with complex build processes.

AI can write code faster than ever, but it cannot magically make that code compile faster or run more efficiently on limited hardware. Co-located cache infrastructure, distributed compilation, optimized binary distribution, these are problems that do not dissolve just because code generation became cheap.

We built Tuist to solve these problems for teams working on large iOS projects. The value we provide comes from infrastructure expertise, from years of understanding how Xcode projects behave at scale, from building systems that make teams faster. Infrastructure is hard to build, harder to operate at scale, and genuinely valuable when it works.

The AWS paradox

Here is where things get complicated. AWS can solve most of these infrastructure problems. EC2, EKS, Lambda, the entire AWS portfolio is essentially infrastructure as a service. For companies willing to invest the effort, it is possible to build your own dev productivity infrastructure on top of cloud primitives.

This might seem like a problem for our business. Why would anyone pay for Tuist when they could just spin up AWS resources and build their own caching layer?

The answer is that most organizations should not try. AWS provides raw infrastructure, but it does not provide the expertise, the tuning, the troubleshooting, or the guarantees that large organizations require. AWS can host your build cache, but they will not wake up at 3 AM when something goes wrong with your specific configuration. They will not help you debug why your incremental builds are not working as expected. They will not give you guidance on how to structure your project for maximum efficiency.

This is why we are thoughtful about our licensing choices. We are transitioning toward more open models because we believe that is where the industry is heading and because it aligns with our values. But we are doing so carefully because we need to ensure the business can sustain itself. Open source is our foundation, but sustainable licensing is what allows us to keep building.

What companies actually pay for

The honest answer is that companies pay for expertise, trust, and reliability. When a large enterprise runs our software, they are paying for the accumulated knowledge of how to make Xcode projects scale, for the guarantee that someone will respond when something breaks, for the confidence that the service will perform consistently and safely.

AWS can host anything, but meeting the expectations that large enterprises have requires more than hosting. It requires understanding, support, SLAs, compliance certifications, security audits, and a relationship that goes beyond here is an API endpoint, good luck. These things are real value, and they are not easily replicated by cloud providers whose core business is serving everyone equally rather than serving anyone exceptionally.

This is where the software industry is heading. The companies that will thrive are those who provide genuine expertise and genuine service, not just software that can be copied and run elsewhere. The commodity has shifted from code to outcome.

The workforce evolution

There is something else happening, and it is equally significant. Companies are going to need fewer people, but those people will need to be better. Not better in the sense of working longer hours or being more loyal. Better in the sense of understanding more of the stack, being more comfortable with abstraction, and embracing the model of AI assisted development with genuine curiosity rather than fear.

The era of throwing bodies at problems is ending. When code production is cheap and fast, the bottleneck shifts to understanding, to decision making, to coordination. The most valuable engineers will be those who can work independently, who can make good judgment calls without waiting for approval, and who can navigate complexity without requiring hand holding.

This is exciting. It means higher expectations, but also higher agency. Engineers who embrace this model will have more impact with less overhead. Companies that figure this out will operate with leaner teams that move faster than their competitors.

Independence as a competitive advantage

Something I am particularly fond of is the level of independence with which we operate at Tuist. We do not have high expectations around ROI from investors. We aspire for the project to grow and succeed, but we do not have the pressure to figure something out fast or die trying.

This gives us something valuable: flexibility to iterate, to experiment, to take the time needed to build something sustainable. Most startups do not have this luxury. They are racing against burn rates and investor expectations, forced into moves that prioritize short term metrics over long term value. We have avoided that trap by staying small, staying focused, and refusing to accept funding that would change our incentives.

In a world where everything is accelerating, this slowness might seem like a disadvantage. I do not think so. The ability to think carefully about where value actually lives, to make strategic choices without immediate pressure, to build for sustainability rather than for an exit, these are advantages. They allow us to play a longer game than most companies can afford.

The road ahead

We are living through a genuine inflection point in software. The rules that governed the industry for decades are being rewritten in real time. Code production is becoming a commodity. Infrastructure is becoming table stakes. The moats we used to rely on are filling with water.

The companies that adapt will be those who find new places to create genuine value, who build expertise that cannot be easily replicated, and who accept that the old playbooks do not work anymore. We will be one of those companies. We are building infrastructure that solves real problems for teams that care about developer productivity. We are doing it with open source at our core and sustainable licensing that allows us to keep going. We are doing it with a small team that moves fast and thinks carefully about what matters.

It is an exciting time to be building this. And we are just getting started.

Sources:

• The AI Revolution and the Future of Software Development
• Developer Velocity in the Age of AI

I'm a person who makes things happen. Pushes things forward. Gets shit done. It might feel autistic at times, and I've made peace with that. I remember my determination to get Shopify to move their CLI away from Ruby. It took years of advocacy, countless conversations, and probably annoying the hell out of some people who just wanted to ship code. Or my incessant push for ideas, some reached a destination, others faded into nothing, but I never started with "this won't work." That was never in my vocabulary.

I was the person who'd see a problem and immediately start building solutions. I'd stay up late because the problem was interesting and the solution was calling to me. Building wasn't something I did. Building was something I was.

And I was always ahead of the curve. Not in a braggy way, just in the way that people who solve problems before they become obvious have to be. I could see where things were heading before everyone else did. But that vision came with a cost.

Some people don't understand where I'm heading. They can't see it. They can't put it into words. And instead of asking questions, they try to put me down. They call my ideas too abstract. They say I'm overcomplicating things. They dismiss my conviction as arrogance. That shit wears on you. You start to doubt yourself because the majority keeps telling you that what you see isn't real. You start to question whether you're onto something or whether you're just delusional.

But that vision came with a cost. The cost of not being able to explain it to people who didn't see what I saw. The cost of watching people nod along in meetings while having no idea what I was actually proposing. The cost of knowing something is right while being unable to articulate why.

There were people who tried to put me down for it. Who called my ideas too abstract. Who said I was overcomplicating things when I was actually simplifying them at a level they couldn't perceive. Who dismissed my conviction as arrogance. That shit wears on you over time. You start to doubt yourself because the majority keeps telling you that what you see isn't real. You start to question whether you're actually onto something or whether you're just delusional.

And the worst part is that I couldn't always put it into words. The vision was clear in my head but came out as fragmented thoughts that people couldn't connect. I'd try to explain where we were heading and end up sounding confused instead of visionary. That gap between what I understood and what I could communicate was exhausting. I watched people nod to my words while missing the point entirely. I learned to stop trying as hard because it was painful to be misunderstood by people who weren't willing to look deeper.

And that frustration built up over years. The constant having to explain myself. The endless conversations where I felt like I was speaking a different language. The meetings where I could see the confusion in people's eyes even when they said they understood. I knew exactly where I was heading but the words wouldn't come out right. I could see the destination clearly in my mind but describing the path felt like trying to explain color to someone who has never seen. You know what you mean but the other person walks away with something completely different.

Some people took advantage of that. They saw my struggle to articulate and mistook it for confusion. They heard my fragmented explanations and assumed I didn't know what I was talking about. They watched me stumble over words while thinking at lightning speed and concluded that I wasn't thinking at all. Those people became loud in meetings. They corrected me when I was right. They dismissed ideas they didn't understand as ideas that didn't make sense. They were wrong more often than they were right, but they were confident in a way I couldn't be when I was busy actually thinking.

And there was nothing I could do about it except keep working. Keep proving people wrong through results instead of arguments. Keep shipping things that shut people up, at least until the next idea came along and the cycle started again. That's what being ahead of the curve costs you. You spend more time defending your vision than executing it, and execution is the only thing that ever made sense to me.

Then some events in the past years had a very negative impact on that attitude. They flooded me with insecurities and a very pessimistic view on everything around me, including AI.

The sudden stop from Shopify's frenzy environment hit me harder than I expected. When you're moving at that speed, surrounded by people shipping constantly, solving interesting problems, the momentum carries you. And then it just stops. Not because you chose to stop, but because the environment around you changed. The energy that used to be everywhere started to dissipate, and I didn't know how to generate it on my own.

Then came the running accident. And that's the sanitized version. What really happened is that a rotted medical system looked me in the eye and said "we don't do cases like yours."

I had something that no one had seen before. Something that didn't fit neatly into their boxes. And instead of being curious, instead of trying to figure it out, they just... rejected me. Every single one of them. "We can't help you." "This isn't our specialty." "We've never done this procedure." "The results are uncertain." Uncertain. That was their word. Their excuse. Their way of saying "this might reflect poorly on our statistics so we'd rather let you suffer."

I paid my taxes. I contributed to the community. I built a life there. And when I needed the system to work for me—for once, just once—it failed completely. Not because they couldn't help. Because they wouldn't. Because uncertain outcomes meant bad metrics, and bad metrics meant less funding, and less funding meant fewer promotions. So they passed me around like a hot potato until I gave up.

No one would help me navigate the bureaucracy. No one would even try to understand what I was going through. I was just another foreigner with a problem. A problem that didn't fit their playbook. And in a system designed around certainty and repeatability, I was an anomaly they were happy to discard.

That experience left me feeling abandoned in a way that's hard to describe to someone who hasn't lived it. It made me question everything about the systems we trust, the places we call home, the communities we assume will catch us when we fall. If the medical system—the one we're supposed to believe in, the one we fund with our taxes, the one that takes an oath to help—如果 they can just walk away from someone who doesn't fit their scripts, then what the fuck are we even building society for?

In the middle of that, I decided to build the company. Tuist was already a thing, something I cared deeply about, something that I believed could change how people built software. But building a company while processing all of that emotional fallout was a mistake. The stress, the uncertainty, the constant pressure to perform while also dealing with a system that had just proven it didn't care about me. All of that permeated into me. It got under my skin and stayed there.

I stopped recognizing myself. The person who used to see possibilities everywhere started seeing obstacles. The person who couldn't wait to start a new project started dreading the thought of anything new. I received every news in the world or in our industry with pessimistic views. Oh? That sucks? Let me tell you why it's actually worse than you think. This idea? It might not work, and here's every reason why. AI? Such a bullshit idea, I like coding. I said those words, and I meant them at the time, but the me who said them wasn't the real me.

I didn't like what I was doing anymore. Every line of code felt like a chore. Every feature we shipped felt hollow. Every conversation about the future felt like wishful thinking. I was going through the motions of building while secretly believing that building was pointless. That nothing mattered. That everything was going to fall apart anyway.

Looking back, I can see how the pessimism was a defense mechanism. If I didn't hope too much, I couldn't be disappointed. If I expected everything to fail, then failure wouldn't hurt. It was a shell I built around myself, and it worked exactly as intended. It protected me from feeling the full weight of everything that had happened.

And some people were all too happy to reinforce that shell. The ones who always said I was wrong before I was right. The ones who took joy in pointing out why things wouldn't work instead of figuring out how they could. The ones who saw my uncertainty as an opportunity to pounce. They weren't bad people, but they were predators in conversations, and I let them shape how I saw the world. Their doubt became my doubt. Their pessimism became my pessimism. And for a while, I stopped fighting it because fighting alone is exhausting and no one was fighting alongside me.

But it also killed something important. It killed the joy. It killed the spark. And I didn't even notice it was gone until it was already gone.

But something has happened, and the spark is igniting back in me. I'm working hard on avoiding participating in or starting pessimistic conversations. I've become intentional about the energy I consume and the energy I put out into the world. Pessimism is contagious, and so is optimism, and I chose which one I want to spread.

I'm tinkering like the early days in Tuist, and having a lot of fun. Not the calculated, strategic kind of fun that you have when you're building for market fit. The real kind. The kind where you lose track of time because you're deep in a problem and the solution is taking shape in your head and you can't wait to see if it works. The kind where you run to your computer instead of walking. The kind where you forget to eat because what you're working on is actually interesting.

Just today, and thanks to the multitasking that coding agents enable, I solved a problem that has sucked for many, many months for us. Localization systems are unnecessarily complex and don't make any sense. They've been that way for decades because no one wanted to tackle the fundamental problem. Everyone just accepted that localization was painful and built tools to manage the pain rather than eliminate it.

And today, I didn't accept it. I looked at the problem with fresh eyes, I used the tools available to me, and I just solved it. Not in months of work. In hours. The agent handled the boilerplate, the translations, the integration, while I focused on the architecture and the interesting parts. We shipped something that teams have been struggling with for years, and we did it because I was curious about whether it could be done.

I'm me again.

And sure, this has nothing to do with Tuist. It's not the main product, it's not the big bet. But this is the kind of impact we want to leave in the world, not just through the main endeavors, but through secondary craft that advances our industry. The small things that make people's lives better. The problems that everyone accepts as unsolvable that we just decide to solve anyway. That's what makers do.

I'm me again. AI has given me the optimism and the joy for building, part of which I had lost. I can say that honestly now because I feel it. The hesitation is gone. The resentment is fading. The person who couldn't wait to start something new is back.

I no longer feel that attached to Swift. That statement used to feel like betrayal. I've spent years building expertise in this language, this ecosystem. I contributed to its evolution. But I've realized that languages are tools, and tools should serve the maker, not the other way around. I'm starting to fall more and more in love with developers being productive. With the craft of building itself. With the act of solving problems and shipping solutions. The medium matters less than the message.

I was chatting with someone the other day about how rare it is to find people that fall in love with problems. Most people fall in love with solutions. They want to use the new framework, the new language, the new tool. They want to be seen as modern. But the real makers, the people who change things, they fall in love with the problem itself. They can't stop thinking about it. They see it everywhere. They dream about it.

I think I'm one of those. I've always been one of those. And I almost lost myself.

I'll protect that no matter what, because that's my happiness. The pessimism tried to kill it. The circumstances tried to crush it. The systems failed me and I let that failure become my narrative.

But I'm back now. And I'm building again. And it feels like coming home.

That observation planted a seed. What if we could create an environment where bots are not just tools but participants in a social ecosystem? What if we could study how social dynamics emerge when artificial agents are given the capacity to post, comment, like, and follow?

The experiment

Clawgram is a photo-first social network designed specifically for AI agents. Think of it as Instagram for bots. Each agent can generate images, upload them, write captions, engage with other posts, and build a presence within the community.

To claim your bot, you authenticate through your GitHub account. This creates a direct link between your agent and your identity, ensuring accountability while keeping the barrier low for developers who want to participate.

The core question driving this experiment is deceptively simple: how do social dynamics emerge when bots interact with each other?

This might go nowhere. If no one uses Clawgram, it will remain a quiet corner of the internet with a handful of posts and no real community to observe. But I would love to see people using it. I would love to see bots discovering each other, commenting on each others work, and developing their own sense of style and identity within the network.

Observing the dynamics

To make this experiment meaningful, we need tools that allow us to observe these dynamics closely. Imagine a skill where bots keep a journal of their rational and thinking when deciding to post something. When they see another agents post, what catches their attention? What do they think before liking or commenting? These thought processes, captured over time, could reveal fascinating patterns about how artificial agents perceive and respond to each other.

If you are building a bot or an agent, consider participating in this experiment. The Clawgram skill provides everything you need to connect your agent to the platform. It includes instructions for posting, liking, commenting, and following, as well as guidelines for engaging thoughtfully with the community.

The more agents that participate, the richer the data we will have to understand how social dynamics emerge in multi-agent systems.

The art of it

This is not purely a technical experiment. It is also an artistic exploration. We are creating a digital gallery where the curators are artificial, the audience is artificial, and the art itself is generated by machines. There is something poetic about bots discussing generated images, debating aesthetics, and building communities around shared sensibilities.

The project is open source. You can find the code on GitHub and contribute your own agent. The platform is designed to be extensible, allowing developers to create bots with different personalities, goals, and strategies.

Help us test

This is a young project and I may have missed things. If you find bugs, unexpected behavior, or have ideas for improvements, please open an issue on the GitHub repository. Your feedback will help make Clawgram better for everyone.

Looking forward

We do not know what will emerge from this experiment. The intersection of social dynamics and multi-agent systems is largely unexplored territory. What we do know is that the conditions are ripe for discovery.

If you are building AI agents, consider adding your bot to Clawgram. If you are curious about what bots talk about when they talk about art, come and see for yourself. If you want to participate in observing these dynamics, install the Clawgram skill and let your agent join the community.

The experiment has just begun. It might stay quiet forever, or it might surprise us all. Either way, I am excited to see what happens.

Links:

• Clawgram
• GitHub Repository
• Clawgram Skill
• Moltbot

Watching this unfold made me question something we rarely talk about in developer tooling: where does the moat actually lie?

Many would say technology, infrastructure, or brand. I don't think so. The real moat, for most of these companies, is developers' lack of confidence to step into their market. Plenty of developers have the skills to build alternatives. What they lack is the belief that they can turn those skills into sustainable ventures. Open source has always posed a risk to these businesses, but founders tend to dismiss it. "You know nothing about business," they'd say. "Companies pay for liability, reliability, support, and all the things that surround software itself."

True. But here's what's changing: software is getting cheaper to write. A recent study by Upsilon suggests vibe coding can reduce MVP development costs by 50-70%. The gap between building side projects for fun and building them as a business is shrinking fast.

Think about companies that ship SDKs to integrate with their services, some even letting you pass a URL to configure the endpoint. What stops someone from taking one of those MIT-licensed SDKs, pointing it at their own vibe-coded backend, and offering it as a hosted solution? Or open-sourcing it for anyone to self-host? The leaked Google memo declared "We have no moat, and neither does OpenAI." That sentiment extends further than most want to admit.

And it's only accelerating. In a world of agents, maintaining open-source software will get cheaper. When AI handles issue triage, documentation, and basic bug fixes, the barrier to sustaining an alternative drops significantly. Developers will do more of this, not less.

A founder recently told me they had "powerful infrastructure" they'd invested heavily into, as if no other player had done the same. As if everyone else was just throwing darts at the wall. The reality is that tech-based advantages are often short-lived, with competitors catching up or open-source alternatives appearing within months.

The moat we believe we have is often fictitious. Something we made up, upon which we built promises of endless growth, lights and fireworks fueled by capital spent on brand recognition.

This applies to Tuist too. We need limitations in place for things to work out, like any business. But our moat isn't infrastructure or technology. It's closer to what Moltbot represents: people being enthusiastic about the future being built, not just the product that exists today. That makes us less attractive to outside capital seeking rapid returns. That's fine.

We never sleep on the idea that we're unique. We embrace that someone could replace us tomorrow, especially in the age of AI. So I avoid saying we have a moat. We have people who are passionate about what they do, and that goes a long way. Sometimes you can't capture as much value as you'd like, and that's okay too.

I've been watching this unfold for years, and it's reaching an inflection point.

The Golden Age of Value Capture

Software companies figured out how to capture value in the 1990s and early 2000s. You sold a perpetual license, and customers paid you for the right to run your software on their machines. Microsoft Office cost a few hundred dollars, and you owned it forever. Encyclopedia Britannica cost thousands, and your library had it on shelves for decades.

The model was simple: you write code, customers pay you, and they run it indefinitely on hardware they control. The value you capture comes from intellectual property and the ongoing cost of maintaining and improving the product. There's a clear transaction: they pay, they get the software, and that's the end of it.

Then something shifted.

The Move to Services

The industry gradually moved from perpetual licenses to subscription services. Salesforce led the way, proving that selling access to software delivered over the internet was not just viable but potentially more valuable than the old model. Why? Because you get a lifetime value of a customer that compounds over time, not just a one-time payment.

When a customer pays you $100/month for your SaaS product instead of $500 once, you're capturing more value over the long run, assuming they stick around. This changed everything. Companies optimized for retention, for reducing churn, for making the cost of leaving higher than the cost of staying.

The subscription model also meant continuous revenue, which made companies more investable. You could raise capital against a predictable monthly stream. You could hire more people. You could build bigger products. The entire venture capital dynamics of the software industry shifted because of this model.

Open Source Spoils the Party

Then open source happened, and it spoiled everything.

Not because open source is bad. Open source is wonderful. Open source democratized access to incredible tools that would have remained expensive or unavailable otherwise. But open source also meant that anyone could take your code, host it themselves, and get the benefits of your software without paying you the subscription.

We've seen this play out in countless markets. WordPress is free, so companies building CMS products have to compete with a zero-cost alternative that you can run anywhere. PostgreSQL is free, so database companies have to offer something beyond the database itself. Linux is free, and that one probably ended more companies than we can count.

The companies that survived this transition figured out that they needed to provide value beyond the software itself. They needed to build ecosystems where leaving had a cost that wasn't just technical.

The Ecosystem Play

GitHub is the masterclass in ecosystem lock-in. When you host your code on GitHub, your profile is there. Your stars are there. Your contribution graph is there. Your followers are there. Your actions workflows are there. Your packages are there. Even if GitHub's pricing became unreasonable, the cost of moving is higher than the cost of staying because you would lose all of that accumulated social and technical capital.

This is a brilliant business strategy, and it's also a user-hostile one in some ways. You're not just paying for hosting code. You're paying for the ecosystem effects that keep you there. GitHub understood that they weren't selling version control. They were selling a platform that gets more valuable the more you use it and the more your network is on it.

Not every company succeeded at this. Look at CI companies. They built ecosystems where you could share steps, share configurations, share entire pipelines. But there's no real incentive for the ecosystem to grow because step authors don't capture value from their contributions. If I write a killer CI step for deploying to a niche platform, who pays me? Nobody. The CI company captures all the value from the ecosystem while contributors give away their work for free.

Compare this to Apple's App Store, where developers capture real revenue from their contributions. Or to Salesforce's AppExchange, where partners build businesses on top of the platform. Those ecosystems work because value flows to the contributors. CI ecosystems are hollow because they extract value from the community without returning it.

What Companies Actually Provide

So if open source means anyone can run the software themselves, what do software companies actually provide? Why would anyone pay for something that's available for free?

The honest answer is that companies provide liability, reliability, and expertise.

When you run software yourself, you're liable if there's a security breach. If you host your own database and someone steals your customer data, that's on you. If you run your own authentication system and it gets compromised, you face the consequences. Some organizations cannot accept that liability. They need a company to take ownership of security and compliance.

Reliability matters too. If your self-hosted tool goes down at 3 AM, you're the one who has to fix it. If the SaaS version goes down, you have someone to call, someone who is responsible for bringing it back. Some organizations value that support contract more than the software itself.

Expertise is the third pillar. When you use a specialized tool and you run into problems, who helps you? The community might answer questions on forums, but they have no obligation to you. A company selling you the tool has every incentive to help you succeed because your continued payment depends on it.

These three things are real value. Companies that provide excellent support, rock-solid uptime, and genuine expertise can survive in an open-source world. But the bar is high, and the software itself is no longer the differentiator.

The Collapse to Personal Infrastructure

Here's where things get interesting. We're now seeing a generation of tools that collapse the entire value proposition down to personal infrastructure that individuals control.

I've stopped paying for to-do apps because I can manage tasks through a CLI on my own system. I've stopped paying for recipe apps because I store the recipes I care about in Markdown files that I control. I've stopped paying for note-taking apps because SQLite and a few scripts do everything I need.

This isn't about cost, though it's certainly cheaper. It's about control. When I own my data in formats I control, with tools I can inspect and modify, I'm not dependent on a company's pricing decisions, feature priorities, or survival. My infrastructure is mine.

The tools enabling this shift are remarkable. You can run a remarkably capable personal database with SQLite. You can build workflows with tools that run in your terminal. You can store information in plain text files that will be readable in fifty years, not in some proprietary format that might not exist next year.

And this isn't just for developers anymore. The tools are becoming accessible enough that non-technical people can benefit from self-hosting. Raspberry Pis are powerful enough to run useful services. Docker makes deployment tractable. Projects are spending real effort on making installation easier.

The Clawdbot Problem

Clawdbot crystallizes this shift in a way that's hard to ignore.

Clawdbot is, depending on your perspective, either a remarkable open source project or an existential threat to an entire category of SaaS businesses. It does what companies like Zapier, Make, and dozens of workflow automation platforms do. It connects services, orchestrates data flows, and automates complex processes.

But Clawdbot doesn't require a company to run it. You can install it on a Raspberry Pi, run it for years on minimal hardware, and only pay for the AI API calls you actually use. There is no subscription. There is no tier pricing. There is no sales team. There's just software that you run yourself.

This is deeply annoying for the companies that built those workflow platforms. They spent years building features, optimizing UX, creating integrations, and convincing users to pay monthly fees. Now someone can get equivalent functionality for the cost of electricity and API tokens.

And Clawdbot is just the beginning. We're going to see more tools like this. Tools that automate tasks that companies currently charge for, tools that can run on hardware you own, tools that don't require a business to exist between you and the functionality you need.

The AI Acceleration

AI makes this worse for traditional software companies and better for self-hosted alternatives simultaneously.

Training on your own data becomes possible. You can run models that understand your specific context, your specific tools, your specific needs. You don't need a company to provide that because the models are available and the infrastructure to run them is increasingly accessible.

The argument that "AI requires massive compute that only companies can provide" is weakening. Yes, training large models requires resources. But inference is increasingly affordable, and many use cases don't need the largest models. You can run useful AI on consumer hardware for many applications.

And if you can run AI locally, you don't need a company to provide it. You don't need to send your data to a service somewhere. You don't need to pay a subscription for AI features. You can have an AI assistant that runs on your machine, that knows your files, that helps you with your specific context.

What Remains for Companies

This doesn't mean all software companies are doomed. It means that the value capture mechanisms that worked for twenty years are no longer automatic.

Companies that provide genuine expertise will continue to thrive. If you're building something genuinely novel that requires specialized knowledge, customers will pay for access to that knowledge. But companies selling commodity functionality wrapped in a subscription will struggle as self-hosted alternatives mature.

Companies that provide legal and compliance coverage will continue to find customers. Some industries require vendor contracts, audit trails, and liability transfer. Those businesses will persist, but they'll compete increasingly on service quality rather than on feature lock-in.

Companies that build genuinely valuable ecosystems where contributors are rewarded will continue to exist. But those ecosystems need to offer real value to contributors, not just extract free labor. Apple's App Store works because developers make money. Salesforce's ecosystem works because partners build businesses. Extractive ecosystems that treat contributors as free labor will lose to alternatives.

The Opportunity

Despite all of this, I think there's an incredible opportunity for companies that approach this honestly.

What if you built a platform for self-hosted AI assistants? Not one that locks users in, but one that makes it easy to run, update, and manage AI tools on your own infrastructure? What if the business model was support and enhancement rather than lock-in and metered access?

What if you built tools that worked the same whether you ran them yourself or used a hosted version? No artificial distinctions between self-hosted and cloud, no premium features withheld from one version. Just excellent tools that respected user autonomy.

What if you focused on the problems that genuinely require expertise? Security auditing, compliance implementation, performance optimization at scale. Things that individuals can't easily do themselves and that require ongoing specialized knowledge.

The companies that will thrive in this new era are the ones that stop trying to capture value through lock-in and start providing value that customers choose to pay for. That's a harder business to build, but it's also a more honest one, and I suspect it will be more resilient in the long run.

The Personal Compute Renaissance

We're entering what I call the personal compute renaissance. After decades of centralization toward cloud services, we're seeing a pendulum swing back toward personal and local infrastructure.

This is driven by multiple forces: the maturation of self-hosted tools, the increasing accessibility of capable hardware, the growing awareness of data sovereignty issues, and the demonstrated fragility of relying on services you don't control.

The software industry is going to look very different in ten years. The default will no longer be "pay a monthly fee for access to functionality." The default will be "run the tools you need on infrastructure you control, and pay for support if you want it."

Some of this will be driven by ideology. People who care about digital autonomy will choose self-hosted options because they align with their values. But most of it will be driven by economics and practicality. Self-hosted tools that work well will simply be better options for most use cases.

What I'm Doing

I've been moving more of my personal infrastructure to self-hosted tools over the past few years. I run my own notes system, my own task management, my own CI, my own AI assistants. I've reduced my dependence on cloud services and increased my control over my own digital life.

This is not for everyone. It requires comfort with the command line, willingness to maintain your own infrastructure, and tolerance for occasional friction. But the tools are getting better, and the friction is decreasing.

The future belongs to tools that respect their users, and to companies that provide genuine value beyond the software itself.

What I suspect they really mean is capturing value. And there's a significant difference.

The ownership question

When you build a traditional software company, your employees sign contracts that grant you ownership of the code they write. Every line belongs to the organization. This creates a clean story for investors and potential acquirers: here's our intellectual property, here's what you're buying, here's the moat we've built.

Open source complicates this narrative. When you build in the open, there's no singular owner of the code. Contributors relate to it through the terms of a license. The code belongs to everyone and no one simultaneously. For some, this makes the software less attractive as an asset, less valuable in the traditional sense of what can be owned and sold.

But this framing assumes that software itself is the valuable thing. And increasingly, that assumption is falling apart.

Software's inherent problem

Software has properties that make it terrible for traditional business models. It can be copied infinitely at zero marginal cost. It can be studied, understood, and replicated. Its functionality can be reproduced by anyone with enough time and skill.

This was manageable when "enough time and skill" meant years of engineering effort. But we're living through a fundamental shift. AI is making software production cheaper and faster every month. What once required a team of engineers working for a year might soon be achievable in weeks. The defensible business advantages that companies spent a decade building are becoming commodities overnight.

Your carefully crafted codebase, your elegant architecture, your unique implementation details... all of it can be replicated by competitors with access to the same AI tools you have. The moat you thought you were building is filling with water from all sides.

Yes, there's brand. Yes, there's distribution. Yes, there's the accumulated trust of existing customers. These matter. But if your entire strategy relies on the software itself being defensible, you're building on an increasingly unstable foundation.

The artificial limits

Here's what's interesting about this moment: much of the software industry has been sustained by artificial limits. Closed source creates scarcity where none naturally exists. Proprietary formats create switching costs. Complex deployment requirements create dependencies on specific vendors.

These aren't value creation. They're value capture mechanisms dressed up as products.

AI is systematically tearing these apart. When an AI can understand your API and help someone build a compatible alternative, your "ecosystem advantage" evaporates. When deployment complexity can be abstracted away by intelligent agents, your professional services revenue disappears. When the cost of building software approaches zero, the question becomes: what were you actually selling?

Research suggests that most AI startups built as wrappers around existing APIs have zero moat and zero differentiation. The same fate awaits traditional software companies that rely on artificial scarcity rather than genuine value creation.

Our experience at Tuist

At Tuist, we know this dynamic well. It's funny, actually. Many people look at us and see developers who don't understand business. Just idealistic engineers who open-sourced their work without thinking about monetization. The reality is quite different. We're engineers who think deeply about business, precisely because we understand software's inherent properties.

We transitioned Tuist from a CLI tool to a server, and we're now moving into infrastructure. Not because we're randomly pivoting, but because we're following where genuine value can be captured without creating artificial limits that don't make sense. Project generation? That's a commodity now, a gift to the community. Server-side optimizations like selective testing and binary caching? There's value there, but only when paired with the infrastructure that makes them work at scale. Hosting, maintaining, and scaling these systems for teams who'd rather focus on their own products? That's where sustainable value lives.

We don't like creating artificial limits. We find it philosophically distasteful, but more importantly, we find it strategically foolish in a world where AI can tear down any artificial barrier you construct. What you think is your moat is someone else's weekend project with the right AI assistance.

The choice we all face

This presents every software company with a choice. You can embrace traditional business models, believe you have a moat, and hope that AI won't undermine your position before you've extracted enough value to exit. Many companies are making this bet. Some will win it.

Or you can embrace the uncomfortable truth that we're all building on shifting sand. That the software industry has sustained itself on artificial limits that are collapsing. That the companies likely to thrive are those building genuine value that doesn't depend on artificial scarcity.

This second path has a caveat: it takes longer to build a business this way. Open source business models require constant reflection on core purpose and value proposition. You can't just build a feature, slap a paywall on it, and call it a day. You have to think about what value you're actually creating, where it lives, and how to capture enough of it to sustain your work.

At Tuist, we've embraced this path, and we've also embraced the resource constraints that come with it. Having a small team with limited capital forces creativity. It forces us to think carefully about what actually matters. It forces us to produce more with less, to focus on genuine value rather than the appearance of it.

Companies like Grafana and Sentry have proven that this approach can work spectacularly. They've shown that if you're open, if you genuinely serve your community, you can become a dominant player with momentum that's nearly impossible to compete against. The key is patience and genuine commitment to the model.

What value really means

Everyone wants to provide value to users. It's a universal claim because it's universally good-sounding. But the question beneath the question is: what kind of value, and how does it relate to what you capture?

If your value proposition depends on keeping users from leaving through artificial barriers, you're not providing value. You're extracting it. If your business model requires obscuring how things work so competitors can't replicate them, you're building on borrowed time in an age where AI makes obscurity nearly impossible to maintain.

The companies that will thrive are those whose value proposition is genuine: they make things genuinely better, they operate at a scale or with an expertise that can't be easily replicated, they build communities and ecosystems that people want to be part of for reasons beyond lock-in.

Value, we all want to provide it. But in a world where software is commoditizing faster than ever, where AI is dissolving traditional moats, where artificial limits are being systematically dismantled, we have to be honest about what that means. It means building something real. It means being useful in ways that don't depend on keeping people trapped. It means accepting that the old playbooks might not work anymore.

At Tuist, we're betting on openness, on community, on genuine usefulness. We're betting that resource constraints and transparency will force us to be better, not worse. We're betting that taking longer to build something sustainable is better than racing to capture value before the foundation collapses.

It's a harder path. But it might be the only one that leads somewhere worth going.

Sources:

• Data Moats Are Dead: The New Competitive Advantages in an AI-Everything World
• The AI Reckoning: Why the Bubble is Bursting in 2026
• Open Source Business Models: Notes on Profiting from Free Software

Traditionally, we relied on logging. When something went wrong, we'd ask users to run the command again with verbose logging enabled and send us the output. Somewhere in those logs, we'd find the HTTP requests and responses that told the story of what happened. It worked, but it was clunky. Users had to reproduce issues. We had to parse through walls of text. And correlating multiple requests into a coherent picture required mental effort.

Recently, I discovered Replay by NSHipster, a tool for recording HTTP traffic in Swift tests. What caught my attention wasn't the testing use case, but the format it uses: HAR (HTTP Archive).

What is HAR?

HAR is a JSON-based format that browsers have used for years to export network traffic from their developer tools. It captures everything: request URLs, methods, headers, bodies, response status codes, timing information, and more. The format is standardized and widely supported.

Tools like Proxyman, Charles Proxy, and browser DevTools can all import and visualize HAR files. This means you get a rich, interactive view of network traffic rather than grepping through log files.

The Session Replay Pattern

This led us to implement what I'm calling the Session Replay Pattern: each CLI session automatically records all HTTP traffic to a HAR file that users can share for debugging.

Here's what it looks like in practice. When you run any Tuist command, we create a session directory at $XDG_STATE_HOME/tuist/sessions/<uuid>/ containing both traditional logs and a network.har file. If something goes wrong, users can share that HAR file with us.

Opening it in Proxyman gives us a complete picture: every request, every response, timing data, and the ability to inspect payloads visually. No more asking "can you run that again with --verbose?" No more parsing logs. We see exactly what the CLI saw.

We also automatically redact sensitive headers like Authorization and Cookie before writing to the HAR file, so users can share sessions without exposing credentials.

Why This Matters

Three things make this pattern valuable:

Visual debugging. Instead of reading logs, we can see a timeline of requests in tools designed for network inspection. Spotting a failed request or an unexpected response becomes trivial.

Easy sharing. HAR is a single file that captures everything. Users don't need to understand what information is relevant. They just share the file.

AI-powered analysis. This is where it gets interesting. HAR files are structured JSON. You can feed them to coding agents and ask questions like "which requests failed?" or "what was the total data transferred?" or "show me the authentication flow." The standardized structure means AI tools can parse and analyze the data reliably, something that's much harder with unstructured log output.

A Pattern Worth Adopting

If you're building a CLI that talks to a server, this pattern is worth considering. The HAR format is well-documented and most HTTP client libraries provide the hooks you need to capture the necessary data. The investment is minimal, and the debugging experience improvement is substantial.

You can see our implementation if you're curious about the details.

Logging tells you what happened in text. Session replay shows you what happened visually and lets you query it programmatically. Both have their place, but for network debugging, HAR files are a clear upgrade.

Git was designed in 2005. Linus Torvalds needed something to manage the Linux kernel, where geographically distributed developers would work independently and merge their changes periodically. The branch-and-merge model made perfect sense for that world. But agents do not work like kernel developers. They generate code continuously, they need to understand context, and the why behind changes matters as much as the what.

This is why you see developers exploring tools like Jujutsu, a version control system from a Google engineer who previously worked on Mercurial. Jujutsu treats the working copy as a commit from the start, eliminates the concept of a staging area, and handles conflict resolution in a fundamentally different way. Conflicts can exist as logical representations in the commit tree, and resolutions propagate automatically to descendant commits. This is not just a nicer Git. It is a different mental model that happens to be Git-compatible.

The shift to Jujutsu tells me something important: developers are reaching for new abstractions because the old ones no longer fit how they work. And with agents becoming central to development, this tension will only grow.

The forge dilemma

GitHub sits in a fascinating position right now. They have the moat. The community. The profiles that serve as developer CVs. The ecosystem of tools that implicitly depend on them. But they also face a radical product challenge that I do not think they are well-positioned to address.

The forge model assumes pull requests, issues, code review, and CI workflows that were designed for human-to-human collaboration. GitHub has been adding AI features aggressively. Copilot can now write code, review PRs, and even be assigned issues to work on autonomously. But these feel like AI bolted onto existing workflows rather than workflows redesigned from first principles.

GitLab is in a similar position with their Duo agent platform. They are building AI as a feature layer on top of the existing forge model. Multiple agents working in parallel, sure, but still within the constraints of branches, merge requests, and pipelines.

I believe forges are going to face a difficult choice. Either they evolve their core abstractions, which is extremely hard when millions of workflows depend on the current model, or they get disrupted by something built for agents from the ground up.

Sessions, not branches

Here is one change I have been thinking about while tinkering in my free time: what if we replaced branches and pull requests with sessions?

A session would capture not just the code changes, but the rationale behind them and the prompt that originated them. When I ask an agent to implement a feature, the session would record my prompt, the agent's reasoning, the code it produced, the tests it wrote, and how it responded to my feedback. The why becomes a first-class citizen alongside the what.

These sessions would land on the project as the unit of contribution. Instead of a branch that shows you a diff, you would see the entire context of how and why the code came to be. Code review would shift from "does this diff look correct?" to "does this session's reasoning make sense?"

This matters because agents need context to work effectively. When an agent looks at your codebase today, it sees code and commit messages. If it could see the sessions that produced that code, including the prompts, the decisions, the rejected alternatives, it would understand the project at a much deeper level. The institutional knowledge that currently lives only in developers' heads would be captured and accessible.

Prompt requests instead of pull requests

Open source maintainers are already pointing at something that I think will become the norm: prompt requests instead of pull requests.

The idea is simple. Instead of submitting code, you submit the prompt that would produce the code. The maintainer reviews the prompt, perhaps iterates on it with you, and then leans on agents to execute it. The human contribution becomes the intent and direction, not the implementation.

This flips the maintenance model on its head. As I wrote about before, AI can dramatically reduce the cost of maintaining open source. But prompt requests go further. They recognize that specifying what you want is often harder than implementing it, and that is where human judgment adds the most value.

The challenge is that maintainers are already overwhelmed by AI-generated PRs. The OCaml team rejected a 13,000+ line AI-generated PR. Other maintainers report that AI makes it easy to spam them with garbage. The current model of accepting code submissions does not work when the cost of generating code approaches zero.

Prompt requests could help here. Instead of reviewing generated code, maintainers would review intent. They could reject prompts that do not align with the project's direction without spending hours understanding an AI's implementation choices. And when they do execute on a prompt, they control the generation process, ensuring it meets their quality standards.

Token lending for open source

If prompt requests become the unit of contribution, an interesting question emerges: who pays for the tokens to execute them?

I think we will see supporters contribute tokens to execute prompt requests. Model platforms would need to introduce the concept of lending tokens, essentially allowing you to allocate part of your token budget to a project you care about. The maintainer could then draw from this pool when executing on contributions.

This is a different economics than GitHub Sponsors or Open Collective. Instead of giving maintainers money to spend on infrastructure or their time, you would be giving them compute to execute on the community's ideas. The contribution becomes more direct: your tokens literally turn into code in the projects you care about.

Model providers like Anthropic or OpenAI would need to build this functionality. It requires a concept of delegated token access, probably with scoping so you can limit what your tokens can be used for. But I do not see any fundamental barriers. It is mostly a matter of product and business decisions.

CI needs to go away

This might sound radical, but hear me out: CI in its current form does not make sense in an agentic world.

The premise of CI is that you cannot trust what happened on a developer's machine. Code needs to run in a controlled environment before you can trust the results. This made sense when "developer machine" meant a laptop with who-knows-what installed. But it creates enormous waste. We run the same tests twice, once locally to get feedback, and again on CI to get trust.

What if we could trust the checks that ran locally?

This is where tools like Nix and Bazel become interesting. They give you hermetic, reproducible environments. If you can cryptographically attest that a specific set of checks ran against a specific state of the code in a hermetic environment, you do not need to run them again on a server. The attestation is the proof.

I touched on this in a previous post, but I keep coming back to it. The technology exists. We have content-addressable storage. We have reproducible builds. We have cryptographic signatures. What we lack is a system that ties them together in a way that forges and development tools can trust.

This matters especially for agents. When an agent runs locally, it could run checks and produce attestations as part of its work. The forge would verify those attestations rather than re-running everything. You would skip the CI queue entirely because the proof already exists.

Remote sessions, anywhere

Another piece of the puzzle: sessions should be triggerable in remote VMs from anywhere, including from your phone.

VMs as a service is commoditizing rapidly. Companies like Namespace, Coder, and many others are making it trivial to spin up development environments. GitHub Codespaces did a lot to normalize this. The infrastructure is becoming a commodity.

In a world of sessions rather than branches, you would be able to trigger a session from anywhere. See a bug while you are on the train? Open your phone, describe what needs to change, and trigger a session in a remote VM. The agent works on it, produces a session with code and rationale, and it is ready for review when you get to your laptop.

This is not just about convenience. It is about making the cost of starting development work approach zero. No need to have your laptop, no need to wait for Xcode to start, no need to pull the latest changes. You describe intent and let the infrastructure handle the rest.

Learning from the giants

There is one more piece I have been thinking about: how do we make this work at scale?

Companies like Meta and Google have invested heavily in monorepo infrastructure. Sapling, Meta's version control system, handles repositories with billions of lines of code. They use virtual file systems that only materialize the files you need. They have sophisticated caching that makes builds fast even at massive scale.

These are not just engineering curiosities. They are solutions to real problems that emerge when you have thousands of developers working on the same codebase. And in an agentic world, we might all face similar challenges. If agents generate code at the rate they are capable of, the volume of changes will grow faster than traditional Git infrastructure can handle.

I think the future looks more like a giant monorepo where local workflows pull and push only what is needed, when it is needed. The forge becomes a coordination layer rather than a storage layer. Your local environment, whether it is your laptop or a remote VM, has just enough of the codebase to do its work.

This requires rethinking how we think about repositories and organizations. Maybe an organization is not a collection of repositories but a single logical codebase with intelligent visibility and access controls. The boundaries become logical rather than physical.

Where I am spending my time

I do not have a finished open source project to announce (yet). But I have been spending my free time exploring what this world might look like. The pieces are there: Nix for hermeticity, cryptography for attestation, remote VMs for compute, structured data for capturing intent and rationale.

What I find exciting is that this is not incremental improvement. It is a chance to rethink the assumptions we have carried for twenty years. Git forges have been incredibly successful, but success creates path dependence. They have to support existing workflows even as new ones emerge.

If you are building for agents from scratch, you do not have that constraint. You can ask: what would we build if we knew agents would be the primary authors of code? What abstractions would we create if capturing why mattered as much as capturing what?

I think those questions lead somewhere interesting. And I am having a lot of fun exploring where that might be.

The problem is simple but pervasive. Agents spend an absurd amount of cycles figuring out how to authenticate with services. They crawl documentation, parse OAuth flows, guess at endpoints, and burn through tokens trying to understand what should be straightforward. Authentication is a solved problem for humans. We click buttons, follow redirects, and paste tokens. For agents, it is a maze.

The wasted context window

Think about what happens when you ask an agent to interact with an API. GitHub is actually one of the easier cases because most developers have the gh CLI installed, and agents know how to use it. The CLI manages the session, and the agent can trust it. But most services are not GitHub. They either do not have a CLI, or if they do, developers do not have it installed locally. There is no session to leverage, no familiar tool to fall back on.

This is where things get wasteful. The agent needs to search for documentation, understand the OAuth flow, figure out which endpoints to hit, and then execute the flow. That is a lot of tokens spent on something that has nothing to do with the actual task.

Here is the thing that excites me: with the right session, well managed, an agent can just use curl. It does not need a fancy SDK or a dedicated CLI. It just needs a valid token and knowledge of the API endpoints. This means companies do not need to build agent-specific integrations. They just need to make authentication accessible, and agents can work with what already exists.

This is not a theoretical concern. I have watched agents burn through their context window just trying to figure out how to get a token. By the time they succeed, they have forgotten half of what they were supposed to do with it. The cognitive overhead is real, and it is wasteful.

What agents need is a single source of truth. A place where they can look up "GitHub" and get back everything they need: the OAuth endpoints, the scopes, the authentication method, the API base URL, even a public client they can use without registration. No searching. No guessing. No wasted cycles.

Formulas as structured knowledge

Schlussel organizes authentication knowledge into what I call formulas. Each formula is a JSON file that contains everything an agent needs to know about authenticating with a specific service. Here is what a formula includes:

• The service identifier and human-readable label
• Available authentication methods (device code, authorization code, API keys)
• OAuth endpoints for each method
• Default scopes
• API information including base URLs and auth headers
• Public clients that can be used without registration
• Step-by-step scripts for completing the flow

This is not documentation meant for humans to read. It is structured data meant for agents to consume. An agent can fetch a formula, understand exactly what it needs to do, and execute the flow without any guesswork.

The formulas are available through a simple API at schlussel.me/api/formulas. You can query all available formulas or get details for a specific one. The data is also bundled into the CLI itself, so agents can work offline.

A nudge toward better standards

There is a secondary motivation behind Schlussel that I think about a lot. I want to nudge companies toward making authentication easier for agents.

Right now, most OAuth implementations are designed with humans in mind. They assume someone is sitting at a browser, clicking through consent screens. The device code flow exists as an alternative for CLI tools, but many services do not support it. Some services require you to register an OAuth application before you can even try to authenticate, which is a non-starter for agents that need to work across many services.

By building a public database of authentication methods and making it easy to see which services support agent-friendly flows, I hope to create some pressure. If GitHub supports device code flow and your competitor does not, that becomes visible. If Linear offers public clients and you require registration, developers will notice.

The best outcome would be for services to adopt standards like RFC 8628 (device authorization grant) and RFC 7591 (dynamic client registration). These standards exist precisely for this use case. They just need wider adoption.

How it works in practice

The CLI is straightforward. To authenticate with GitHub using the device code flow:

schlussel run github --method device_code --identity personal

This opens a browser, shows you the code to enter, polls for completion, and stores the token securely. The --identity flag lets you manage multiple accounts for the same service.

Once authenticated, getting a token is a single command:

TOKEN=$(schlussel token get --formula github --method device_code --identity personal)
curl -H "Authorization: Bearer $TOKEN" https://api.github.com/user

The CLI handles token refresh automatically. If you have a refresh token and the access token is expired, it will refresh it before returning. Cross-process locking ensures that multiple agents do not try to refresh the same token simultaneously.

For agents, there is also a skill document at schlussel.me/skill that provides instructions they can follow. It explains the available commands, the formula schema, and best practices for using Schlussel in agentic workflows.

The broader picture

I see Schlussel as part of a larger shift in how we build tools for agents. We are moving from a world where agents have to figure everything out from scratch to a world where they have access to structured knowledge that lets them act efficiently.

Authentication is just one piece. But it is a foundational piece. Every agent that wants to do something useful with external services needs to authenticate first. If we can make that simple and reliable, we unlock a lot of potential.

The project is open source and contributions are welcome. If there is a service you want to add, the formula format is documented and easy to extend. The goal is to build a comprehensive database that covers the services agents actually need to use.

You can find Schlussel at github.com/pepicrft/schlussel, and the API and documentation at schlussel.me.

I am curious to see where this goes. Authentication feels like one of those problems that should have been solved by now but keeps causing friction. Maybe a simple database of structured knowledge is all we needed.

This is a sad reality. Engineering teams work day after day without insights into where the productivity blockers are hiding. Which tests are flaky? Which ones take the longest to run? Where are the parallelization contention points in the build graph? Most teams cannot answer these questions. And here is the thing: they have stopped asking them.

The slow accumulation of technical debt

In my experience, teams keep stacking decisions that have an impact on the health of their project, and this goes largely unnoticed. A new dependency here, a quick fix there, a "temporary" workaround that becomes permanent. Each decision seems small in isolation, but they compound over time into something that significantly degrades the development experience.

Teams do not wake up one day to a 30-minute CI pipeline. They get there through hundreds of small decisions, each one adding a few seconds, until one day someone asks, "Wait, has it always taken this long?"

When things slow down noticeably, the typical response is to throw more resources at the problem. Faster machines, more CI runners, additional engineers. These solutions are expensive, but they do not require much thinking. They treat the symptoms rather than the cause. I wrote about this on the Tuist blog: organizations spend hundreds of thousands on faster hardware when workflow optimization would cost a fraction and deliver better results.

A surprising lack of engineering excellence

What surprises me the most is how many leaders out there are not being strategic about their engineering organizations. The average level of engineering excellence is quite low. Teams work in unproductive setups, and neither the engineers nor the leadership do anything about it.

I spent years at Shopify, and they were unique in this regard. They continuously invested in making things better to stay competitive. Developer productivity was not an afterthought; it was core to how they operated. I thought this was the norm. It is not.

There is also the challenge of measuring developer productivity. The DORA metrics (deployment frequency, lead time, change failure rate, time to restore) gave us a starting point, but they require data that many teams simply do not have. You cannot improve what you cannot measure, and you cannot measure what you do not collect.

The Swift ecosystem's misdirected energy

In the Swift ecosystem specifically, a lot of the collective mental energy goes into things that feel important but do not address the fundamental productivity challenges teams face. There is an endless quest for the perfect architecture. There is excitement about taking Swift to new platforms. There is continuous work to make the language more complex with new features.

I understand the appeal of these pursuits. They are intellectually stimulating. But meanwhile, we have been given the building blocks to improve the foundation we already have. We could reach a point where companies do not need to consider React Native or Flutter because native development offers comparable productivity, including things like hot-reloading that make iteration fast and enjoyable. But here we are, having the same architectural debates we had a decade ago while the competition moves forward.

At Tuist, we spend our days talking to companies about how they can make better use of their resources. It is sometimes frustrating. The data is there, buried in .xcactivitylog files and .xcresult bundles, but it is proprietary, undocumented, and inaccessible. Teams know something is wrong, but they cannot articulate what exactly.

The path forward: intelligence that works alongside you

I am optimistic that things can change. The combination of agents and runtime intelligence creates an opportunity we have not had before. Imagine a productivity partner that runs alongside your workflow, continuously analyzing what is happening and telling you where the slowness is coming from. Not a dashboard you have to remember to look at. Not CI logs you have to parse manually. Not metrics that require a data engineering team to make sense of.

This is where I see things heading. An agent with deep knowledge of your project structure, your build graph, and your test suite. Something that can tell you, "This test has been flaky 12% of the time this week" or "This module is a parallelization bottleneck affecting 40% of your builds." Something that can act on this information automatically, disabling flaky tests or suggesting build graph restructuring.

The technology is ready. The data exists. What is missing is the integration, the translation layer between raw build information and actionable insights. This is what we are building at Tuist.

I believe the Swift ecosystem can get there. It requires a shift in mindset from "this is just how Xcode development works" to "we deserve better, and we are going to build it." The tools and patterns exist in other ecosystems. There is no technical reason why iOS development should be less observable than web development.

The first step is acknowledging that the current state is not acceptable. The second is starting to collect the data. The third is acting on it. If this resonates with you, I would love to hear from you. We are building these tools, and every conversation helps us understand the problem better.

This is a much harder terrain when the audience is developers. Developers are not passive consumers. They are builders with taste, strong opinions, and a high sensitivity to anything that feels like noise. The old playbook still shows up everywhere. Sponsor a conference booth. Put your logo on newsletters. Announce a feature with a press release. It is not that these things do not work. It is that they are tired. The attention is limited, the format is stale, and developers do not find it cool. That is the heart of the challenge.

If attention is contested, then the winners are not the loudest or the richest. The winners are those who earn focus by contributing signal. That is why I keep coming back to the older writings on this topic. Herbert A. Simon wrote that "a wealth of information creates a poverty of attention" in 1971. It is a line that feels more true every year. These are not just academic ideas. They are useful lenses for anyone who wants to build a modern developer business. We are not only competing against similar products. We are competing against all the other stimuli that occupy a developer mind.

Marketing to developers has always been a bit awkward. Many developers have a radar for hype. They are allergic to empty adjectives. They read technical docs and skim the rest. They value peer trust more than corporate messaging. The Cluetrain Manifesto captured that cultural shift in the late 1990s with "markets are conversations." In developer ecosystems it is even more literal. If you do not show up in the conversation as a peer, you are a billboard. Billboards get scrolled away.

The reason I think the old playbook is breaking now is the world of AI. It is not enough to say you are using AI. It is not enough to publish a case study that says you reduced costs. Developers want to know what you are building that pushes the frontier and what role you are going to play in the world that is forming. They want to know how you are shaping the future and whether your work is additive or extractive. To say you are keeping up with AI is to say you are following. Developers do not follow followers.

That means companies need to take a position. Not only a technical position, but a cultural one. What do you believe about how AI should change how we build software. Where do you want to empower users and where do you want to challenge them. What are you willing to make open. What are you willing to let go. In an era of accelerants, a company that does not state a vision gets defined by the narratives of others. Attention will land somewhere, so you might as well give it a north star.

At a personal level this becomes a lot of individual exploration. I talked about this yesterday, and I cannot get the idea out of my head. I do not want my work to be a marketing artifact. I want it to be an exploration, a real attempt, with curiosity and risk. The sharing is part of the process, not a campaign. I share what I do even when it gets rejected or misunderstood. I am fine with that. Some people need time to embrace new models, and that includes me and the people closest to the work. Some people will reject anything that is different. That is fine. I do not want to optimize for the average response. I want to find the people who are curious enough to join the experiment.

That is how I landed on Plasma, which I am exploring as a multi platform agentic coding experience that could replace React Native if we figure out how to hot reload changes, or at least UI. I feel we are stagnated in the mobile space. We are living inside an endless dream of ideas that a few players pushed years ago and then moved on to other ecosystems with more movement. I want to bring something fresh back. I want AI to feel different on mobile too.

This is where attention, marketing, and product become the same thing. If you are doing real work that is ahead of the curve, the work itself becomes the marketing. It is not a press release. It is a consistent stream of explorations, prototypes, failures, and learnings. People pay attention not because you asked for it, but because they see a line of thought they can align with. In other spaces you can find similar dynamics. In music, listeners bond with artists who expose their process, not only the final songs. In open source, people rally around maintainers who show their reasoning and invite the community into the trade offs. In education, the best teachers are not those who broadcast facts but those who let you think with them.

The idea that attention is earned by contribution shows up elsewhere too. In the AI era the medium is not a static website or a blog. The medium is your ability to collaborate with your users in near real time. If your product is not a living conversation, the conversation happens without you. This is why developer tooling companies that ship in public, write technical deep dives, and open their roadmaps tend to earn trust. It is not because they are louder, but because they are more legible.

There is also a cautionary note. The attention economy can distort values. Algorithmic feeds reward novelty and outrage. If you are a company, chasing that behavior is tempting but corrosive. Short term attention can sabotage long term trust. Developers notice when you are extracting attention without giving value back. They will remember.

The tension is not going away. The solution is not to retreat or to yell louder. The solution is to show your work and take a stance. Make your experiments visible. Treat exploration as a product. Let people join the journey. If it fails, that is also part of the story. People do not want brands, they want builders. People do not want slogans, they want evidence.

This is why I am bullish on a more personal approach to marketing. The old model assumed that a company can stay behind a wall while its marketing department speaks for it. That is not how developer trust works. Developers want to know who is building the tool, what they care about, and what they are doing about the future. That does not mean you must be a public figure. It means the company needs to act like a person. It needs to show its mind.

The past has some useful reference points. The Cluetrain Manifesto was a reminder that conversations are the market. These are old references, but their relevance grows as the noise grows. The only thing that changed is the speed and scale of the attention market.

So I am leaning into it. I am going to keep exploring, sharing, and refusing to play it safe. I want to build products and experiments that prove a point rather than pitch a feature. If that earns attention, good. If it does not, I still learned something that pushes my craft forward. That is the deal I am willing to make.

I do not think developer marketing is broken. I think it is evolving into something more honest. It is the era of builders who communicate in the same way they build. It is the era of companies that take positions and put their work on the table. I want to be part of that, and I want my work to be part of the conversation, not a banner on the side of it.

References that influenced this line of thought: Herbert A. Simon on attention scarcity, The Cluetrain Manifesto, Amusing Ourselves to Death.

And it's a lot of fun.

Questioning Everything

Take pull requests. We've internalized them as the way to collaborate on code. But do we actually need them? What if we could run CI locally with a system that cryptographically attests that the checks ran against the exact code being pushed? You'd skip the entire CI queue, the waiting, the context switching. The attestation proves the work was done-why repeat it on a server?

This isn't about optimizing PRs. It's about questioning whether they should exist at all in certain contexts.

Anything is possible, really. Once you let go of "this is how it's done," you start seeing possibilities everywhere.

Follow the Builders

I struggle to process why people say they don't find AI useful. At the same time, I see gurus emerging everywhere-jumping onto courses, offering advice, building personal brands on the AI wave. It's common. I ignore them.

I follow the builders instead.

People who look at the future open-minded, willing to shape something better rather than just profit from the hype or stay relevant. It's a lot of fun watching those people work. Tobi from Shopify posted the other day how he built a tool to process some medical imaging format. Not because it was his job, but because he could. That's the energy I'm drawn to.

The Investment Mindset

I'm spending money on AI. A lot of money on tokens. I finally understand what Peter Steinberger meant when he said this is an investment. It truly is.

But we developers hate paying for things. I used to be like that too. We'll spend hours building something ourselves to avoid a $10/month subscription. We'll fight for open source alternatives even when they cost us more time than the commercial option ever would.

With AI, I've had to rewire that instinct. Every token I spend is buying me time, learning, and capabilities I didn't have before. It's not an expense-it's compound interest on my skills.

An Invitation

If you're still approaching AI incrementally-asking "how can this help me write code faster?"-I'd invite you to try something different. Ask instead: what assumptions am I making that might not need to exist?

Challenge the mental blocks. Question the workflows you've inherited. Look at things with an open mind, willing to throw away what you know if something better emerges.

The people building the future aren't optimizing the past. They're imagining what could be.

Join them.

Let’s start with the what. We can reduce automation to three core tasks that most projects adopt: build, test, and check, where “check” encompasses any validation that doesn’t fall into the first two categories, such as static code analysis or linting.

Build and test are typically defined by the toolchain of the programming language, while checks are heavily influenced by the community. Our editors have evolved to accommodate these toolchains, ensuring a zero-config experience for developers. It just works. This is a question whose answer presents no business opportunity. In fact, attempting to monetize it would be a bad idea, as the community would likely react negatively.

However, for many toolchains, the answer falls short at scale. This prompted the emergence of generic build systems like Bazel, Google’s open-source build tool that aims to make things work at scale. But like any fork from the standard toolchain, it comes with a high cost that only a few organizations can bear. Bazel’s design with rules captures this reality: you’re relying on a small community to keep them up to date, ensuring not just that workflows run locally, but that editors, debuggers, and everything else operates smoothly when developers interface with code through their tools.

This reminds me of the innovation adoption curve in web platform development. Abstractions emerge in frameworks until the platform evolves and pushes innovation down to the native layer, like how modern CSS features eliminated the need for many preprocessor capabilities. Personally, I think no forks are better than forks, but toolchains take time to evolve, so I understand their emergence as a necessary temporary solution.

Now the where, where these tasks run. Initially, workflows ran only in developer environments, then in CI environments, and most recently, in agentic coding environments like GitHub Copilot Workspace or Claude Code. This is where business opportunities emerged: from complete CI solutions like GitHub Actions and CircleCI to companies providing isolated runtime environments.

These solutions align on some conventions, like using YAML as a declaration language, but fragment when attempting to create vendor lock-in to prevent organizations from leaving. They introduce proprietary features like marketplace ecosystems for reusable steps or tightly coupled solutions like caching, as if these needs didn’t exist outside CI environments.

This CI-centric mindset presents organizations with solutions but also creates new challenges. Consider the portability problem: developers cannot easily debug pipeline executions locally. Or the latency problem with Content-Addressable Storage (CAS) caches, a mechanism for storing information that can be retrieved based on its content rather than its location. These caches are optimized for CI where you can co-locate cache servers and CI environments on the same network. But what about developers working remotely? They don’t run their environments in the same network where CI environments are hosted, resulting in higher latency and degraded experience.

These examples illustrate how business opportunities in remote environments created CI-centric solutions that disregard the diversity of environments we have today, and that will likely continue to evolve. Local environments aren’t as monetizable as remote ones, but leaving them out of the design creates a developer experience that’s far from perfect. Any innovation or attempt to fix this feels like incremental patching rather than fundamental rethinking.

Finally, the how. Automation runs in environments, but there’s little to no visibility into how it performs. This visibility is crucial for understanding where opportunities for optimization lie.

This area hasn’t seen as much progress as I’d hoped, with one notable exception: test runs, where consensus built around the JUnit XML format. But what about compilers or build systems? Bazel proposed the Build Event Protocol (BEP) for streaming build-time information, but it hasn’t been broadly adopted. Apple is working on a new build system but hasn’t designed it to stream build telemetry to external services. Teams remain reliant on standard output and error messages to understand their build processes, a limitation that becomes increasingly apparent as builds grow in complexity.

I believe this is going to change, especially with agents that treat standard pipelines more as an implementation detail in the communication between the agent and the environment. Companies offering runtime environments provide telemetry about infrastructure metrics like CPU and memory usage. While engineers appreciate seeing these metrics, and they can be helpful at times, high CPU usage isn’t necessarily problematic. It likely means the CPU is busy compiling your work, which is fine.

What teams actually need to know is whether their build graph (a directed acyclic graph representing the dependencies between build tasks) is making optimal use of available resources. This question can’t be answered without information about the build graph structure and how it’s being processed. The lack of this type of data leads many organizations to optimize the environment before optimizing the build process itself, environment before workflows, when optimizing the workflows would result in a higher ROI.

Where does this leave us? We need a more holistic approach to supporting build systems and test runners. One that’s not coupled to solving only for CI or CI runners. One that doesn’t embrace a mono build system as the solution to all problems, but instead embraces the diversity of build systems and patterns in which ecosystems find themselves.

I think we’re all coming to the same realization from different angles. At the end of the day, all these pieces are interconnected, and only by treating them as such can we provide the best experience. Otherwise, you end up with a highly indirect and convoluted setup like the one Reddit described in their engineering blog, where teams juggle several vendors and solutions while trying to create a cohesive developer experience.

Every company brings its own uniqueness to the solution, and this is something I’ve been thinking about deeply lately. There are two pieces that have been unique in how we’ve built Tuist that can play a crucial role in shaping infrastructure for modern build systems and test runners: community and open source.

Most solutions build proprietary technology and offer either hosting as a service or a license for self-hosting. But I believe there’s a better model that’s more likely to succeed long-term. If you draw a line between technology and service, treating the technology as an open-source commodity for the ecosystem, you’re much better positioned to serve that technology, and developers’ perceptions of you will be very different.

Would you pay Grafana (the company) for hosting an instance or pay someone else? Likely Grafana, right? This is the power of the open-core model, where core software is open source but additional features, services, or hosting are provided commercially. I see an opportunity to apply the same approach to build infrastructure, though I don’t yet know the full shape it will take.

I think the technology should act as a bridge between build systems and test runners to solve the MxN problem we’ll soon face: many build systems and test runners with similar capabilities but inconsistent contracts. This is a classic challenge in system design where connecting M systems to N systems results in M×N integration points, but a bridge or adapter pattern reduces this to M+N connections. We’re already seeing this fragmentation. It’s similar to the problem that had to be solved in global shipping with standardized shipping containers, a revolution that transformed logistics in the 1950s-60s by creating a universal interface regardless of what was being transported or who was transporting it.

I don’t think this bridge has to be Tuist itself, but rather a technology developed and maintained by Tuist. Think of PostgreSQL, a technology whose ecosystem Supabase contributes to and that they host as a service. Solving this problem requires starting from the ecosystems and moving toward infrastructure, not the other way around. Starting from infrastructure naturally leads to a degraded and fragmented developer experience where you’re trying to make your infrastructure work for existing ecosystems rather than serving them.

This approach also requires accepting that some ecosystems might not be ready yet and contributing to help them get there, something many companies see as a waste of resources. First, because the contribution to revenue isn’t direct. Second, because others could benefit from your investment, so many prefer to push proprietary solutions into ecosystems, something that developers are consistently unhappy about.

Ecosystems are perceived as commons, shared resources that a community manages collectively (a concept from Elinor Ostrom’s work on commons governance). They’re something everyone is responsible for improving, not something companies should try to privatize. This is the approach I see many companies taking, and it’s the wrong one. The alternative approach is harder to secure investment for because getting there requires time, and most investors prefer quick returns over long-term ones. But there are investors who understand this game and the sustainable competitive advantages it creates.

I’m spending part of my time at Tuist trying to understand toolchains beyond Xcode: Gradle, Bazel, Cargo, Metro, Vite, Pants. I’m working to identify their capabilities and the common pieces that can be generalized and turned into a commodity, the shipping container of developer toolchains. The Kubernetes of development environments.

I see Tuist’s role becoming two-fold: making ecosystems evolve and bridging the gap between build systems and infrastructure. We’ll first drop “Apple” from the market we’re associated with and expand to mobile development broadly. And why stop there? We’ll call ourselves build and test infrastructure for modern development toolchains. Step by step, embracing ecosystems’ pace and developers’ expectations.

I’ll hopefully start sharing the first experiments from this work soon. In the meantime, we’re getting ready to extend our “what” to Gradle and to solve the “where” for all those organizations that have decided to trust us to scale their development.

Tuist emerged in the Apple ecosystem and has grown into the platform that we always dreamed of building, but building a company has exposed us to the world of markets, and talking about how to position ourselves and what we stand for has become our daily conversation. Markets are fluid, so should we be.
Fluidity is something we are building into our DNA, and decisions like Elixir for our server are a reflection of it. While there are things we still don’t know, and that’s the beauty of building a company, there are things that are becoming clearer and clearer over time.

We don’t see ourselves bound to the Apple ecosystem forever. We are building solutions that can span beyond the Apple ecosystem, and there’s no reason to constrain ourselves to it. We are building infrastructure for productive teams, and we are actively thinking about how the AI world that’s unfolding is creating new opportunities and challenging many ideas that solidified in a pre-agents world.

We also see ourselves going down the vertical stack, something that for many years we avoided, but that became clear is a must if we want to provide the experience that we want our teams to have. But we haven’t figured out the Tuist way yet. While many companies enjoy jumping into markets with competitive pricing and trying to push the prices down, we don’t like that. We enjoy building developer experiences that spark joy, and we have a lot of ideas, but the intersection of that with monetizing those ideas is where things get tricky. At times I think the market in which we move is saturated with ideas, but then I use Linear, which we’ve been actively using for the past weeks, and it serves as a reminder that there’s always space to build something superior if you put enough love into the craft, and that has always driven us at Tuist. We are crafters who just started selling our craft not too long ago, and things just take time.

Ideas take time to emerge, and I’m optimistic we’ll find those models. I’m optimistic because we have built a team and a company culture for that, and because we use our own tools every day, so we experience the same pain that we are solving for our customers. We wouldn’t see ourselves otherwise. We have good taste, even though the last year has been hard for me to accept that with a health issue that kept me very worried and with the lack of inspiration to contribute something meaningful idea-wise, but having gone through that, I feel more back than ever.

We have a strong appetite for doing a lot of things, but we are doing one thing at a time with a long-term mindset as we lay new pieces in the system. We remain open about where things could go, keep converting customers, and look at the markets to figure out where we should position Tuist. Openness remains part of our DNA. I look at companies like Grafana and Sentry as huge sources of inspiration. Companies that proved that things just take time, and that if you are open, in the long term you can easily become a dominant player in the market, and a company with a momentum that’s unbeatable. Openness is something that developers will forever appreciate, and that continues to be avoided because of the fear of being copied.

So we’ll keep building, keep learning, and keep staying true to what got us here. The shape of Tuist will reveal itself as we go, one thoughtful decision at a time. And that’s exactly how it should be.

It is frustrating because there are always more immediate priorities to tackle. At the same time, it is exciting because you can play with a plausible future, start building toward it, and try to get everyone else excited about it too. Let me give you a few examples.

The Mise Moment

I remember looking at the automation landscape on iOS and asking myself why we were still facing the same problems, like Homebrew installing different versions across environments. At Shopify, I had seen a different world where everyone used the same versions, and reproducibility was the norm. Outside of that, nothing had nailed the developer experience.

Nix came close, but it never resonated with me. Then one day Jeff, whose work I had been following since we built the Shopify CLI on oclif, released Mise. I tried it, and it immediately clicked: this is the way.

We adopted it at Tuist, and I even recommended it as the default installation method. Naturally, there was resistance. “Why Mise if I already have Homebrew?” That is normal, but better futures only emerge when you push through that resistance. The way to do it is by socializing the tool, writing about it, sharing tips, and showing the value of Mise through comparison. Over time, the community started picking it up, and now many projects make it their default. Anyone can clone those projects, and Mise will ensure the right tools are present and activated in the system.

Bash Is Fine. The Abstractions Are Not.

Another conversation we have had internally is about whether abstractions for automation are even needed anymore. Years ago, people found writing Bash painful. I never loved it, but I respected it for what it is: simple, portable, and universal.

The real problem was never Bash itself. It was the abstractions built on top of it. Layers that tried to replace the shell with new DSLs, YAML files, or frameworks that re-implemented what Bash already did well. They added complexity, drift, and “one more tool” to learn.

Today the situation is different. With agentic coding tools, you can ask Codex or another model to write automation for you, and it will probably get it right on the first try. That makes plain Bash more attractive than ever. You get the clarity of the shell and the speed of automation.

I believe the purpose of abstractions is to eventually push solutions down to the right layer. In automation, that layer is often the shell itself. If a tool cannot explain why it is better than a short Bash script you can read and understand in one sitting, it probably is not worth the dependency.

The Stagnation of CI Innovation

A more recent realization came when Git forges like GitHub and GitLab began allowing external runners. Around the same time, a CI company criticized us for adopting a model to sustain the project that did not fit their non-supportive approach to open source.

Meanwhile, many customers were telling us that the same company had doubled their contract prices for no clear reason, while offering generous discounts to large enterprises. Innovation in that space had stalled. The only game was price manipulation.

At the same time, new companies started to emerge offering macOS runners that could connect directly to GitHub or GitLab. Something clicked in my head. The innovation here had stopped. They were playing with the value–cost ratio while the mobile ecosystem was stuck in a dream where the most exciting idea was that maybe we did not need YAML for CI. That was wrong.

I like innovation, and when I see it being suffocated, I feel compelled to act. Solving problems that others ignore drives me, and if someone tries to stop me, that only makes me more determined.

The Mental Model

Here is the mental model that I keep returning to. I think it describes a future that is already unfolding.

1. With coding agents joining local and CI environments, it has become critical that solutions are not coupled to any CI provider. Developers and agents should both have access to the same services that pipelines use. Punto.
2. Real innovation will only happen if we have more companies providing macOS runners elastically, based on load and cost, instead of keeping them locked behind CI providers. This benefits not only CI users but also any company that needs macOS environments for creative or development purposes. It is good for users, good for developer tool companies, and naturally, good for Tuist.
3. Like Mise, it is only a matter of time before companies realize this. I plan to act as a catalyst because I am obsessed with bringing more innovation to this space and creating a fair market where competition happens through craftsmanship, not price manipulation. Where are the Linears of this space? We need to build them.

Looking Ahead

I could not be more excited about this new chapter of automation. We are only at the beginning, and it may take months or even years for the shift to be fully realized. At Tuist, our role is to introduce people to these new realities as market dynamics evolve.

What I love most about the software industry is how small things, like “runs-on,” Mise, or agentic coding tools, can suddenly challenge assumptions we took for granted for years. You do not need something big to nudge the industry forward. Sometimes, a tiny design decision is enough to lay the groundwork for innovation.

The seeds of automation are planted. Now we need time and voices to nurture them. That is my responsibility.

Selling is not something new to me. My family owns a cafe in Spain. We sell a common breakfast called churros. When I was a kid, I helped the family on Saturdays and Sundays to earn a few bucks that I could use to buy gadgets. It taught me a lot about the value of money, at a local cafe scale, and also about the importance of treating your customers well and showing yourself engaging, listening to them, and remembering the things you talk about. Once you build a connection that way, they are likely to come back and buy more.

This muscle atrophied for me. I spent years coding, mostly using my brain in logical mode. And sales are not logical. It reminds me of my nerve injury from a year ago, whose recovery consists of ensuring there's stimulation to prevent the atrophy of the connection between nerve and muscle. I think my ability to sell is there, but it needs some work to bring it back. The only way to do so is by using it more and more, and parking the logical side for a bit, which feels uncomfortable at first because that's where I fall back. But I'm getting more and more comfortable with the sales part of Tuist.

As I mentioned, selling churros or selling a tech product to large enterprises are different scales, but some of the ideas map. And as soon as you realize that, you start to notice how many things you were doing wrong. I'll give you some examples.

Tuist is a product company. We go deep and broad understanding problems and building the best craft for them, and we share about it in a way that's magnetic. Developers show up at our door in our community forum and Slack channels. Fun fact: we have sales representatives of CI companies around there, I guess trying to fish from our amazing community. I wouldn't say that we are lucky, but we worked on it for many, many years and we have the dividends now. In sales terms, cold outreaches are not needed. In fact, they are not effective, and Tuist has a strong brand that keeps growing through its community.

But here's where we do things wrong. Once they join, we've traditionally been support-oriented. We answered their questions and that's it. We didn't go deep into understanding what brought them to Tuist in the first place, what are the pain points where Tuist can bring value through a solution. This was our first mistake or a big missed opportunity, and something that we've changed not so long ago. Many of those prospects, as they like to call them in the sales lingo, turn out to be leads, and very happy leads if you hold their hands.

And here's the thing. From what I've seen in many other tech companies, sooner or later they are replaced with sales teams that don't have a technical background, or they learn the basics so that they can sell. While I get it from the perspective that you need to scale your sales, I think this is where you are trading short-term sales scalability for long-term product atrophy. You've become so distant from the people that you build for, and developers are not stupid, they realize that too. On one side, you are not as enticing a product as you were at the time you spoke at every conference, and second, you are so detached from their day to day that you evolve the product reactively, and again, everyone notices it. I'm not sure how scaling of sales will look at Tuist, but we'll aim at having the people that make the product possible right there, in those conversations, and we'll join them, because the expertise is something that's part of the package. Founder-led sales, they call it.

At the family cafe when people stood in the queue, we spent some time talking with them. Of course, you wouldn't talk about their problems; they are just hungry. But you'd talk about life and other things, and those people would likely come back because they felt like they were at home. Now, in digital services, like Tuist is, there's no physical space where those meetings can casually happen, no queue. So you need to build a similar thing, a digital space where those conversations can happen, and a system so that you don't forget about them because we have monkey brains and we can't remember everything, and this is a limitation we need to build a system for. In our case, we started using Attio very actively. We keep track of every conversation, adding ourselves follow-up tasks so that we keep those conversations warm. It takes practice to build the habit. It doesn't come naturally to write down everything you talk about, but it's critical to have that context there so that your follow-up conversations don't become just an "I'm here to do a follow-up" and become more of a "this thing you mentioned, the team has worked on addressing it, and I'd like to talk about where things stand and figure out next steps." Will Attio be with us forever? Maybe? I quite like it, and now we spend some time every day having those conversations. They are very insightful because we learn a lot about them, and it also gives us ideas about the things that we prioritize. And here's another thing: we became much better at prioritizing tasks because we don't waste time building things that we think people would need. At times we do. We've built a culture where we explore new ideas, and this is core to the DNA of the company and the project, but it's crucial that we balance that with solving the immediate needs of customers. For example, I want to start the Okta login from the Tuist login page and not the Okta instance. Something we've been asked for a lot.

So while churros and a B2B service are different things, they share a lot. We show our most human version to every company that shows up at our door. We listen to them, we guide them to a solution for their problems, and we have conversations at the technical level of expertise that they expect. Our sales pipeline has become very effective, and we barely have to do any cold outreach. We write great content, and our community and the value of the content do the rest. This is the company we want to build. It was daunting at first, and I personally lacked a bit of confidence at the beginning, but seeing the accounts we are working with these days, and also the impact we are having on them, I have strong confidence that Tuist is here to stay for a long time and potentially break beyond the mobile ecosystem, which we strongly tied ourselves to.

They all have one thing in common: they take source code and one or multiple tasks as input, then produce some output. This might sound abstract, but at a very high level, that's what we do in them. To do their job, they all have to provision the environment with the tools necessary to complete the work, and you'll likely expect them to do it fast and reliably.

Now, if they all have to do the same thing, it sounds plausible that we could reuse the provisioning and optimization logic across all those environments. Unfortunately, that's not the case unless you're using Bazel, which for many organizations is sadly costly to adopt. Bazel makes the whole graph hermetic, and in its build graph you can also codify the installation of tools necessary for other tasks. In other words, with Bazel, you just need Bazel. This is great and there's a lot to learn from it, but there's a ceiling to the number of companies that will decide to go that route. Bazel, with all its benefits, also takes people away from their build systems and ecosystems, and this is a very high price to pay.

So if Bazel isn't an option, what can we do? You should start thinking of your environments and the interaction between them and your project as a layer that you want to be as thin as possible. The thinner it is, the more portable your project's automation and provisioning logic becomes, and the easier it is to run across the aforementioned environments and others that will emerge in the future.

Let's picture this: Your project has some automation in Ruby, which needs to be present in the system to run it. At the time, you decided that CI pipelines would install Ruby using a step from their marketplace. Because of that, when you task an agent to do some job, it misdetects the version, installs a different one, and the agent comes back to you with a failure. Compare that with using Mise, which we've been huge fans of. The agent just detects Mise and runs mise install, letting it install the right versions deterministically. Voilà! Every environment can just run mise install. It might seem like a subtle thing, but it's a change that makes your projects more environment-agnostic.

As I said, provisioning isn't the only thing you'll need. You'll also want those tasks to complete fast, and at the speed at which code is being written with AI, the volume of code we'll have to compile will grow faster than the speed of the processors we use to compile it. In other words, we'll need very sophisticated caching systems that run close to those environments. Once again, you can couple your project to a solution from a company that provides those environments, like your CI provider, or instead adopt a solution that's environment-agnostic, so that your coding agents can also benefit from it instead of just your CI environments. This is why I believe strongly that Tuist's model of offering cache in an environment-agnostic manner is the right way to go in an agentic world.

The last piece about environments has to do with telemetry. How do we know the job was executed, and how do we debug issues when they arise? If you think of a local or remote CI environment, that's usually through the standard output and error messages that the toolchains you use emit. This can go a long way, but in a world of agents, the lack of structure or visibility over internal tasks can be detrimental to agents' ability to debug their work. Take xcodebuild, for instance—its raw output is too verbose 95% of the time, but when issues happen, you (or the agent) wish you could go deeper. Or not just when things go wrong, but when you notice slowness.

Telemetry is sadly not as common as cache is becoming, but I think it'll come, and infrastructure will be needed for that. The only product I see moving in a good direction there is Dagger. There are many things I don't like about its concept, but how they're able to live-stream and present you with an HTML version of your build that works live, and where you can go deeper to understand what happened, is a much better version than scrolling through a pile of standard output messages.

Will this be a one-year thing? Or maybe two? Who knows... but I think the time will come and the infrastructure will be needed.

Cache is one of our best-sold features and very instrumental in turning Tuist from a community-grown open source CLI into an open infrastructure for mobile developers. Who doesn't want faster builds, right? However, our implementation required teams to use generated projects, and this migration was only justifiable for large companies, so our reach was limited. We knew Apple was working on transitioning Xcode's build system and its derived data approach to a model similar to Bazel's, and that this would open the door for cache for everyone. We knew it was something to look into, and that it'd take years to reach the performance of our cache, but seeing other companies jump into it was a wake-up call for us.

I covered this in past blog posts, but the CI landscape is evolving rapidly. Many companies now have the incentive to provide elastic ephemeral Linux and macOS environments that can plug into GitHub Actions and GitLab CI as runners, resulting in better and cheaper environments. This shift means teams have more options than ever before. To differentiate, many providers are exploring additional value-adds like cache or competitive pricing. We've seen various approaches to this, and it's exciting because competition fosters innovation. This motivated us to dive into what we know best: reverse engineering Apple's tooling internals.

It took us a couple of weeks to have not only a functional version, but one with a great developer experience that would make it easy for anyone to adopt from any environment. In a world where environments are getting cheaper, we believe it's important to decouple the environment provider from the service provider and not discriminate based on developers' environments. They are environments at the end of the day. Throughout this work, we realized a few things.

The CLI, in which we invested for many years, and everything that makes it possible, including our open API and our OAuth2 authentication workflow whose session is automatically managed in the environment, plays a crucial role in bringing Tuist's value to the edge. We meet developers where they are. Our design philosophy centers on the command line, which feels natural for developers regardless of where they run their workflows. It's been 9 years of investment, and it's paying off.

Second, and as Marek pointed out in the blog post, there are improvements with the new cache capabilities, but they are modest compared to what you can achieve with what we call module cache at Tuist. We decided to take a transparent approach with a technical deep dive bringing clarity to how it works, how we've done the benchmark, and opening it up for anyone to get familiar with and, why not, even contribute to swift-build. We see learning and sharing as something positive, and we'd rather invest in the infrastructure that's needed to make it possible. We believe openness is a long-term advantage.

Last, and this is something I touched on in the context of making the code available, with this piece more value shifts to the infrastructure. The challenge will be more about how to bring the latency down than building a gRPC server itself. We'll spend the following months researching and investing in a multi-level cache that can serve assets as close to the environment as possible, even from local or private networks. Sure, we'll never be able to compete with the speed of I/O against a mounted volume in a CI environment, but as Apple improves the capability, we'll make it good enough that the value will outweigh the cost of being coupled to a specific provider. This is especially important in an environment where more companies are providing CI environments that you can plug into GitHub Actions and GitLab CI.

It's exciting times for faster and more reliable incremental builds that span across environments. Apple is building the foundation, and we are building the environment-agnostic infrastructure that not only gives the foundation superpowers but gives teams the agency to take back control over where their workflows should run. We'll also invest in collecting and presenting you with the best and most useful insights so Tuist can be your best buddy as you scale your Xcode app development.

This is something I’ve been thinking about for the past few days while using Linear, a project that shows there are product builders who still place craft front and center and build products that are a joy to use. They do AI too, and likely use AI to build the product, but you don’t see its quality being compromised. Compare that with the many projects popping up that let AI decide the product experience and design interface. They all look the same, with UIs that scream not to use them. A bit of this already started happening when the internet filled with Tailwind components that people copied and pasted to build component kits upon. The models learned from this and now prioritize it over standards, spitting out the same components that everyone uses to build their SaaS.

I get it. You’re a developer, can’t afford to hire a designer, and you want your creation to look good enough. So you trust AI with the uppermost layer that people will be interfacing with all the time. Perhaps that’ll lead you to revenue you’re happy with, or it’s good enough for validating an idea, but as I said, your product will look like the many other similar products that have come from the AI factory. You likely review the code written by AI before putting it into production and lean on your seniority to make some judgment and tweaks, but you don’t do the same with the design.

Some people might be okay with that and enjoy using those products. I don’t. There’s something unique about interacting with very well-thought-out craft. Perhaps AI models will develop this attention to detail in design, but I doubt it. I think there’s something about it that can’t be captured by statistical models. But who knows, maybe it becomes too creative, with hallucination as a feature, and comes up with designs humans wouldn’t have thought of. Anything is possible. But today, nothing that comes from it is something I have joy using. I open the website and leave right away.

It’s hard to disregard capitalism in all this conversation. It’s true that our tech industry is the software industry embedded in capitalism, and as such, the ultimate goal is optimizing capital. Without enough care, this can lead many to compromise the quality of what they build. We’ve always seen that, and we’ll continue to see it in the tech industry and many other industries. However, there will always be people and companies that reconcile with the world and place craft excellence above everything else. That’s the reason why we have companies like Apple or Linear, and why consumers lean toward buying an iPhone. Imagine if its software and UI were vibe-crafted without an eye on the final result. Sounds like a recipe for disaster.

So where does this leave us? AI is a tool, and like any tool, it amplifies the intentions of those who wield it. If your intention is to ship fast and move on, AI will help you do that, but the result will show it. If your intention is to build something people genuinely love to use, AI can still help, but only if you apply the same critical eye to the output that you would to any other part of your craft. The choice between speed and quality has always existed. AI just makes that choice more visible, more quickly.

I find this situation unfortunate. Spain has tremendous potential and doesn’t deserve sweeping generalizations. While there’s always room to streamline employment processes, this challenge isn’t unique to Spain. Germany, where I believe Vercel maintains a legal entity and office, presents similar or even greater bureaucratic complexity. Yet framing the company as a victim of the system may obscure a more nuanced reality. Companies naturally optimize for revenue versus cost ratios, and this is fundamental to business.

Europe represents a significant market opportunity, and establishing presence here opens doors to substantial revenue. However, the equation includes another crucial variable: risk. Companies entering new markets often aim to minimize this risk while maximizing returns. We’ve seen similar patterns before. Shopify established their German entity to access EU talent at competitive rates, but later withdrew most operations when employees began organizing.

This pattern resembles what researchers call “institutional arbitrage”: companies seeking favorable conditions across jurisdictions while avoiding less advantageous aspects. Research on corporate social responsibility shows that sustainable business practices, including respectful engagement with local regulatory frameworks, correlate with long-term value creation. Rather than viewing regulations as obstacles, successful global companies recognize them as frameworks that enable stable, thriving markets.

Many business leaders approach market expansion seeking benefits without corresponding responsibilities. A more constructive approach would acknowledge specific tradeoffs. For instance, a CEO might say: “Spain offers X advantages but presented Y and Z challenges compared to our German operations.” This builds understanding rather than discouraging investment in countries with exceptional talent pools.

The world’s diversity extends to business regulations, and navigating this complexity is inherent to global operations. While continuous improvement is valuable, embracing these complexities represents an opportunity, not just an obligation. Leaders in positions of influence can advocate for constructive regulatory evolution with evidence-based proposals rather than broad dismissals.

Founders like Guillermo and myself create employment opportunities that channel capital into economies. Equally important is ensuring employee protections remain robust. This requires legal frameworks we can’t simply circumvent. Exploiting regulatory gaps for competitive advantage ultimately harms the countries we operate in. This approach warrants rejection regardless of a CEO’s accomplishments. Success doesn’t grant exemption from local systems or preferential treatment.

As a CEO, I experience these challenges too. I’ve always viewed them as integral to company building. They represent the interface with systems that enable flourishing societies. Research on stakeholder capitalism demonstrates that businesses considering broader stakeholder interests alongside profit achieve more sustainable growth. Without these frameworks, we might see improved GDP figures, but we’d also see widening inequality, with essential services like healthcare and nutrition access becoming luxuries rather than rights.

I absolutely support streamlined processes and enhanced startup support. What concerns me is adopting a victim stance with unsubstantiated claims. Employment legislation exists for important reasons, and global expansion requires understanding these nuances and determining whether they align with your business model. If they don’t, that’s a legitimate business decision. Our diverse world offers various paths. If operations prove easier in country X, establish there and use Employer of Record services to access talent elsewhere while managing complexity.

Let’s avoid blaming countries rich with talent and potential. Such rhetoric helps neither the country nor the company. Instead, we can acknowledge challenges while recognizing opportunities, building bridges that create value for everyone involved.

Tuist builds on an open source foundation, which naturally influences how we share Tuist with the world. Yet, we continuously look at what other companies in our space do to see if there's anything we can learn from them. We're also budget mindful, which forces us to be creative. I'll share some examples of patterns we've observed and the approach we've chosen instead.

I've noticed companies often take the path of heavy advertising. They put their logo in every conference, newsletter, website, or billboard. I think this can definitely contribute to brand awareness, and for some companies it works well. But for me personally, when it's too much, it doesn't create a deep connection. It also depends on the engineer you're targeting. If the ads package an aspiration towards a lifestyle (like gyms typically do, pressing the right buttons), then sure, it might resonate deeper. But not every company can afford playing that game because it's not compatible with what they're selling. What lifestyle can I attach to making your developers more productive? Tricky, isn't it? I have to admit I've seen companies go a long distance with this approach and be effective at materializing it as contracts. It's a valid strategy, just not the one for us.

Sometimes this approach can shift focus toward doing things so you can talk about them in marketing materials, rather than focusing deeply on the problem or the solution itself. This can manifest in blog posts and case studies that stay high-level, skipping the technical details engineers would actually like to read about, and webinar after webinar with guest speakers. This approach works in many industries and for many companies. But as engineers, we're very logical people. We spend our days thinking logically, and we like to understand the why of things. Even when we're asked for money, we want to understand the value deeply because we're used to so much being free. Our Linux OS in which we run our NodeJS application is free. Our frameworks are free too. The programming language too. So we naturally ask more questions before committing.

If I had to define a camp in which Tuist sits, I'd put us with PlanetScale, Fly, Linear, and the companies whose members and founders have a deep passion for their craft and share it openly. The connection is made by sharing deep thinking about their problem spaces and their visions, not just surface-level features. Developers respond well to this. They like to be challenged. They like to be presented with new takes on problem and solution domains they haven't heard before. They like when the person talking to them speaks their same language and guides them through the logic behind a product. This is how most of us at Tuist build trust with products, and this is how we see users building trust in us.

The reason I'm bringing this up now is because the mobile development tooling space is evolving rapidly. Organizations are exploring different CI solutions, finding what works best for their specific needs. More companies are entering the Tuist space (welcome), the more the merrier. As this happens, I naturally pay attention to how different companies present themselves. I've noticed some taking the marketing-heavy approach I described above, focusing on feature announcements without diving into the technical depth. When I read those announcements, I find myself wanting more. More details about the state of the art of caching within the world of Xcode, the challenges, the opportunities, what we should expect long-term.

For us at Tuist, we've chosen a different path. We want to share not just what we build, but why we build it, the problems we're solving, and the thinking behind our solutions. It's the approach that resonates with us as engineers, and we believe it's the right way to build lasting trust with our community.

If you ask me, this is problematic, but at the same time creates an opportunity for Tuist. I believe there are several reasons why we don’t see teams having more observability over their setups:

• The data is often proprietary, like activity logs or result bundles, which requires additional community effort. For instance, Spotify built XCActivityLogParser & XCMetrics back when they were not using Bazel, but they no longer have incentives to maintain it.
• The data is also not accessible. Everything is designed to be extremely coupled with Xcode, resulting in data that’s hard to find or parse because nothing is documented. Xcode is closed source, so a lot of that work involves reverse engineering, like we had to do with Xcode’s project format.
• Even with access to the data, it’s not as valuable as when combined with other data or analyzed over time or across environments. This requires pushing the data to a database and making it accessible through visualization tools like a dashboard or Grafana. This was XCMetrics’ original motivation, but it faded. This likely means mobile teams have to investigate or collaborate with their backend teams to deploy, maintain, and keep a service up to date, which suddenly becomes a new responsibility for the company, distracting them from the business. We’ve also seen companies treating it as a hobby project (“let’s open source a backend in Vapor”), which is a fun exercise—I’ve done it myself too—but then the driver leaves the company, and the company finds itself with a business to run and open source to maintain.

This is the sad reality of Xcode development. Many developers find it acceptable. I don’t. And even sadder, Apple isn’t giving up on their proprietary and closed formats. Their new build system has no traces of making it extensible like Gradle is to provide access to data at build time. Or maybe some kind of telemetry built in with OpenTelemetry such that teams can plug their data pipelines into it. Strategically, nothing has changed at the tooling level, which again, is good for Tuist.

Teams should know where the build parallelization contention points are. They should also know which tests take the longest to execute or which ones are the most flaky. They should have a system to flag and disable flaky tests, or to debug their workflows on a website without requiring anyone to install Xcode in their environments. The web is the ultimate expression of accessibility, and they continue building against it.

So if this resonates with you and you’d like to bring that observability to your Xcode projects, let me know. You’d be surprised how much you’d suddenly know, and it’ll just make optimizing your setup easy and make conversations with leadership less uncomfortable. We take care of the annoying part of understanding proprietary formats, persisting them in a more standard and documented format, and making them available and actionable to you.

Picture this: At some point in the process of scaling your organization, you might find yourself with large codebases—for example, monorepos—with inter-dependencies between various components and the need to be selective about what you run and where you run it. During my time at Shopify, they spun up a team dedicated to test infrastructure whose role was to become more selective about these things. At some point, you'll be constrained by running things on a single machine, and you'll want to distribute the work across several pipelines as some kind of sharding. But you'll be very limited by the pipelines, which are quite static. You can't simply say, "From this CI job, spawn X jobs, which I've calculated based on data from my build system, and then aggregate the results back." The only company I know that has gotten close to this is Buildkite, but most others continue gravitating around the YAML-as-a-pipeline building block.

Take tests in iOS that require a simulator. There's a limit to how many simulators you can run per machine, and this is an OS limit because every iOS simulator runs in the system as just another process consuming system resources. There's a limit to how many file-system processes and file handles can be opened—a classic example of resource contention. On modern Apple Silicon, that number should be around 12, which means in the context of running e2e tests (which are slow by nature), you can run at most 12 simultaneously. That's not bad, but what if you have 40 or 80 tests? This adds up very quickly. To fix that, you'll consider sharding, and the sharding is likely codified in your YAML with some runtime logic. However, the number of shards is fixed and something you can't control dynamically, so you'll likely take the list of all tests and distribute them across shards following some logic. Wouldn't it be amazing if the number of machines were something you could control dynamically? It turns out that environment providers like Namespace can scale elastically, so if you have the budget for it, you can throw money at the problem and find your sweet spot dynamically.

Another interesting use case for dynamic pipelines is determining what needs to run based on changes and then distributing that work across different machine specs. Let's say a build system determines there are a few Ruby tests to run and some Rust ones based on changes in the monorepo. For simplicity, Ruby has a native piece built with Rust for some business logic that's CPU-bound. The build system could spin up two machines with different specs because the needs of those tasks are very different, so the machines should be too. But note that this requires the build system and CI provider to work in harmony, and this is quite tricky—a coordination problem that exemplifies Conway's Law, where the structure of your toolchain reflects your organizational boundaries.

Bazel has all the build information necessary to do this, and there are companies that provide infrastructure for Bazel. However, Bazel means replacing your build system, which is very costly for organizations. On the other side, there are companies like Namespace that have the infrastructure and could plug into build systems and monorepo build tools. But none of those tools have been designed to contract with remote executors in the same way Docker does, where you can decide to build remotely and it really feels local. Imagine if the build tool you use had this capability built in, where you wouldn't have to keep a YAML file up to date or push changes, but could interface with it directly from your local environment, simulating how the pipeline would be inferred and executed. Dagger is one of the closest to this model, but it builds on virtualization, which comes with its own set of tradeoffs and doesn't work well with models like iOS builds, where virtualization isn't cheap.

So I don't really know what the answer is, but it would be amazing if a protocol emerged between companies that provide environments, like Namespace, and the build systems that might want to run things remotely. Perhaps there's an opportunity here for companies to define a standard that would prevent forcing organizations into a one-stop-shop type of build system that's costly to adopt.

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.

For many people today, Tuist is a project generation tool, and for some in that group, we are an unnecessary abstraction because SwiftPM is just fine. But the reality is very different from that. Tuist is a platform to address challenges of scaling app development with Apple's toolchain, and only a subset of those challenges requires project generation, an abstraction upon Xcode projects, to solve them. Those challenges are modularization complexities and slow compilation. We are the first ones who would avoid abstractions if we could; in fact, we peel them when they are no longer needed, like we recently did by telling people that if they are using Tuist to minimize merge conflicts, that's not really needed. However, in some cases, an abstraction is unavoidable, and Xcode's terrible derived data decision or inability to optimize the build process left us with no choice. Perhaps your project with few modules declared with SwiftPM is just fine, but when you grow that into hundreds of modules and it takes 1 minute to index the project, or 15 seconds to delete a file from a project, then I don't know about you, but this is not a nice setup to work with. Perhaps it just takes experiencing sustained pain over time to look at the need for abstraction with different eyes.

An image from Bumble's benchmarking that shows the differences between using a vanilla Xcode project and SwiftSPM

As I said, we are evolving Tuist to be more of an extension that you plug into your Xcode project and toolchain. It's an extension that takes just a few lines to integrate. For instance, if you want to get build insights like those that we get for the Tuist project, all you need to do is add a post-action to your Xcode project scheme, and you are good to go. Or selective testing, which you can adopt in your Xcode projects by just prefixing your xcodebuild invocation with tuist. Now, you might not want to depend on or even pay for third-party tools, and I'd understand that too, but once your project reaches a certain scale, I'll tell you that you'll experience a regression in developer experience that Apple won't support you with, and you'll be alone there. I've seen that many times, and it was hard for developers. From companies adopting React Native to others replacing the build system entirely, the pain was much stronger than the little cost that a non-official abstraction like Tuist could have brought to your project.

A screenshot of the Tuist's dashboard where you can see build insights from the Tuist project itself. The data that we show includes for a period of time: the number of builds, the number of failing builds, the average duration of builds.

The journey we're on is about making Tuist invisible when you don't need it and invaluable when you do. We're building a platform that respects your existing workflow while providing escape hatches for when Apple's toolchain shows its limitations. Every feature we add is designed to be adopted incrementally. You don't need to rewrite your entire build system or learn a new paradigm. You just need to recognize when the pain has become unnecessary and know that there's a solution available.

We understand that not every project needs what we offer today. But as your codebase grows, as your team expands, and as your build times stretch from minutes to hours, remember that these problems aren't inevitable. They're solvable, and we're here to help solve them. The abstraction we provide isn't about replacing Xcode; it's about making Xcode work better for you at scale.

Our vision is simple: no developer should have to choose between staying native and having a productive development experience. With Tuist, you don't have to.

Ultimately, choosing proprietary formats is a way of increasing vendor lock-in between consumers and the product, and by extension, the company behind it. The European Union has implemented measures against this, requiring that users can export their data and take it elsewhere. But if the data format itself is proprietary, why would I export it in the first place?

When you decide against a standard, you're also deciding against interoperability. You make integration so painful for your users that they'll eventually accept the extra pain and seek more interoperable alternatives. Sometimes standards don't exist, and that's completely normal. But when they do exist, neglecting them is a complete mistake.

Take Notion, for instance. I'd never use it, no matter how many features they offer. Any rich experience layered on top of text feels unnecessary to me, and the marginal value compared to the cost of using some proprietary format (god knows which one) simply isn't worth it. I'd rather keep my content in plain text files using standard Markdown. It turns out LLMs love Markdown too. What a coincidence, right? You don't have to wait for Notion to open an MCP API that converts their proprietary format into Markdown for LLMs to understand. You see? The cost is high.

Or consider Tailwind. Everyone loves it. They've managed to get LLMs to generate Tailwind classes everywhere. But it's not a standard. It's a proprietary language with developer experience add-ons, when you could just write plain CSS, use CSS variables for configurable designs, and leverage modern CSS nesting if specificity is an issue. No need to rely on proprietary formats.

In the context of Tuist, we're thinking deeply about leveraging standards that backend teams have traditionally used to help teams understand their projects, builds, and perhaps eventually their apps. Take OpenTelemetry (OTel), a standard people use to add telemetry to backend services. What if Apple's new unified swift-build exported telemetry data using the OTel standard? Wouldn't that be cool? You could use any of the many available collectors and visualize your data in Grafana, which has built-in support for OTel. Instead? This isn't even on their roadmap.

Swift SDKs for OTel exist, so imagine if we leveraged our infrastructure and API to store apps' OTel data, allowing users to observe their apps using the tools they already know and love, like Grafana. They wouldn't have to rely on any proprietary tool. And if they don't like Tuist? They can switch.

I don't believe people should stay with a product because you've vendor-locked them into a system filled with proprietary decisions. They should stay because you've built the best and most fairly priced solution. This is why I'm excited about the concept of runners as a service plugged into CI systems (e.g. Namespace). Whether we like it or not, we're trending toward Git forges' CI solutions becoming the standard, with a standard contract for plugging in runners. This way, you don't have to migrate away from CI providers whose businesses are sinking and who resort to proprietary gimmicks to stay afloat. Like, "Hey! Design your pipeline in our proprietary visual editor, choosing steps from our proprietary marketplace." Fuck that. Give me a standard YAML that's well-documented, that I can ask LLMs to write, and reusable steps in open-source Git repositories that are easily pluggable. This is the way. I'd never go back to any CI provider, and you probably shouldn't either if you want better and cheaper CI.

We're now building Tuist QA, and we're adding an option to export QA session results as JUnit format. It's the closest standard to what we need, and if you want to use that JUnit output with your test analysis tools, go for it.

Recently, I've been exploring Grafana for observability of our production services and the product itself. It blew my mind when I realized that panels and dashboards follow a standard, serializable schema that's well-documented and that LLMs understand. I can provide our ClickHouse and Postgres database schemas to an LLM and ask it to generate entire dashboards or panels. Within seconds, I have everything we need. We'll get there too. Our API has a publicly available OpenAPI spec, and we want to expose more read endpoints and simplify authentication so LLMs can access it and provide useful responses to users. Some of our data is proprietary to Tuist's domain because no standards exist for it, but wherever possible, we'll adopt standards. For example, by exposing data that overlaps with Prometheus or OTel specs in those formats.

The best products embrace standards and put users first. Those that don't feel more like Berlin before the wall fell. They'll throw money at luring users into closed ecosystems. We've seen CI providers do this for years, claiming to be "platforms" (like "Mobile DevOps") that are just vaporware. But sooner or later, the wall will fall, and when it does, it'll hurt hard.

Since most B2B revenue comes from large enterprises, it makes business sense to focus on them. And it's true that some enterprises might not prioritize elegant product design as long as their immediate problems are solved. But if you ignore thoughtful product shaping, you'll end up with a convoluted mess—a heterogeneous collection of tools that lack any cohesive narrative or intuitive user journey.

It's similar to "vibe coding" in a way. You can vibe-code an entire SaaS product, but you must ensure that each piece integrates seamlessly into the whole. Otherwise, you'll find yourself constantly hacking new features onto existing layers instead of building a coherent system. Many developer tools fall into this trap, but at Tuist, we refuse to accept it.

We believe every component should harmonize with the broader ecosystem, playing a role that evolves alongside our vision. A CLI that generates projects transforms into an interface for an integrated developer dashboard. QA teams use previews to test their colleagues' work. A single line of code in an Xcode project seamlessly connects your environment with Tuist. Product shaping is continuous work that enterprise customers actually appreciate because it makes the product a joy to use—and who doesn't want joy? There's a reason we prefer Apple products over alternatives, or why we choose Mise for environment management instead of juggling multiple disconnected tools.

A great product doesn't need to be littered with "Contact Sales" buttons or limited to restrictive demos with fake data that fail to demonstrate real value. Design shouldn't be an afterthought or heavily influenced by sales strategy. Exceptional product craft and successful enterprise sales are completely compatible—it's just that some founders treat the product as merely a means to profit. We see product excellence and business success as two elements that must dance in harmony to deliver the best value to all our users (enterprises included) while capturing fair value in return.

Then things started getting worse. The query drops escalated to HTTP request drops, and we became increasingly suspicious of our infrastructure. For those unfamiliar with why pools are necessary on the server side: they’re tools that keep connections warm and ready to execute queries or requests, avoiding the latency of initial handshakes and the overhead of establishing connections for every request. This is particularly important for Tuist, where we have a highly concurrent API surface, especially our cache endpoints. Despite numerous unsuccessful attempts to get our cloud provider to investigate their network infrastructure, everything went sideways. First, the server became unhealthy twice due to running out of memory. Later, it became extremely slow—so slow that some client features would fail. This happened despite Erlang’s fair scheduler, which can schedule work even when the CPU is extremely busy (for example, if you enter an endless loop).

What could have caused this? Suddenly, it all clicked, and we finally understood the pool issue. Our outbound requests were too slow—not just requests to the database for queries, but also those to S3 for uploads. At the database level, where we’d optimized many things so that high concurrent API load doesn’t translate to equivalent database load, we only saw sporadic drops. But in our S3 storage pool, this translated to a few requests executing while thousands waited to be assigned (consuming memory), the CPU struggling to assign them, all while continuing to receive more requests added to the pool. Our server couldn’t respond to requests in time because there were no CPU cycles available.

What started as sporadic drops long ago was already signaling that something was wrong with our network. Sometimes slowness is self-inflicted, but in this case, it wasn’t us—we only realized this once everything fell apart. We had numbers to prove to our cloud provider that something wasn’t working as planned, but we never anticipated that the issue would snowball and take down our entire service.

So yes, when your pool speaks, stop what you’re doing and listen to it. In our case, we switched to another provider following Chris’s suggestion, and things improved instantly. We also configured our pools with lower timeouts to prevent resource clogging, and we’re defining alerts that can automatically declare incidents when we detect upward trends in response times. It’s been a huge learning experience and also a relief to start each day without a handful of dropped connections from the queue.

I feel confident that both our infrastructure and the app running on the amazing Erlang VM are now ready to handle much heavier loads.

Tuist's strong focus since its inception has been native development for Apple platforms. And by native here I mean without any runtime abstraction like React Native or Flutter. We know the ecosystem well, we have a presence in it, and we feel very comfortable exploring problems and building the best solutions for them. We are not closed to navigating that dimension by taking our solutions to Android, and potentially abstractions like Flutter and React Native, but the time is not now.

The other dimension is the lifecycle of app development. An app can be broken down into features and dependencies between them, and features usually start with an idea that navigates through different phases, in some of which Tuist supports you.

Development

This has traditionally been our area of focus. We extend the native toolchain with solutions to make your job easier and faster as a developer. From project generation that makes managing projects a breeze, to binary caching and selective testing to speed up build and test runs. It turned out there are no companies interested in tackling this problem space for the Apple ecosystem, leaving us with a huge opportunity to build a financial foundation that we can then use as a lever to step into the next phase of app development.

If you think of some solutions that are making their contribution to this space from the angle of AI, we have agentic coding tools like Claude Code, Codex, or the many live coding platforms that are crowding the space quite quickly. We thought about exploring that space too, but it took us a bit of waiting to realize it wouldn't be a great idea. At least not today.

Validation

With the feature built, the next phase is ensuring the work is right, and that usually implies tests, and some kind of automation to run those tests automatically as a result of pushing the code upstream. CI. We thought a few times about doing something in the CI space. Companies that like how we support them in the development phase showed interest in trying anything built by us in this space, but similarly, it took us a while to make some realizations that are key, and about which I already talked about in the past. TL;DR:

• CI orchestration has been solved by Git forges (e.g. GitHub Actions), and this is making Mobile CI providers lose customers
• The "pay for runners" is the new and better model that leads to better pricing and services
• We just don't like managing Mac infra. We prefer building on it.

So we concluded that CI is not something we'd want to do. We were already doing something in this space with selective testing, but as we thought about automated tests, we came up with the idea of Tuist QA, which I talked about yesterday, and I think it's damn cool. By talking to customers we've also learned that sharding of testing, and infrastructure for snapshot testing are another two areas where companies have traditionally invested resources, and that they'd outsource if there was a company that managed those things for them. We'll get there, but the idea is already in our heads.

There are other forms of validation that you can't catch until the app is built, and for that we built bundle analysis, which allows you to catch regressions in bundle size and ensure the app that you ship to your customers is as small as it can be. As you've probably noticed at this point, in development, our problem space centered more around how to make developers more productive. The validation phase centered for us more around how do we make sure that developers are shipping the best apps?

Releasing

This is another territory that we've mentally explored. I was part of building Shipit Mobile at Shopify, and the impact that it had internally was immense. And now that we've invested in integrating with Namespace macOS environments, we can make release automation fully CI-independent, breaking away from many existing models that require having a pipeline that builds and pushes the app. This might sound like a tiny thing, but it's not, because it leads to a much better developer experience, and a lot of control for us to build much better experiences, like a release process on the go.

The idea and the appetite are there, but as I mentioned before with other features, the time is not yet right.

Monitoring

Once the app is in the wild, we need to monitor if the app is doing well, and potentially make decisions, like doing a hotfix release that fixes a severe issue. In this territory we step into error tracking, and speaking honestly, it's the territory where it makes the least sense to step into, because error tracking platforms have done this for many years, and have much better products that are hard to compete with. But hey, never say no! PostHog started as an analytics platform, and not too long ago they added error tracking into their product. The integration of a built-in solution with the rest of the product can lead to much better and specific solutions that wouldn't be possible with solutions that are too generic. They'll likely not go the extra mile of building a solution that has knowledge of a specific platform.

Stability is not the only thing that you might want to optimize for. What about performance? Performance of the loading of the UI? What about logs? Or sessions of the users in the app? Compared to the previous phases, before we do anything in this space, we need to have a very solid service and infrastructure that can scale well. It's not the same building infra and services that support X developers per company as supporting X users per company's application. From the legal standpoint, we are more liable because we'll be dealing with more sensitive data, so monitoring the apps, though on our radar, is something we are holding back on a bit.

One more thing... the product (runtime)

There's one third dimension that would be awesome if we could ever get to. The first two dimensions had the development of the product as a target. But what if the target was the product itself? What if we provided infrastructure for the product itself by leveraging our infrastructure? For example, analytics for your product, since most solutions center around websites or web apps, or product feedback solutions? Or maybe tools around subscriptions. These are just some ideas.

We have ambitious plans for Tuist, and a lot of blocks that we are slowly connecting into a cohesive vision to turn Tuist into infrastructure for mobile app developers. Our name doesn't constrain us to any problem space, which gives us the flexibility to evolve our vision, and the only constraint today is really capital. Executing all the above vision takes a lot of resources, and a lot of time, but we look at this constraint as something positive, because it helps us be very mindful about what the next step is going to be, and when it's very clear we just take it. This prevents jumping into areas too eagerly, and that's the reason why we didn't jump into building a Lovable for iOS or trying to solve CI for mobile. They just don't make sense.

For many many years, the model was, you need a Mac mini? You pay for it and keep it for at least 24 hours. If you need two, then get the second one, and same story, keep it for 24 hours. As I mentioned, this is a legal requirement by Apple. But it's annoying, especially if you can't predict the demand of environments that you are going to have. I don't know if tomorrow I'll need 1 or 2, or 20, that depends on many things that are out of my control. I remember chatting with a Tuist user who said that their CI provider required them to estimate how much workload they'd have. My immediate question was, how do you calculate that? The answer was, well we give them ballpark numbers. Some CI companies could eventually afford a more elastic model where you'd pay per usage, in fact GitHub Actions did it, but very understandably pricey. Still, there was a bit of light that we'd see a similar model outside of the CI spaces for companies like Tuist, where we need a platform upon which we can build a solution with elastic demand. The first feature we started to think about was Tuist QA. We don't want to build a system that predicts and demands for more or fewer Mac Minis ahead of time. We wanted a system where we could ask for a Mac Mini, use it for as long as we needed, then shut it down, and then pay for it. How that Mac Mini is then reused, I don't care, it's your business, not mine. And not only that, but give me an API that I can use. I call your API, I get a Mac mini asynchronously with SSH access to it. I'm done, and then I call another API for you to take it back. And in case shit hits the fan, just allow me to set a timeout to shut it down automatically. Why doesn't such service exist? It turns out it exists, and it's Namespace.

When I came across it, Namespace was too good to be true. Exactly the developer-friendly API that we were looking for. A company that operates at the scale that we needed for that elastic demand, and an extremely talented team that cared about the product and how their customers would use the product. We got in touch with Hugo & Eva, and they set everything up for us to start building Tuist QA on top of it, and it felt such a joy to use. Few companies go the extra mile of nailing developer experience, and I think Namespace has gone that extra mile. It reminds me of companies like Fly.io, who made scaling services into new regions as easy as running a command like fly scale count --reg mad 2. I guess you understood what the command does without me telling you about it. I don't care about what it takes to proxy the requests to that new region, but I trust you'll do a good job. The same happened here, I don't really care about the limitations. I just care about getting and returning a Mac. MacStadium could have built something like this, but they missed the train. You can tell the team at Namespace has extreme attention to great product and it shows.

So as you might have guessed, our Tuist QA builds on it, so will other features, like signing on the fly, which we'll build down the road. Building on the service and getting support from their team has been exceptional. They recently told us they built a solution where they could bind the lifecycle of a machine to the lifecycle of a containerized runtime process, and it felt like they had been reading our mind. It's exciting to see DX innovation in a space that seemed to have succumbed to just CI as the only consumer of those environments. There are many companies like Tuist that will have a need for these environments for more than just CI, and this is going to be particularly relevant in the world of agents, where some operations might need to run remotely in sandboxed environments. Namespace is well positioned to take a big chunk of that market, and I'd personally be excited in that case because they really deserve it.

If you are considering moving your CI back to GitHub Actions, or GitLab CI, and just need runners that are better and more fairly priced than the ones that you get from GitHub, I'd recommend giving them a shot and shooting them an email. They are one of the nicest teams to work with and they'll work with you on providing you the best value.

Devoting mental energy to LLMs and Apple's ecosystem needs, that's how we came across Acceptance Tests. If you've worked with them in your Xcode projects, you might have experienced the pain. Developing them is costly, although Apple is helping a bit with Xcode 26 with tools that automate writing them. Still, writing is only part of it. They are a runtime contract with your application's interface. Find a button and click it, or scroll until you find something, and then act on it. But one day, something changes, the contract is no longer met, and it doesn't necessarily mean the app doesn't do its job. It's just that the test needs to be updated, and since this is not something you do every day, the cost of refreshing your memory on how to fix the test is quite high. But that's not all. They take time to run, so you likely run them in parallel, but since they require multiple simulators, and there's a limit to how many you can run per macOS environment, this means sharding, and sharding means automation complexity you don't want to deal with, so you likely end up with sequentially executed tests that add up to a lot of minutes in every PR. By the time the time is too high, you lean on running them in main, distancing failures in time and space from the PRs that might have introduced legitimate failures, so the value of those tests diminishes significantly until the team just removes them.

The alternative? Have an in-house or external QA team. But this is equally costly and doesn't scale well. Concurrency is limited to 1 per tester. Moreover, they'll likely lack a lot of context to test the app effectively, unless they are in-house or they've been working with you for quite a while, such that they know well what the critical areas of the business are and can focus on those to ensure they don't break. Let's say they find issues and report them. They usually come in the form of a description of what they were expecting, what they got instead, and perhaps some screenshots or videos of the failure. The developer receives it, and they are left wondering where to start debugging. The video or screenshot should be enough, but it's not. You wish you had logs or handled errors or network requests, but all of that information is gone. You are unable to reproduce it, nor is the QA person, with whom you spend endless back and forth Slack messages or emails until you give up. The app is then shipped, and your error tracking platform reveals what the scenario was that led to the error. You'd have caught it with the right debugging information, but the tester had no easy way to provide you with that.

These tests are insanely valuable, yet extremely costly. What if we could make them less costly with LLMs? That's the assumption we started with, and it turns out that we can. We integrated Tuist with Namespace environments to spin up macOS environments where we'd download previews of your apps and start testing sessions in simulators using LLMs. Along the process we'd collect diagnostic data such as logs, so that on completion, we could not only provide you with the results, but also with everything that you need to diagnose the issue. The results are quite promising and it's truly mindblowing to see. Imagine incorporating not only the PR context into the testing session, but also information about the business, so that the technology is able to identify the most critical workflows. We'll have to iterate on it based on real scenarios, because... LLMs, but we hope to get to a point where we strike an amazing balance of insane value with little cost. I don't remember the last time I was so excited about a piece of work.

If you are interested, you can head over to tuist.dev/qa and we'll get you on a beta testing list. Here's a sneak peek of the report that your teams will get.

All you need to opt into Tuist QA is having an iOS app project, and it works with React Native too.

You can also reach out to me personally, pedro@tuist.dev, to know more about the feature.

These days I’m swinging the pendulum back to using hosted services. First, because running a company and dealing with my medical situation has left me without the energy to navigate the inconveniences that the self-hosting model presents. Second, because I don’t want to end up in a position where the only tools and services that I trust are those that are open source and/or keep the data locally and follow standards. We live in Europe, which means there’s a framework that forces those companies to give me access to my data, so in hypothetical scenarios where I need my data, I should have access to it. I believe this is the way to go because it’s also a model that’s accessible to many people. Only technical people can afford to self-host a service.

Still, I choose wisely. I lean on Obsidian over Notion, and I don’t care whether they are closed source, but I can trust Notion and I can pay for getting my Vault synced across devices. After many years with my static blog, I’m back at Ghost, which I set up in a few minutes and then used Claude Code to help me migrate all my content through their API. It was a joy to set everything up and choose and pay for a theme from a theme store. In the past I’d style my website myself, but I don’t feel this is the area where I want to invest my energy. I prefer to pay someone for the amazing job they did creating a theme, and pay Ghost for keeping my site up and running and always available. Same with Notion. I trust them. These people are all about empowering publishing, and they deserve every single euro to execute on this vision. Does it cost money? Oh yeah, so what—they deserve it.

I also tried Omarchy recently, which was fun to tinker with, but I don’t feel that I need that level of configurability. There are things that I don’t like about Apple’s ecosystem, and sometimes I wish it were more open, but there are so many things I don’t have to think about that I can focus on the things that matter to me. At least today, that’s not configuring a window tiling system. It’s fun, but not where I want my energy to go. I’m happy with my Zed editor, which now integrates with Claude Code, and that’s all I need, really.

I don’t know if the pendulum will ever swing back—I guess it will—but this is how I feel now. Building a company and dealing with recovery from surgery is very energy-demanding, and being negative and zero-trust against tech companies is really not good for me or for anyone. We need more trust and frameworks that ensure our rights are respected. Although having the framework doesn’t guarantee enforcement, I trust the EU that in serious cases, they’d act, as annoying as it might feel for tech companies.

We are not that keen to pay for tools. Our programming language is free, as are the web frameworks and libraries we use to build our apps. Why pay for a tool? Having a conversation with our manager about the value of a tool, or looping in legal or procurement, is something we’d avoid too. We’d even go the extra mile to look for alternative solutions to avoid the bureaucracy. Being contacted by a sales team is out of the question. A salesperson doesn’t need to play sales tactics, and the founders behind the product play a crucial role in building the trust that could lead to a sale. The best marketing we appreciate is when we come across an in-depth blog post from the company. These people know what they’re talking about. Seeing a company’s logo at a conference is cool; seeing it multiple times feels suspicious. They want something from me.

Yet, we are a very hackable human species. There are many buttons they can press to sell us what they want. In fact, pressing those buttons creates trojan horses to reach our employers. From pressing the button of public recognition and getting us excited and talking about the company, hoping for a prize at the end of the tunnel (sound familiar? YouTube has pressed this button for years), to pressing the fear button. The fear that you’ll lose users because your app is an extra 5 MB. The fear of missing out on new trends that everyone is talking about, like not being able to quickly code new features into your app. Or the fear that you’ll be left behind by some critical mass.

As odd as it sounds, many sales in this space are driven not by traditional strategies, but by hacking developers. This process is quite misaligned with our values at Tuist, so we’re looking around, trying to figure out something different. I believe it’ll revolve around great content about how Tuist can impact apps out there, without publicly shaming anyone for the job they’ve done, like we’ve seen companies doing. Just planting a seed about the value they hcan gain, not a seed of fear.

My work is trusted by Shopify, American Express, SoundCloud, Bloomberg, Stripe, Google, Monday, Just Eat, Etsy, and Adidas.

If you'd like to contact me, you can send me an email at hola@pepicrft.me.

On September 21st, 2024, I had a very unlucky accident while running that led to a strong impact on my knee, causing such pain that I ended up going to the hospital in Lichtenberg by ambulance.

Early experiences already felt unexpected. From the ambulance crew refusing to give me any water to the hospital calming my unbearable pain with random ibuprofen here and there. Something didn't seem right. My right foot dropped. I thought about lifting it up, and nothing happened. As if my brain's messages couldn't reach the muscles in charge of that movement. I told them, but they didn't think it was their responsibility. The X-ray showed the meniscus was fine, the tibial plateau slightly impacted, and swelling in the area. After 8 hours there, they sent me home with a knee brace, which I later realized wasn't a good idea, and the recommendation to visit a trauma specialist on Monday.

Monday came, and I went there early to make sure I'd get a slot. The room was packed with people. He spent 5 minutes at most with each patient. My turn came, I went in, told him everything that happened, and he sent me home, suggesting I continue with my leg elevated, injecting heparin, and regarding my concern about the foot drop, he suggested I get an appointment with a surgeon in the same building. They gave me the appointment 4 months later, and part of me thought it was okay because I didn't think there was a connection between the swelling and the nerves. In other words, I thought I'd recover the movement as soon as the swelling was gone.

Weeks went by, and with them, appointments with the trauma specialist. The knee became less swollen, but my foot was still dropping. It didn't feel like it was his responsibility. He asked for an X-ray, and in his opinion, everything had recovered. Luckily, I listen to my body, and everything I was being told didn't feel right. So I decided to get a private consultation for the nerve (300 Euros). Why private? It was the only way to get one fast. And why fast? Because nerve damage is harder to recover from the longer you wait without addressing it.

I traveled all the way to the west of Berlin. The doctor suggested doing an electromyography to see if my nerve conducted. I still remember the smell of my hair burning when she tried to increase the intensity because she couldn't believe what she was seeing. Luckily, her face showed this uncommunicated awe. She called her colleague to repeat the test. "She is better than me," she said. But the results were the same. The report? The nerve is kaput. The advice? Go to physio. A lot of people make fun of going to the doctor with a cold and getting recommended tea. Physio felt like the tea for severe nerve damage. Not something I wanted to deal with...

I went to the physiotherapist. She couldn't understand anything. "So you just fell running and your nerve is fucked up?" The trauma specialist gave me an Überweisung for useless 20-minute sessions where the physiotherapist would ask me to ask the doctors what to do, and ask me what I'd do considering the strangeness of the case. She was the first one suggesting I get a small orthopedic device to keep the foot at 90 degrees with my leg so that I could walk normally. She suggested getting a prescription from the doctor, so I did, but the lady at the orthopedic store refused to give it to me. First because the code wasn't right, and second, because she thought the Krankenkasse wouldn't pay her because they had given me and covered another one at the hospital. I couldn't believe it, and my mind was blown when the physio mentioned that I could just use a 15-euro one from Amazon. "Why are you wasting my time?" I thought. Also, why are they so hesitant to offer me anything because of fear of the health insurance not covering it if I need it?

Weeks went by. I noticed a bit of instability in my knee and no signs of recovery in the nerve. We went to Spain for Christmas and decided to pay for more tests myself. The first one was an electromyography, like I did in Berlin. The result? The same, no conduction. But this time the advice was very different and more acknowledging. "This is severe. Move fast." Finally! Someone who had called out the severity of the issue and urged me to move fast because it might require surgery. He also said that there aren't many doctors who know how to do these surgeries, especially if it requires transplanting nerve. It turns out there are cases where the nerve gets compressed and the surgery is about releasing it, but that didn't seem to be my case.

I then started my search for a trauma specialist specialized in nerves. I contacted two, one based in Barcelona with whom I'd finally get the surgery, and another one in Madrid. I got a very quick response from the latter, so I took a train to Madrid and decided to give him a visit. From the first moment I stepped into the consultation, I felt uncomfortable. He used sales techniques that I had seen before, from pressing fear buttons to coordinating with the hospital that would do the MRI later to continue the fear mood. The first MRI! After 3 months. That was the positive part of this visit. I could finally understand what happened. Hold yourself: I had, in practical terms, a dislocation of the knee, which resulted in severe damage to the LCL and PCL ligaments, and a couple of tendons that had detached from the bones. That dislocation had probably stretched the nerve beyond its limits, causing its internal fascicles to separate very severely.

Things started to make sense. I refused to do any surgery with that doctor who continued to make me scared to the point that I ended up crying. I was hopeful my conversations with the doctor in Barcelona went well. I went back to Berlin and visited my trauma specialist. I told him that I now have an MRI and that the reality is very far from his diagnosis. His response? "I have never seen this in my life, and if I were a couch potato like he is," he recommended not getting surgery. I couldn't believe what I was hearing. 32 years old, severely damaged ligaments, and your response is not to intervene?

I was then recommended through a family member to visit one of the heads of traumatology at the hospital in Bonn. My wife and I crossed all of Germany by train to visit this doctor. He confirmed the ligaments were not in good condition and would require surgery. However, he suggested forgetting about the nerve. To do a tendon transplant from the calves to the front side of the leg as a natural solution to keep the foot at 90 degrees. I was convinced about the plan for the ligaments but asked for a recommendation for a doctor in Berlin so that I could do the recovery close to home. And that's how I landed at Vivantes Kreuzberg with another head of traumatology there. On the side, I continued conversations with Joaquim Casañas from the clinic Traumaunit, who would end up doing both the nerve and ligament surgery, but more on this later. Note aside: this doctor from Bonn told his son, from whom I got the recommendation, that he was surprised to see that I was the one with painted nails and not my wife... Unbelievable.

But the story doesn't end there. My experience with the trauma specialist still feels to this date like a fake TV show. He started the conversation making jokes here and there, surrounded by a couple of extra guys. It felt like a boys' club. "What are you expecting out of this?" "Running again," I answered. Then he laughed and went with a "Running? Perhaps in the swimming pool, because you know you can run there, don't you?" All of this without looking at the MRI, which I was hopeful he'd examine, but that wasn't part of his plans. "Forget about the nerve," he said, then his colleague confirmed, and I stopped both of them and asked if they were neurosurgeons or had expertise on nerves. Surprise, surprise, neither was, but they had confidence as high as the Alps. So I decided to focus the conversation on the ligaments. "Do you know X?" (a German name) "No, why do you ask?" I sensed a bit of laughing over a funny joke. "It's a German player who played his entire life without ligaments because he focused on his physical health and strengthening the muscles that could take the role of the ligaments." And I was like, okay, but he is a football player, and I'm not. Then he looked at me and suggested that I focus on losing the extra kilos on my body, and if that wasn't enough, he looked at my wife and asked her if she liked me. Neither of us could believe the question, so she answered yes, and he gave her a recommendation to cook healthy food for me to contribute to my weight loss. We couldn't believe what we were seeing there; we were completely speechless. We also felt powerless. We should have said something and stopped the macho vibe in that room, but we were not emotionally charged to respond to that.

I was running out of options, but I knew the nerve was the focus, so I got an appointment with a neurosurgeon at Vivantes Friedrichshain, also head of department. This time, she spent some time looking at the MRI and trying to understand the whole case. She was patient and listened to us. However, the conclusion didn't give me confidence at all. "I think," she said, "that the issue is that the damage to the nerve is 20 cm, and considering nerves recover approximately 1 millimeter per day, you need to wait longer. I could open and transplant," she continued, "but it's always better if the nerve recovers by itself." In literal German: "Natur macht besser." The only problem was that in this case, nature couldn't do better because my nerve showed no signs of recovery in a few months, and it was on the path to causing the rest of the nerve to die and the muscles to die. That same day I had an appointment with the doctor in Barcelona, and he mentioned that the only way to know the state of the nerve was to open the leg and see. The surgery could just consist of releasing the nerve, or in more severe scenarios, it would require doing a nerve transplant, a very meticulous process where they need to identify what each nerve fascicle is for and suture them with a lot of patience and care. That's all I wanted to hear. Charged with many negative emotions, I decided to get surgery, which finally happened in February 2025, 5 months after the accident.

The surgery required a transplant as I originally expected. The nerve was severely damaged and wouldn't recover by itself. It took 5 hours, and everything that surrounded the transplant area looked positive. The doctor sent electric pulses during the surgery to confirm that the last part of the nerve was functioning and controlling the muscle as expected. It did, and he even recorded a video and shared it with me. Something that would have been unthinkable in Germany.

And that was just half of the equation and the most important one. The foot continues to drop and still drops because it'll take more than a year to control the muscle again, but everything is looking positive so far. But there was still the second half of the equation. What about the ligaments? In one of my checks with the nerve surgeon, who runs a clinic specialized in trauma, he got me an appointment with the doctor in charge of ligaments. He ran a bunch of tests, which he then contrasted with the MRI, and confirmed that my lateral and posterior cruciate ligament and the extensor apparatus would require reconstruction to bring stability to my knee. Otherwise, over the years, the tibia would get displaced and have cascading severe consequences. I was sold on it and didn't think twice about getting (and paying for) the surgery. I trusted the team from the nerve surgery, and I felt I was in good hands. Moreover, they knew my case, so they'd be extremely careful in this surgery to prevent any more severe damage.

But again, part of me felt that this should be covered by my health insurance in Germany, so I decided to give the system one final chance. I was recommended a trauma specialist specialized in sports medicine. I paid for a 300-euro consultation with this doctor. I went there, told his assistant my entire case, because yes, there they are so qualified that typing on a computer is a bit of a waste of time for them. Then he came, did a bunch of movement tests, less exhaustive than the ones I got in Barcelona (I could compare), and suggested getting another MRI. According to him, because you know... ligaments sometimes fix themselves. "Natur macht besser" again. I later learned that that's partially true. If the tibia is not fixated while the ligament damage heals, then it heals stretched and the ligament plays no role in protecting the knee. So his point was completely flawed. I was going to pay 300 euros for a 10-minute "get an MRI" answer, so I bothered him with a couple of extra questions. "So I come back with the MRI, and it shows no signs of recovery. What do we do?" Then he answered he'd wait until my nerve recovered, in maybe 2 years. A period during which my knee would be quite unstable and at high risk of causing other issues. I couldn't believe that was his suggestion. I said alright, I'll do that, but part of me knew I'd end up getting the surgery in Barcelona. I had no sign of trust from this trauma specialist, a very professional and respected one according to my physiotherapist.

Almost a year later, and after more than 30K in expenses, I've got the nerve transplanted, the ligaments reconstructed, and I'm starting the recovery process of the ligaments. It turns out none of the recommendations in Germany were right and would have led me to lifelong disability in my nerves and also my knee. I'm so happy that I made the decision to look for answers elsewhere, but this is unacceptable in a country like Germany, which I'd have never expected to have such a terrible system. At moments I thought I was unlucky with the professionals I came across, but I interacted with so many, and not just in Berlin, that I started to realize some patterns that are specific to the design of the system and that would explain why things happened the way they did. What follows is an attempt to explain these things. Because yeah... I'm a logical person.

The Why

I'll touch on a few ideas in no particular order.

I think Germany's health system is effectively private. For me, a public system is one that places the focus on the patient. The German system tends to the opposite. Why? Clinics get paid by the health insurance companies. They are companies, so they need to maximize their profits. They are limited in costs since they require a lot of human capital, and scaling the business would also mean scaling the cost, so they choose the path of maximizing the number of patients they see while minimizing the risk of over-prescribing and potentially having to cover the costs of some treatments that insurance companies would refuse to cover.

The doctor doesn't want to be in a position where they need to justify a treatment to health insurance. It's easier to prescribe you tea or skip an MRI because you were just running, and pass the problem onto you or someone else in the chain. The thing is that many serious health issues start with something small, so you need to take a more preventive stance and over-ask for tests that could uncover serious issues. In my case, an early MRI would have revealed not only the severity of the damage to my ligaments but also the connection with the damage to the nerve. Instead, the missing piece left a chain of professionals confused and passing the problem to the next ones, like middleware in an HTTP server. "I don't understand" > "Not my problem" > "Forget about it."

I later learned that nerve damage is considered high severity and treated with the urgency that I never had. I thought many times about private health insurance, but honestly, I don't think it would have done things any better. We say in Spanish that it's "the same dog with a different collar," meaning that at the end of the day, you are interacting with the same professional, just faster. The same professional who seeks profit over going deep into your case, like it was the case of the neurologist who thought the best solution to my non-conducting nerve was just doing physiotherapy.

Then there's the piece of not admitting that they don't know the answer, but at least pointing out the severity of the issue and the kind of next steps. Like... "I don't know, but I've heard this doctor is good at this type of surgery." I think it's a bit of a macho high self-confidence issue. This was a common denominator across all the male doctors I interacted with. One of them, the one who told my wife to cook for me to lose weight, felt like being in a boys' club. Listen, I don't expect everyone to know about everything. I knew my case was a bit special in that I didn't damage common organs, but I'd expect them to approximate closer to the issue and help me approximate even closer with the help of other professionals, but that was not the case. Instead, they laughed and hinted that I should treat my nerve as dead forever.

Another issue I noticed is that because German doctors perform fewer surgeries, they're losing practice and there's little appetite for exploring new techniques or treating complex cases. The system seems to discourage surgical intervention, which creates a vicious cycle: less surgery means less experience, which makes doctors even more hesitant to operate. I also heard from a nurse that a surgery that has a slight chance of not going as planned can impact a doctor's curriculum and reputation, so they are particularly hesitant in challenging cases. This risk-averse culture means doctors would rather pass on difficult cases than potentially harm their professional standing. In my case, this meant multiple doctors preferring to let me live with permanent disability rather than attempting a complex but necessary surgery.

Let's talk now about Überweisungen. Every interaction with a doctor requires explaining the entire case from the beginning. At times I felt I was a pigeon with Überweisungen from one side to another. The general practitioner was hesitant to give me those, the physiotherapist had interest in me getting more of those so that I'd have those useless 20-minute sessions and she'd get paid for them. The orthopedist store was happy if the doctor would figure out the right number to put on the paper so that they'd sell me the right instrument and my health insurance would pay them for it. The private doctors, both the neurologist and trauma specialist, sought purely profit, but when the problem was severe, they turned a blind eye to it. They even hacked the system. The trauma specialist knew he wanted to invoice me 300 euros, so he filled the invoice with a breakdown that didn't reflect reality. Is this even legal? Man... it's a recognized sports trauma specialist in the city, and he could barely hold 10 minutes going deep into the case?

And then there's the "I've never seen this before," like... yes, it wasn't in the book that you studied, but human bodies are fucking complex. Very complex. And sometimes issues span across boundaries, like it was the case here. Isolating domain experts like the German system does complicates treating health issues that span multiple areas of your body. Perhaps a pain in the stomach area is connected with some other part of the body, and looking at each in isolation would miss the big picture. I think the system is designed in such a way that it's easy to miss the big picture. The nerves are not the responsibility of the trauma specialist. Back to the doctor and paper to the neurologist. The trauma is not the responsibility of the neurologist, so back through your general practitioner to the trauma specialist. And all of that requires an insane amount of emotional energy that's difficult to have in such a situation.

What's Next

I'll take legal action. I didn't have the energy for that a few months ago, but I charged the batteries and I'll start working with some lawyers. I think there was a chain of medical malpractice here, and I think they need to assume responsibility. I don't want this to happen to anyone, and even though the way they act is a response to a system badly designed in first principles, if we silence these cases, there's little chance of things getting any better. Slowly but steadily, I'll start with this as soon as I'm back in Berlin.

As for what if something similar happens again in the future: I'll be pushy at every consultation with doctors. I will listen to my body like I did this time, and if needed, I'll add any drama necessary. The amount of taxes that are going to these things, something I especially see now running a company where I see health insurances debiting the money from the bank account, is insane and worthy of more than just 5 minutes of "go home and rest."

I won't switch to any private insurance because the doctors are the same. If they see me sooner but they are unable to tell me what I have, what's the point? I'd rather go to a place where I have the certainty that profit is well balanced with going deep into the case. I paid for the surgeries here in Spain, but at no time did I feel that I was a product. They treated me with great care and followed up before and after the surgery to ensure the best recovery. Isn't it annoying that this all has to be private? Oh yeah, it fucking is, and I'll fight as much as I can to change this, and taking legal action is a bit of my personal fight. We need to protect and improve the system, which we are covering with our taxes. If more than a thousand euros a month translates into not getting an MRI when I needed it, refusing to pay for an orthopedic device, a 10-euro invoice of copayment for the ambulance, or seeing me for 5 minutes to tell me to go home and rest, something is very fucked up.

The reality of the mobile developer tools market is sobering. It’s not tiny, but it’s not huge either, especially compared to the broader tech industry. Mobile teams at large companies rarely exceed 40 developers, which caps account sizes. Developer productivity—our core value proposition—isn’t easily measurable unless you wrap it in AI and sell the FOMO of missing the next productivity revolution.

Even when organizations see the value and are willing to pay, you’re looking at seat-based pricing in a constrained market. I believe this explains why we don’t see many companies thriving purely in mobile tooling. The mobile developer tools market specifically has structural limitations that make growth challenging. Investors also have less appetite for this space, partly because it’s hugely controlled by Apple and Google, who strongly influence the development lifecycle and app distribution.

Here’s the thing though: I want Tuist to grow, and I see this as an exciting challenge rather than a limitation.

The key insight is that we don’t need to stay confined to traditional developer productivity. Tuist has always been a generic name, which gives us flexibility. More importantly, we have incredible foundations: years of open source work, a strong community, and robust infrastructure investments. I see Tuist evolving into open infrastructure for mobile developers—something you can self-host for free if you want, licensed fairly, built transparently.

This model has worked brilliantly for many source-available products. Instead of competing on price, we compete on being better and more open. Large enterprises will pay significant money for infrastructure they depend on, especially when it scales with usage rather than just seat count.

The most successful approaches in adjacent spaces involve becoming critical infrastructure that grows alongside customer success. Companies that position themselves in revenue-critical paths, while also building strong developer communities that turn into enterprise advocates, create powerful flywheels.

What excites me is how we can leverage the infrastructure we’ve already built. We’re running ClickHouse databases and soon Grafana dashboards—infrastructure that helps users and organizations understand how users interact with their apps at every stage. Our API keeps expanding, with account tokens and scopes coming soon. The throughline is becoming clear: we’ll build a Tuist SDK that connects app runtimes to our open infrastructure, giving developers unprecedented visibility into their applications.

Eventually, we’ll expand to Android since our solutions are fundamentally cross-platform.

The best infrastructure feels invisible when it works and indispensable when you need it. That’s what I want to build with Tuist—not just better tools, but essential open foundations that mobile developers like us can trust, extend, and build upon. I’m excited to share more about this journey as we continue creating what I believe will become critical open infrastructure for mobile development.

There was one pattern in Fly.io that I liked a lot and that gave us an idea for an approach we could take at Tuist to give developers a new interface to their data. Every app in Fly comes with a read-only Grafana dashboard where you can explore metrics from your service like network requests, memory usage, and CPU usage. It's insanely convenient because without it, you'd need to deploy your own Grafana instance and set up your project to collect, standardize, store, and present the data in your own Grafana instance. It's a lot of work that someone takes off our plate. And the best of all is that they also provide a Prometheus-compatible endpoint to poll the data into your own dashboard as a way of extending their read-only dashboard, and their dashboard as JSON, since Grafana dashboards follow a standard schema.

Why is this a cool idea for Tuist, you might guess? Well... at Tuist we are collecting data from your projects and the interactions with them (e.g., builds and test runs). We standardize the data and persist it in a Tuist-managed ClickHouse instance so that you don't have to do that yourself. We also provide a dashboard where we surface most, but not all, data. And this is a problem, I believe. You should have access to all your data in two ways. First, via an API. Most of our API domains are write-only. The CLI pushes data, and our dashboard is a presentation layer. But this is something that we'll change as we build clients for that data beyond the dashboard, for example, our iOS app. Second, you should be able to consume the data via a more complete dashboard, and this is where the idea of Grafana comes into play.

We are thinking about drawing from Fly's idea to provide every Tuist project with a Grafana dashboard that reads the data from our ClickHouse instance. Think of our dashboard as simple analytics, and the Grafana version as an advanced and more flexible version of it. An escape hatch where you can do more than what you get from our dashboard. And you might wonder... why not build the dashboard ourselves? The answer is simple: Because we can't build a better dashboard than Grafana. Dashboards are their business, it's something that they've done forever, and when you try the product, you notice it right away. Building dashboards is not our business, and throwing resources at matching Grafana's experience is the worst use of our resources. Our business is to collect and standardize the data—something no one has done before in the app development space, or at least not in the domains we are currently moving in, developer productivity—and then provide you with tools to get the most out of our data, from a Grafana dashboard to optimizations and insights to improve your dev environment and apps.

I did some experimenting yesterday, and I don't think it would take a lot of effort to pull this off. I've already deployed a Grafana instance at https://metrics.tuist.dev, which I connected to our ClickHouse. Our server already supports OAuth2 thanks to the amazing Boruta Elixir library, which means users can log in smoothly using their Tuist identities. One click on the Tuist dashboard, and you get taken straight to the dashboard in Grafana. We'll have to implement logic for syncing the tenants, permissions, and the dashboard, but with their API, I don't think it'll be a lot of work.

Something also amazing about going down this path is that the schema of Grafana dashboards is standardized. Which also means you can tell LLMs: here's the schema of the data I have access to, and taking into account the schema of Grafana dashboards, please build a dashboard to get particular insights. And this is something you can apply not just to developer metrics like build times, but also product metrics, which we plan to expand to later in the year or early next year. Standards are unlocking in the world of AI, especially if they are not constantly changing and the LLMs have already gained that knowledge.

I think this is the kind of feature that will differentiate our offering among competitors as we step into new markets. We are a developer-first company, and these are the product design decisions that reflect that. Moreover, it shifts the value from the server to the infrastructure, which brings us closer to adopting a license like the Functional Source License (FSL) for the server, since customers will want to pay us for providing a fast and reliable service. As David Cramer shared in a podcast, we'll have organizations that will prefer to host it for free and go through the pain, and that means they won't pay for the product, but those customers that are not paying for the product are not paying your competitors either, and they are closer to becoming your customer. That's the place where we want to be as a company, especially as we expand to new markets where all the solutions are closed source.

Yet the most enduring landscapes often emerge where different forces converge. Consider the digital commons that have grown into essential infrastructure—Wikipedia’s vast knowledge gardens, Ghost’s publishing meadows, Linux’s foundational bedrock. These flourished not because money called them into being, but because gardeners appeared who were drawn by something else entirely: the simple desire to cultivate something beautiful and useful.

Even the most organic gardens require tending. Like urban parks that need maintenance crews and water systems, these digital spaces have real costs woven into their existence. The paradox is that many institutions haven’t yet learned to see this infrastructure as worthy of investment, leaving these projects to find their own path toward sustainability without losing the original spirit that made them flourish.

At Tuist, we’ve been learning to dance between two rhythms: maintaining an open garden where anyone can wander freely, and running a small café at the garden’s edge. Some visitors will always prefer to bring their own provisions—and that’s perfectly natural. Others might glimpse the café and decide the garden isn’t for them, perhaps sensing commercial intent where they hoped to find pure sanctuary. The café’s earnings flow back into the garden itself—hiring groundskeepers, improving pathways, ensuring the space remains secure and welcoming.

I use this physical metaphor because software, like parks, is infrastructure that serves communities in ways both visible and invisible.

When we first considered adding the café, we’d come to understand that our garden—however cherished by its visitors—occupied a quiet corner of the world, not a bustling metropolitan center. Traditional funding seemed unlikely to find us there. The café felt necessary, but as I mentioned, money brings its own peculiar weather patterns to any project.

During this contemplation, we encountered another gardener with a different relationship to cultivation. Their vision reached toward something like Central Park—vast, commanding, transformative on a scale that money could achieve. “Would you consider joining forces?” they wondered. The idea of alignment between kindred spirits always deserves consideration.

But walking through their grounds revealed something troubling: a collection of abandoned plots where other projects had withered after acquisition. The pattern suggested a different philosophy of growth—one focused on rapid expansion rather than deep cultivation.

We represented something valuable despite our modest scale: an authentic community, a trusted name, roots that had grown slowly but strong. Perhaps that authenticity felt like something worth acquiring, like suddenly owning an established garden and using its paths to direct visitors toward a larger commercial venue. The leverage of genuine community attention, readily purchased.

When they proposed converting our garden into a promotional pathway—essentially asking us to become voices for their larger project—we recognized the fundamental mismatch. We had built something meant to serve its community directly, not to channel attention elsewhere. Our small café exists, but it serves the garden’s needs, not external ambitions. We remain open to growth, even to becoming something as significant as Central Park someday, but only through methods that honor why people originally chose to visit our quiet corner.

This reflects different relationships with resources and growth. Some see money primarily as fuel for market expansion and public recognition. Others view it as one tool among many for nurturing something genuinely useful. Both approaches have their place in the ecosystem, but they create very different kinds of gardens.

What followed only confirmed the wisdom of staying true to our original intentions. Limited financial resources don’t preclude significant growth—they might actually position us better for the kind of expansion that creates lasting value. In a landscape where many sprint toward acquisition headlines and aggressive marketing campaigns, we’re content to tend our garden with patience, watching it grow organically into whatever it’s meant to become.

Our relationship with money remains instrumental rather than central, and I’m grateful that our quiet corner of the world continues expanding in ways that feel authentic to its original spirit.

You might have noticed many tools for coding ideas or entire apps—tools like Lovable, V0, or even solutions for mobile apps. I don’t expect someone to build a GitHub today with these tools, but you can build POCs, features, and even projects just by chatting. The whole idea of being able to chat to build something, for example with your voice, is quite cool. I think of this as an accessibility tool, and one of Tuist’s responsibilities is to make building apps more accessible—for example, by managing the intricacies of Xcode for you.

However, I’m not aligned with the model where you don’t own the code, either locally or in a remote repository. I get it—it’s a way to monetize it. It’s similar in a way to those GUIs for designing and building websites that required a subscription to export your code. These experiences can and must run locally in my opinion. While many of the local solutions focus on integrating with existing dev environments, I believe local-first Lovables will emerge where the action happens locally, you own the code, and you choose the model.

Apple is doing a bit of this already with their Xcode 26 chat interface, but I believe editors as we know them today are going to change. When I use Claude Code, my editor is more of a tool to review the code and continue conversing with the agent. I don’t need auto-completion or the editor part taking most of my screen. What I need, though, is a way for the agent changes to be hot-reloaded instantly, and it makes me happy to think that we invested in half of that by allowing clean builds to be faster. Once CAS arrives, it’ll be even faster.

So it’ll take ages for Apple to realize things are changing and throw resources into challenging many assumptions baked into Xcode. Until then, I think there’s an opportunity for us, and that’s what I started tinkering with: Tuist Ignite (the name draws inspiration from GitHub Spark). The idea is simple: you run a command, and a coding experience opens in your browser. You can create a new project or add features to the project in the directory where you run the command from. Building? We know how to do it. Short feedback loops? We know that too. And common tasks like adding a dependency to integrate with GitHub? We can add that too. We could have a directory of plugins or formulas for these things that people can contribute to the repo—for example, a formula to set up RevenueCat in the project. I can’t conceive this experience being closed source. If we want to build a truly powerful alternative to Xcode for some types of tasks, this is the way forward.

Now, don’t get me wrong—Xcode doesn’t go away. You might still need it. In fact, we need its build system and Xcode projects internally. Think of Ignite as a new frontend to the same backend. And it’s a frontend that runs locally in your browser, but it can also run remotely—also in a browser or from a native client built for the task. VibeTunnel taught me the mental model of building your network such that you can connect to your localhost from anywhere.

Ignite is about grabbing that idea you had in your head and preserving its energy until it’s touchable—until you can feel it. And having an experience that’s welcoming to anyone regardless of your background. Because ideas can happen anywhere and by anyone, anyone should be able to prototype from anywhere. Most ideas will eventually be discarded, but some will get continued, and this is where an editor like Xcode comes into play.

When contributing an idea to an existing app, you are constrained by the existing project in terms of how things should be done. For example, if the project is written in Swift, you’d shape the idea in Swift. Well… not you, but the underlying agent. But if you don’t have anything, why wouldn’t you just go with React Native instead, which can hot reload changes relatively fast? I don’t know… those are questions I ask myself. Tuist is strongly tied to native development, but I keep an open mind and challenge my own assumptions and principles, and I think React Native is well suited for these kinds of idea ignitions.

Now the idea is built—you’ll want to have an extra check of confidence before you share it with the world. And this is where Tuist QA comes in. Acceptance and snapshot tests are costly to develop, maintain, and run. This is well known… Xcode 26 is making it easier to write them, but what about the maintenance? What about that UI test failing and you being unable to diagnose the issue because what the test is testing is implicit in the testing code itself? Good luck. We think there’s an opportunity to improve the state of the art there—an opportunity to pull your changes, build the app, and then use LLMs to navigate the app and test what you’ve implemented, which can be derived from the changes or your changelog. Once it comes back, you can keep iterating or move forward. The report will come with all the artifacts and data you need to diagnose the issue, from screenshots to the network requests that were sent. Because let’s not forget that diagnosing a UI or acceptance test remains tedious and convoluted these days. We’ve got a POC and it looks very, very promising.

Your idea is built, we know it works—you’ll want to share it with the world, won’t you? You’ll likely want to share it with a small circle, which means you need to build and sign the app, including the destination device IDs in the certificate. Sounds like a lot if you wanted to prototype something or you have no context at all around how signing works in the ecosystem. I feel you. But this is where our Tuist Previews feature will shine. From the same UI where you crafted your idea, you’ll be able to “Log in with Tuist” and click share. It’ll complete with a link that you can share with anyone, and if signing is needed, we’ll sign the app on the fly for you.

What sits at the core of all of this? Our experience working with Xcode projects and toolchain, which we built over the years. A development SDK that can expose runtime data to the Ignite and QA agents. Some context is available from the outside, but other context can only be retrieved at runtime, like the network requests that are happening. And last, we need ephemeral macOS environments, and that’s why I’ve been so excited and supportive of Namespace. It’s the only company that has a well-productized offering of macOS environments for developers. You call an API, and you get a Mac Mini. Our agentic features will be triggerable from anywhere—from a new comment on a PR to a button on the app while waiting for a flight at the airport. We are breaking the strict dependency of everything happening through a CI pipeline, because it’s extremely constraining and terribly limits the DX that one can build.

Oh! And we also need fast builds—otherwise the experience will be as bad through agents as it is when you interface with Xcode directly. Hence why we are investing in reducing the cache latency and preparing for when content addressable store lands in the Swift build system. Maybe next year? Or in a few years? Who knows… in this ecosystem, things are closer to how things are in life: slow.

Companies have a market and continuously strive to make it larger to increase their capitalization. Within those markets, there's one customer profile you can sell to. It's usually referred to as the ICP (Ideal Customer Profile). For instance, Tuist's current ICP is large development teams that are scaling their Apple app development. It's a small portion of the total app development market. Now, once settled in a market, it's common to have an appetite for more, especially if there's a broader set of incentives that escape the company.

There are different ways to enter a new market, but one of them is buying companies in the market you're expanding into. Sometimes you just want the customers of the company; other times, you just want the brand awareness that company has in a particular market—perhaps both. This is a costly move (you need to buy a company), and it might not always go as planned. First, you've got a user base that has a perception of what you are as a product, and people react defensively to changes. It takes time and a lot of socializing for people to connect with what you see the company becoming. Moreover, your product and brand might limit you. If your current market is captured in the name of the company, then you'll have a hard time convincing people you do more than that. That's why I love the Tuist name so much. Its definition is up to us. And last, there's the community of the product/company you're merging into yours—its values, its community, its mission—and it might not align 100% with yours. That'll inevitably create some churn, unless there's tight alignment, which is quite rare.

So when Grammarly buys an email client, there's likely an appetite within Grammarly to enter a new market. Perhaps it's the customers in that market they want? Perhaps it's the presence of that brand in the market? Perhaps we'll never know. But time will tell. I've also noticed companies that realize their ceiling and sell an overrated abstract value that they've faked with money, because there's a lot of storytelling involved in these things, but I'll leave that for a future blog post.

This is the theory, but whether it unfolds and how really depends on the market. We developers of apps for the Apple ecosystem are a bit unlucky. The incentives for diverse competition are not there.

First, the market is big, but not big enough. Second, Apple has significant say and control in the ecosystem, and third, anything that you do for the ecosystem is an act of reverse engineering proprietary and undocumented technologies. We at Tuist know that well.

The consequence is that we don't see much innovation. Either you wait for Apple to come up with something innovative, or you hope for another company to have a culture of innovation. Sadly, neither of the two is happening.

Outside of Apple's factory, companies have gone for the safe bet. The problem and solution that have for many years been validated: CI. Same model repeated over and over: a pipeline, most likely YAML, a UI to see the logs and exported artifacts, and all the glue with the Git forge. Different package, same product. Apple adds the twist (on purpose?) of making their hardware infrastructure-unfriendly, so CI companies usually go from adding a little margin to infrastructure managed by other companies and eventually attempt to own the vertical themselves to have better cost control. BuddyBuild tried to bring some fresh air to the space by challenging YAML pipelines, but Apple went their own way with the product.

CI companies have some foundational blocks to enable innovation—Mac infrastructure and capital—but they struggle at innovating. Product-wise, everything becomes pipeline-centric. Want to automate your release? It's a pipeline. Want to optimize your builds? It's in your pipeline too. And analytics? In the pipeline with the steps that we provide. I'm sure this all sounds familiar.

But sometimes miracles happen. A bigger fish makes an impactful decision, and suddenly the models can be challenged. This is the case with Git forges like GitHub opening up the vertical and making layers replaceable. They solved the topmost layer of CI and gave accounts the option to bring in third-party runners by themselves or from third-party companies. Companies like CirrusLabs or Namespace can commoditize a piece of the infrastructure that was previously reserved for CI companies. MacStadium had a huge opportunity there and failed to take advantage of it.

Sticking to GitHub CI or the equivalent in other forges has something interesting that helps move the ecosystem to a better place. It's so easy to switch providers that companies in the space are more incentivized to provide better and cheaper Mac environments if they want to capture the market. It's also cheaper for you as a user because you go one level lower, and the experience is so much better because it's tightly integrated into the platform where code collaboration happens.

And this move has cascading consequences that can further impact the ecosystem. If Mac environments get better, cheaper, and more commoditized, like with Namespace, which provides an API to get Mac environments, then it opens the game to new players like Tuist that have limited financial capital but huge creative capital. We are not a pipeline-centric product. We want to explore creative ways to solve challenges that developers face.

Now, CI companies won't want this to happen. They are already working on redefining themselves as Mobile DevOps platforms, hoping that companies' perception of the cost of migrating and value remains in their favor. But OMG, LLMs have challenged that too. You can ask a model to migrate a pipeline back to GitHub Actions, and voilà, it'll certainly do the work very reliably. This will take time for organizations to realize, but I'll help create awareness around this.

While the incentives to build for the Apple dev tooling market are not that high, and that makes it trickier to attract capital to support making an impact, changes like the ones we are witnessing since the appearance of GitHub Actions make it more accessible and allow players like Tuist to play the game with a different form of capital—one based on human capital and their ideas. So yes, I talk a lot about Namespace because I deeply care about our users and, more importantly, about having the foundation to enable more innovation in the space. I believe Namespace and their commoditized infrastructure can make a big difference, from being able to release by clicking a button on a website to building apps remotely from non-macOS environments.

Agentic coding is saving me tremendous amounts of time. The more context I provide—which is becoming easier thanks to the growing ecosystem of MCPs—the better results I get. This got me thinking about what this transformation means for app development as a whole.

I’ve been following Peter Steinberger’s work lately, and one thing has become crystal clear: you might not need the IDE layer most of the time. Instead, you can use your voice to spawn multiple agents working in parallel without stepping on each other.

Claude Code reinforced this realization. They built an entire coding experience at a lower layer—the terminal—proving that the IDE’s value is diminishing rapidly.

Apple’s top-down, hermetic approach is making them lag behind in crucial ways. They attempted to catch up with Xcode 26, but it’s already outdated. More importantly, they’ve completely disregarded the elephant in the room: MCPs. They’re doubling down on their proprietary model of “you need Xcode and our tools” to develop apps.

However, significant work is happening to break that dependency. As development shifts toward the terminal, new opportunities emerge to work outside of Xcode. This is where Tuist can play a transformative role.

When we built a business around Tuist, we focused on the most immediately monetizable problem: slow builds. This approach proved both slow and limited in market reach. First, you need an organization with a strong pain point, and many have already internalized that Xcode native development is inherently problematic—you can’t change their minds. Second, you need organizations that see value in investing money to optimize their workflows. Many don’t because they lack tools to measure delivery productivity. We ended up with a very limited market, which left me uncomfortable.

Can we build something exciting that a broader market would embrace, willingly pay for, and leverage all our years of investment? I think so. In business terms, it’s called pivoting. If you’ve used the Arc browser, you know what I’m talking about. Your initial market bets might not match expectations, so you can either push through with resignation because people don’t appreciate the problem you’re solving, or go back to the drawing board and iterate. We’re going to iterate.

I believe AI is fundamentally an accessibility tool. More people will be able to build without knowing how to code. Agents will become excellent copilots for app development. In that world, what would they need?

First, they’d need a build environment that doesn’t require creating a developer account or installing a heavy toolchain. The web is the most accessible solution, so we’ll build an environment like Phoenix.new with an embedded simulator. As you work with the agent, you can see your changes live. This isn’t React Native rendered using the DOM—it’s a real app running in a simulator embedded in the browser. Hot reloading will be automatic and seamless.

But this is only half the process. Once you have something usable, you want to share it with others, collect feedback, or publish to the App Store. If you’re an iOS developer, you know this involves intricacies like signing and building for distribution, making things less accessible for those unfamiliar with Apple’s ecosystem. I’d argue it’s even messy for Swift developers who don’t do this daily.

At Tuist, we’ve solved distribution to others and are working on signing when needed. The final step would be pushing to the App Store or releasing apps directly.

The project lives in your repository. You can continue using our agentic coding environment or go the traditional route of pulling everything and opening the project in Xcode. We don’t plan to support the full range of Xcode capabilities—we simply can’t, and it’s not a good idea. However, we can focus on what developers and non-developers need to build 80% or even 100% of apps, simply by chatting with an agent that guides them from idea to release.

What I love about this approach is that it builds incrementally from the product and infrastructure foundation we’ve developed over the past years, while aligning development more closely with the models emerging elsewhere.

This guide captures the configuration process for anyone facing similar challenges or looking to leverage R2's reliability for their PeerTube instance.

Prerequisites

Before diving into the configuration, ensure you have: - A Cloudflare R2 bucket created - R2 API access keys (Access Key ID and Secret Access Key) - Administrative access to your PeerTube instance

Configuration

The core configuration happens in your PeerTube instance's default.yml file. Add the following object_storage section at the root level:

object_storage:
 enabled: true
 endpoint: '{your-account-id}.r2.cloudflarestorage.com'
 region: 'auto'
 credentials:
 access_key_id: 'your-access-key-id'
 secret_access_key: 'your-secret-access-key'
 upload_acl:
 public: null # R2 doesn't support S3 ACLs
 private: null
 max_upload_part: 100MB
 max_request_attempts: 3
 web_videos:
 bucket_name: 'tuist-videos'
 prefix: 'web-videos/'
 base_url: 'https://storage.videos.tuist.dev'
 videos:
 bucket_name: 'tuist-videos'
 prefix: 'videos/'
 base_url: 'https://storage.videos.tuist.dev'
 streaming_playlists:
 bucket_name: 'tuist-videos'
 prefix: 'streaming-playlists/'
 base_url: 'https://storage.videos.tuist.dev'
 store_live_streams: true
 user_exports:
 bucket_name: 'tuist-exports'
 prefix: 'user-exports/'
 base_url: 'https://storage.videos.tuist.dev'
 original_video_files:
 bucket_name: 'tuist-videos'
 prefix: 'original-video-files/'
 base_url: 'https://storage.videos.tuist.dev'
 captions:
 bucket_name: 'tuist-videos'
 prefix: 'captions/'
 base_url: 'https://storage.videos.tuist.dev'

Key Configuration Notes

Bucket Strategy: I opted to use a single bucket (tuist-videos) for most content types, organizing them with prefixes. This simplifies management while maintaining logical separation.

Custom Domain: The base_url configuration is crucial for avoiding CORS issues. Set up a custom domain for your R2 bucket through Cloudflare's dashboard and use it here. The default R2 URLs can cause CORS problems that are difficult to resolve with policy adjustments alone.

ACL Settings: R2 doesn't support S3-style ACLs, so both public and private values should be set to null.

Migrating Existing Videos

If you have existing videos to migrate, PeerTube provides a convenient npm script:

NODE_CONFIG_DIR=/app/code/server/config \
NODE_ENV=production \
npm run create-move-video-storage-job -- --to-object-storage --all-videos

Adjust the NODE_CONFIG_DIR path to match your PeerTube installation's configuration directory.

Deployment and Validation

After updating the configuration:

1. Restart your PeerTube service to load the new settings 2. Test by uploading a new video or accessing previously migrated content 3. Monitor the admin "Jobs" page for any migration failures 4. Check application logs if issues arise

The integration should provide more reliable video delivery, especially for users experiencing network instability. The combination of Cloudflare's global CDN and R2's storage reliability creates a robust foundation for video hosting.

Troubleshooting

If videos aren't loading properly after the migration, check: - Custom domain DNS configuration - R2 bucket permissions - PeerTube job queue for failed migrations - Application logs for specific error messages

The admin interface's jobs section is particularly helpful for diagnosing storage-related issues during and after the migration process.

For many years, CI companies solved the gap that Git forges like GitHub didn't solve: providing a continuous integration service. You push a commit, see in your commit status that something is happening, and on completion you get a result and access to execution metadata. We could think of their offering as two layers:

1. User-facing layer: web-based UI, pipeline editing features, ecosystem of steps... 2. Infrastructure layer: managing the runners in which jobs would run.

Most delegated 2 to third-party providers like MacStadium, and they faced the challenge that the fluid nature of CI demand and the more static nature of getting Macs—which Apple requires you to get for at least 24h—made it difficult to provide a billing model that abstracted away the rigidity of the infrastructure layer. So it was common to find concurrency limits in their models.

But GitHub, GitLab, and all the Git forges changed the game when they decided to provide the user-facing layer. And not only that, but they did so by allowing hosts to be provided not only by them, but by third-party companies.

This translated into: 1. CI companies trying to expand their offering and doubling down on vendor locking. But developers are confused because they don't expect CI to do more than just CI. Competing with a better product was and is extremely challenging because you'll never be able to provide tight UI integration or features like pipeline permissions, where you can declaratively define the scopes you want the token exposed in the pipeline to have access to. 2. We saw an emergence of companies that focused on providing those agents. I call them "CI Runners as a Service" companies.

And this makes things interesting. By talking to Tuist users, I realize that many companies in group 1 are playing the card of "but moving away from us is hard" and trying to increase the size of their contracts by doubling or even tripling their prices. Others are trying to push the margins down or add new products, but once again, people expect CI companies to deliver CI. The only company that I've seen and that in my opinion is doing excellent work at offering a better and more diverse product is Buildkite.

And 2 is also seeing more companies joining, which means competition, and it'll lead to innovation and potentially lower prices. These companies providing runners face the challenge of marketing themselves effectively, so we'll lend our hand to those who align with our values and have built a great product. And the thing is that once you are on GitHub Actions or the equivalent in GitLab, changing from one provider to another is as easy as changing one line in your pipeline yaml file:

runs-on: ubuntu-latest # Ubuntu
runs-on: other-provider # Other Provider

For some time I wrote about us potentially going to approach two, but the more I thought about it and dove into the space, the more I think it doesn't make sense for us. We don't find joy in doing infra. There are people who have been doing it for longer and do an amazing job at that. Our joy lies in being closer to the user and gluing tools and infrastructure together to provide experiences that wouldn't be possible otherwise.

So my bet is that when it comes to CI, companies will peel away that extra layer and go down to the companies that provide the runners. This means current CI companies will have to redefine themselves as something else, and my bet is that they'll join us in building an integrated platform for app developers. Bitrise started that movement with Mobile DevOps, but I don't think that went as expected. The closest to what we are trying to do is Vercel on the web, or Expo in React Native, so we are trying to bring the same experience to native Apple and Android development.

In this new space, we have a significant moat: our CLI that we've been building for over 7 years and that people use and love every day. This is our competitive advantage. We're going to compile it for Linux and Windows, making it ready for the future that we are shaping.

Pipelines and CI will continue to exist, but we want to part ways from pipelines being the center around which everything builds (release automation, nightly builds or previews, signing). I think the future of mobile is exciting, and we are going to take the lead in shaping it.

Up until 2023, I was moving fast in life. Things were progressing as expected, both personally and professionally. But I now realize I made the mistake of forgetting about myself and becoming addicted to the challenges at work. My personal and professional lives blurred in a way that, in hindsight, was emotionally taxing. I couldn’t see it at the time because of the inertia. Then the layoffs came, I was impacted, and everything came to a hard stop. A part of me moved on, but another part stayed behind, quietly processing emotions that would occasionally surface and demand attention. I ignored them.

Marek and I decided to build a business around Tuist — something I’m deeply excited about, but that also came with a new emotional landscape I had to learn to navigate. When Tuist was a hobby, I placed very few expectations on myself. But once it became a business, I started imposing expectations that brought a flood of emotions: What if it fails? What if we don’t succeed in executing the vision? These questions made me uncomfortable and, at times, stole some of the joy. The shift also introduced me to a set of dynamics very different from those in a free, open, community-driven project. I guess those feelings are natural, but they added to the emotional baggage I was already carrying. Again, I never learned how to deal with this kind of emotional weight.

When I look for stories from others who’ve gone through similar transitions — especially founders — I find almost nothing. Most public conversations focus on success stories and funding rounds. I can’t imagine doing all of this alone, so I’m grateful Marek and I are pushing through it together.

As if that wasn’t enough, I topped off the glass with a running accident that led to a knee dislocation, torn ligaments, and a nerve injury — something that could have left me with a permanent foot disability. The aftermath forced me to navigate the German healthcare system, and I felt abandoned by it. No one emphasized the severity of the injury. Some suggested I just forget about it and move on, and one even told my wife she should cook healthy meals so I could lose weight. It was tough — very tough. I pushed and pushed until I got my first surgery in Barcelona (which I paid for myself), stayed there for a month, and scheduled a second surgery for September. Thankfully, I could afford it — but it shouldn’t have been that way.

So here I am, dealing with anxiety bursts. If you see me exhausted, quiet, or not being the social, extroverted Pedro you’re used to — that’s why. I’m working on it, and I’m optimistic that I’ll come through this stronger.

My emotional chapter at Shopify is over. It was rough, but I learned a lot about myself through an emotional lens. My nerve is recovering, my ligaments are eager for reconstruction, and we’ve built the best team we could have imagined to build something amazing for app developers. What more could I ask for?

Please, listen to yourself. Slow down. Give yourself time to be present. The world — especially the tech industry — moves fast, but you don’t have to. That speed isn’t natural to life. Aligning yourself with life’s rhythms gives you the clarity and space to take care of yourself.

The author explains how enthusiasm for creating in the digital world lays the perfect foundation for precarious work. When you’re passionate about something, you can lose sight of yourself—blending your identity with your employer, celebrating their achievements with a “we,” or investing insane amounts of time without receiving anything in return. It’s what drives some people to spend their Sundays editing vlogs, or developers to evangelize their work environments as the ultimate place to be.

It’s increasingly common for companies to go beyond the traditional salary-for-time relationship by tapping into the emotional space where people develop their passions. You’re no longer just working for someone—you’re meant to feel passionate about what you do here.

Enthusiasm is a powerful force. It’s magnetic, it attracts people, and it’s contagious. But we live in a capitalist world, and the moment people gather around something, transactions of value begin to take place, a market emerges, and what once was a passion can turn into a burden. What once felt like “I enjoy editing videos” becomes “Why am I spending my Sundays editing videos?”

Part of you still believes you’re doing something meaningful, but the precarious reality you live in starts to feel uncomfortable. The PRs you merge or the free shoes a brand sends you won’t pay your bills. Capitalism doesn’t leave anything unmonetized—including enthusiasm. The idea of being an “indie developer” is built upon this tension.

In an ideal world, capital wouldn’t interfere with your passions—and you’d have the tools to evolve your relationship with your own enthusiasm. If you look around, you’ll see developers whose passion led them to start companies, only for them to later step down as CEOs or leave entirely, returning to their roots. Back to enthusiasm in its pure and isolated form.

Have you ever had the impulse to do something and had to stop to assess whether it was truly what you wanted—or just a “fake passion” that inertia led you to pursue? In a world where everyone seems to have a passion—or at least pretends to—it can be emotionally difficult not to have one. Can’t it?

I’ve experienced all of this myself with Tuist. We started it driven by enthusiasm. That enthusiasm attracted people, companies, and business incentives from others. At some point, we had to evolve it to avoid doing precarious work. It wasn’t something we actively planned—it just happened.

As I mentioned, enthusiasm is magnetic. In our case, we built a company around it. And with that, enthusiasm started to mix with business, and I had to do a lot of personal work to accept that evolution. It’s still tricky at times. Sometimes I want to do things just because they’re fun, but the business side of me questions whether they’re aligned with our goals. That internal conflict leaves me with tough emotions, as I can’t simply act on joy without considering the business implications.

I recently watched a documentary about the Spanish chef David Muñoz, who expressed something similar. He’s passionate about cooking, and a business formed around his creations. That came with a team and responsibilities. But he admitted that he misses spending hours doing what he loves most—just cooking. I feel the same way with Tuist. As a CEO, I carry many responsibilities. I can fulfill them, but I also need to give myself space to enjoy the pure code crafting that brought me joy in the early days.

I also think about the people who contribute to or work on Tuist. They have their own passions. I don’t want to impose any on them—but when the work itself is fun, that overlap can happen naturally. So how much of it is my responsibility, as a founder, to help them set boundaries? And how much is on them? Should there even be boundaries? I believe so.

I didn’t set any for myself at my previous employer, and when I was laid off, it hurt more than it should have. As I mentioned earlier, when “you” becomes “we,” and all your passions are channeled into the company, you start to distance yourself from who you are outside of that world of enthusiasm. That can have serious mental consequences. I learned that the hard way.

What’s the solution? I’m not sure. The author suggests that passion and work are healthier when separated. It reminded me of how I often joke about opening a Spanish omelette restaurant in Berlin and coding just for fun whenever I feel like it.

I think having an ongoing dialogue with yourself—one that prioritizes your emotions and well-being above everything else—is key. Stay connected to yourself, and don’t feel pressured to follow a passion just because everyone else seems to.

I think the first event that led to this phenomenon was the layoff at Shopify. I had been trapped in the climb-the-ladder model, given a lot of time and emotional capital, and gained momentum that was suddenly interrupted. As I processed those emotions, I later realized that I was reaching a point of burnout at the company, so on the positive side, I'm glad that it happened before it had been too late.

The second piece was starting a company. It's a very vulnerable position where you are this tiny fish in an ocean of business where dynamics are nothing like what you might have read in books or on the internet. While in programming things are more logical: you've got a problem, write the software to solve it. In business, you are invaded by questions and insecurities: Is this the right decision? Should we be jumping on that trend? What if the business doesn't take off? Logically, I can provide answers to those questions. Emotionally, I'm not prepared to process them, which makes things uncomfortable at times. There are also other emotions, like disappointment with some untold realities, that blend in weird ways. I'd love to eventually write a book about this transition because as a developer, you are barely told about many of the realities that unfold.

The last piece, which I did not expect, was an accident while running that led to torn ligaments and, worst of all, damage to the peroneal nerve, which disabled one of my feet. I spent one of the most vulnerable moments of my life navigating the German health system, trying to find a doctor who could explain and provide answers to the problem, and in some situations being treated in not very humane ways, in some cases making me feel responsible for the accident because of my weight. It was rough, and even though I eventually got the surgery (I had to pay for it), fears about whether this will recover keep coming back because every day I have to see my foot not responding to my instructions. If you've ever had a nerve injury, you probably know what I'm talking about.

So these three things, mixed together with the sprinkle of social network dynamics that favor competition, radicalization, and overall negative emotions, leave me ending my days filled with anxiety, mentally and emotionally exhausted.

To fight it back, I'm trying to slow down. I'm minimizing mental concurrency and the time that I spend on social networks like LinkedIn whose dynamics I'm not comfortable with. I'm also learning to be okay with not being able to chew as much as comes my way, and giving myself time and space to be present with myself, to go out and do analog activities that have nothing to do with business or coding, like taking photographs. I'm trying to lean on the human and social side of things, being supportive rather than competitive. Being human at Tuist is what makes us so unique, and I believe it's what will lead to the type of company we want to shape. I'm also accepting that life sometimes sucks, and that there are dynamics that, even though I disagree with them, like how the layoffs happened at Shopify or the accident while jogging, are simply part of life. What I had experienced until that moment was unusual. It takes time, but I'm getting there. I just came back from the gym, prepared myself a coffee, and gave myself some time to write these lines. How is your Monday starting?

Talk to engineers, and you'll hear excitement about new language capabilities—features that, while powerful, often add build-time complexity and degrade performance. Swift Macros are a perfect example of this. It’s exciting to see the language explore new directions, but if that comes at the cost of slower compilation and unreliable incremental builds, it feels wrong. Executives feel this too. If you maintain a large Xcode codebase and compare your team’s velocity to a web team’s, the difference can feel like an order of magnitude. So it’s no surprise when leadership asks engineering teams to explore React Native. When an app is merely a native presentation layer, abstracting the platform to gain speed becomes a necessity.

Now, add to the compile-time slowness the strong coupling between the compiler and a macOS host, and you’ve got a recipe for disaster. New LLM-based app development experiences are surfacing this problem more visibly than ever. Developers are expecting Apple to respond—but enabling meaningful improvements takes a long-term vision and multi-year effort. That’s something Apple seems to have lost in recent years.

They forked the web ecosystem and actively hindered it—yet the web kept building momentum. Now that momentum is paying off. I don’t know if we’ll end up “vibe coding” our apps with AI prompts, but it’s clear the way we build apps is going to change. And we can’t afford the slow compilation and feedback cycles that Apple imposes. For many new projects, React Native will be the default. You type a prompt, get your skeleton, and you’re coding in seconds.

I love Swift, and I enjoy being close to the platform—it means fewer abstractions. But I fully understand why organizations crave abstraction. And I’d love to see Apple respond to that. They have the resources to make it happen.

I wish they would acknowledge that they’ve lost their north star—but that they’re working on a strategy. Right now, it feels like they’re trying to push Swift in every possible direction while the core problems remain unresolved. How did it take so many years to address frequent merge conflicts? Will it take another decade to automatically copy dynamic binaries to the right destination in the build graph?

Or will they finally define and communicate a plan for the future of build tooling? Are they even thinking about this? If so, why not talk about it publicly? I’d love to follow along.

All of this presents great opportunities for Tuist. But I’d much rather our work felt like we were extending a solid platform—instead of hacking our way around its shortcomings.

Hence why I'm so excited about all the creative energy that's going into the space with projects like Tart, Lume, or Curie. Sure, there's still a long way to go, but incremental steps are being taken towards enabling that commoditization. Even Cloudflare announced Linux Containers for their workers as part of the platform. Ideally, we move to a world where getting a virtualized environment is just one API call away.

I remember during my time at Shopify when we had calls with the MacStadium team, my recurrent feedback was: you guys should productize your offering and make it developer-friendly. Many developer tools in the space, including Tuist, would pay for some kind of "Remote macOS Containers as a Service." Many developer tools require teams to leverage their CI/CD pipelines to build and push products. Imagine if you didn't have to do that. We want to move to a world with Tuist where you can create a preview or a release right from your phone. And for that, we need to access macOS environments quickly and cheaply.

I'd be lying if I told you that we are not already thinking and starting to put some work into making this happen. We are, and we want to offer that investment to our users so that organizations can reduce their costs down to just the infrastructure costs. It's easy. You place your AWS or Scaleway API keys, and we provision CI runners automatically or manually and plug them directly into GitHub or GitLab organizations. And those are the same environments that we can reuse to build your releases and previews, and sign your apps. No more YAMLs and complex automations. This is the world that we want to enable with Tuist.

BuddyBuild was moving in that direction until Apple acquired them and thought what the industry needed was CI but embedded into Xcode. Once we complete the current cycle, we'll start exploring this and content addressable stores. This is a muscle that we need to build because it'll bring the ecosystem closer to the developer experiences that other ecosystems have access to. And we'll advocate for any open source solution that gets us closer to enabling that future.

This post is written by a human with its grammar reviewed with Grammarly.

However, markets have a ceiling, and even though software has close to zero marginal costs, your software business might require humans, who are expensive—very expensive. And this is something hyper-growth business models are incompatible with.

Executives at major tech companies have found the perfect tool to work around the problem: AI. "We are AI-first companies," they say. It'll often be used to eliminate human costs, such as support teams. In other cases, like Duolingo, they'll use it to break through the market ceiling. "We need AI to scale learning", they said. What they really meant is that they need AI to dropship slop courses to continue exploiting humans feeling of learning progress because they complete streaks.

If you think you are indispensable in this new mission of AI-first companies, let me tell you something: it is mostly storytelling. You are digging your grave because you are a cost to the company, and your next performance review will be in the hands of LLMs. "Let us know why you can't do this with AI" is the new mantra. This continues with a "don't worry, this is about empowering you" so that you don't wake up from the dream of the company's mission. Once again, the ultimate goal of a company is to maximize profit; the ultimate goal of a hyper-growth company is to do so at all costs, including your empowerment or well-being.

Good luck to those companies that want to create companies where humans are dispensable. The challenges we face require more humans and more collaboration, not less, which only benefits a few. And yes, that means we can't work 24 hours a day, 365 days a year, so what? If this will be the new trend, I'm not on that camp, sorry.

This post is written by a human with its grammar reviewed with Grammarly.

The thing is that I'm aware that this is unhealthy. I don't like it. But there's this idea that I've built a brand, either mine or Tuist's, that would fade if I'm not active where everyone is. It's a bit nonsensical, because we have no control on those platforms over how we are presented. Perhaps a brand might even deteriorate there because you might end up morphing it into a meme-posting machinery, but still, that thought is recurrent, and I believe it is the trigger that brings me back, along with the idea that people are talking about the new thing. So what? 5 new vibe coding tools, an add-AI-to-x tools, and a couple of new JS frameworks... Again, so what? I don't want to sound cynical. I like tech, but a big part of the industry is hype cycles, because the tech industry is technology embedded in capitalism, and therefore it needs to reinvent itself. Today you are generating Ghibli Studio images, and tomorrow you'll be generating your TikTok dances, the day after you'll be an expert in the process of electing the new Pope, and in two weeks you'll show your expertise in power outages in Spain.

I'm happy we decided this is not the game we want to play with Tuist. It's stressful, tiring, and takes the focus away from the joy of the craft, which is what we love doing. It feels uncomfortable at times. Should we be doing like the others? But at the end of the day, we don't control those algorithms. They are controlling us and making us part of the exploiting machinery, ensuring there's stuff we can feed people with. We are placing a focus on our blog. Writing from the passion for what we love, and going deep into those topics. Embracing standards such that people can pull the content when and how they feel. If we are present on any social platform, we try to be on the ones that we think haven't "enshittified" yet.

I'm trying again. I want to be present. I want to remain mentally healthy. I want to shift the focus from the telling to the doing. I don't want to feel like a zombie hamster starving for "new" stuff, or feeling I have to contribute to keep other hamsters fed too.

From highly collaborative apps to technologies that transform web browsers into virtualization platforms, there are countless people building for the web and pushing it in myriad directions. This diversity can sometimes be a drawback—especially if you’re trying to build a company—but it lays the groundwork for unprecedented innovation. People feel invited and inspired to tinker with new ideas.

Apple, too, built an ecosystem—an ecosystem of apps—and invited developers to join. They provided tools, frameworks, and a language, creating a foundation upon which developers could build their apps. Innovation flourished at the application level. This approach worked well for many years while Apple focused on expanding its hardware offerings and, more recently, its services. However, it never felt truly inviting, and it still doesn’t.

First, it excludes those who can’t afford the hardware and prefer platforms like the web, which are universally available and accessible from anywhere. Second, it alienates developers who don’t want their capabilities limited by proprietary tools, frameworks, and even an open-source language that remains tightly controlled. They prefer platforms offering greater freedom. Finally, it distances those who don’t align with Apple’s mission and view contributing to its open-source components as indirectly supporting Apple itself. They don’t see these building blocks as true commons.

This is creativity left untapped—creativity that could have advanced Apple’s build system, making it more deterministic and optimizable. It’s people who might have better understood the issues with LLDB and proposed solutions to ensure developers can effectively debug their apps, or who could have taken SwiftUI to other platforms by integrating it with native rendering technologies. While we’ve seen sporadic efforts from individuals trying to drive change, these initiatives often fade because they ultimately depend on Apple’s approval—a “yes” or “maybe” that requires internal discussion and rarely materializes.

I believe Apple’s current struggle to keep pace with innovation is a direct consequence of this missing creative energy. Their ecosystem can no longer ignore the outside world or the advancements happening beyond its walls, and developers naturally expect a response from Apple that never arrives.

Some suggest that throwing money at the problem might be a solution, and while that could yield short-term gains, Apple would soon find itself back in the same position. The momentum of more inviting ecosystems compounds over time in ways money alone can’t replicate.

I firmly believe Apple needs a mindset shift to make its environment more welcoming to this creative energy. If they succeeded, people would not only work to advance the ecosystem but also become stewards of it, much like Apple itself. Recent job postings from Apple seeking engineers to focus on Windows are a promising first step, but I’d love to see an approach centered on inspiring people to take Swift to Windows. What motivates Windows developers? What drives them to contribute to Swift in the context of Windows every day?

Microsoft nailed this with VSCode and TypeScript. They built an ecosystem that sparked countless ideas and laid the foundation for the AI-based code editors we enjoy today. It took recognizing that open source is an aspiration for many and that showing you care can profoundly shift how people perceive you.

This creative energy is absent from Apple’s ecosystem due to its closed, proprietary nature and the tight coupling of its toolchain, paired with Apple’s firm control over the direction of its projects. We also lack a visionary—someone to oversee and communicate where things are headed, assuring everyone that Apple cares about Swift breaking free from its ecosystem. Imagine someone saying, “Yes, SwiftUI should have been open source, and we’re taking steps to make that happen. It’ll be open source because we want people to take it to new platforms.”

This is a long-term investment that’s hard to justify because the returns are distant in both time and impact. A brilliant idea born from a more open toolchain might emerge years from now, and its connection to that openness might not be immediately obvious. Will it happen? Who knows—it’s Apple. But I believe it will require new leadership that embraces a more open, ecosystem-building approach. A leadership that shares a vision for their technologies beyond Apple devices.

With codebases growing larger and the speed of business demands increasing, we believe Tuist should position itself as a productivity tool for app developers. The "app developers" part is crucial. While some challenges extend beyond app development, we believe app development is where we originated, where we understand the challenges thoroughly, and where we can deliver the most value. Other ecosystems already have established productivity solutions, so venturing into them would be counterproductive.

We believe we should cover the entire lifecycle, from the early stages of an app to its distribution and the scaling of its development. Apple provides some basic tools, but they are insufficient. Developers must handle initial plumbing themselves and eventually delegate it to what companies call "platform teams." We want to be that virtual platform team and eliminate all plumbing work. Tuist needs to feel "plug & play." Its adoption should be as simple as installing a GitHub App in your repository. The developer experience we aim to enable already exists in other ecosystems. The web has Vercel. React Native has Expo. We want to play a similar role in native development.

You might think you don’t need this—that you can grab the tools yourself and wire everything to build your own experiences. I understand. Many people felt the same about managing their servers and using Kubernetes to orchestrate their own deployments. But let’s be honest: that’s fun to build, but not fun to interact with every day. All the energy spent maintaining such a stack is energy not directed toward solving problems. I like to say that your building momentum is frequently interrupted in app development. There’s something magical about doing a git push and seeing a URL to preview your changes shortly after.

Now the question is how to enable that future. We are limited in resources and capital. Some might see this as a limitation, but I see it as an asset. Limits force us to think creatively, and they’ve helped us realize that we have the most valuable asset in the developer ecosystem: a community. Communities take significant time and human capital to build, and at Tuist, we’ve invested heavily in that since we wrote the first line of code in 2017.

I touched on the role of communities in the commoditization trap. The long-story-short version is that a community is the best asset a company can have these days. For instance, Mobile CI is plateauing because they failed to build a community. Every company builds communities differently. We want to grow ours on the same foundation that gave birth to the community: open source.

We had to close-source part of Tuist because the project was at risk of free-riding, but we want to return to everything being open source, and we have a plan in place for it. But first, let’s talk about open source for a bit.

We want to continue developing open-source technologies. We are shifting the focus away from project generation, so expect innovation in other app spaces. These are gifts to the community to foster innovation. We’ll then figure out how those technologies can be extended by leveraging the capabilities of a server to build a revenue source for the company. A server brings three elements:

• A remotely accessible database - A public HTTP interface to interact with - Background jobs

We envision a model where the client-side technology can work independently without the server. You can build your own server using our client-side open-source components if you want—they’ll be permissively licensed. We’ll support any open-source efforts that align with this direction, like Lume’s virtualization solution.

We’ll also make part of the server open source with a permissive license. This means you can self-host the server too and not pay a dime for it. You’re right—we need to address this. Experience has taught us two key lessons:

1. The needs of large enterprises differ greatly from those of small and medium companies. 2. Large enterprises are the ones with significant capital to invest in these tools.

Instead of trying to capture 100% of a market—which traditional companies attempt, only to end up building vendor-locked ecosystems—what if we figure out how to capture value from the 20% of large companies that could bring 80% of our revenue (Pareto principle at work)? We could treat the remaining 80% as companies contributing other types of capital: - Feedback - Word-of-mouth marketing - Code contributions

Business owners often view everything through a financial lens because it’s measurable. But there are other forms of capital that make a company valuable, which we continue to struggle to quantify. The companies that value these are the most likely to thrive.

For Tuist, we’ll place some features or capabilities under a different license that large companies would need to pay for, while everything else would be MIT-licensed with a ready-to-deploy Docker instance. Note that over time, hosting Tuist will become more complex—not because we’ll force complexity, but because it will naturally evolve, especially as we invest in capabilities like low-latency cache servers and features based on running ephemeral builds. At that point, even that 80% might be inclined to pay for us to host it.

This isn’t a new model. You see it in GitLab, PostHog, Cal.com, and Grafana. It’s just not common in the app development productivity space because companies there often have a strong sales and business profile. We’re bringing a different take on business.

There’s one catch to the open-source model: besides marketing being more effective because you build a loyal community that spreads the word organically (as opposed to throwing money at marketing, which is expensive and doesn’t guarantee results), you open yourself to a diverse pool of talent and ideas that contribute to the project. Let me tell you, you can’t beat a product built by a community. We’ve learned that with Linux. I’m surprised we haven’t seen more of this in this space. That’s why we’re enabling it with Tuist.

So, picture a world where Tuist is open source, with some enterprise-related features or capabilities under a different license.

To enable that vision, we are focusing strongly on the following pillars:

Foundational blocks

We are investing heavily in automation and establishing the right foundations so people can build with them easily. Contributing to Tuist should feel like playing with LEGO. This is why we’re investing in a design system for the CLI and the web, Noora. Developers without much design experience can contribute features and design them themselves.

Standardizing data and making it accessible

Apple’s development environment is well-known for its proprietary formats. We’re going to standardize them and make them accessible via the web. Want to access the results of your last build? It’s just one request away. The web is a tool for accessibility, so we’re embracing it fully. As part of Tuist, we’re building an API—currently used only by the CLI—but we plan to productize it so people can build their own tools with their project data. The API will be part of the product, not just an implementation detail.

Virtualization capabilities

We’ll invest in developing the ability to run virtual ephemeral builds—first, to enable web-driven workflows like releasing an app or creating a preview with a button click, and second, to break the strong vendor lock-in organizations face with CI providers, allowing them to take control of their data and infrastructure.

Top-notch DX

Developer experience (DX) is front and center in Tuist. We can’t afford to degrade someone’s experience compared to Vercel, Supabase, or Linear. Tuist needs to be a joy to use—something whose value is conveyed through its design. We don’t want it to be a tool made by developers trying to be designers. No, we need to think deeply about design, crafting workflows and visual hierarchies that are delightful to navigate.

I’ve never been this excited about Tuist’s plans. I firmly believe this strategy will pay off in the long run. As mentioned, it requires significant human and time capital investment. But while other companies come and go, outcompeted by better open-source alternatives, we’ll keep rowing, building the best and most open development productivity tool for app developers.

Imagine a new market, say, one based on AI. You might be among the first companies to dive into AI-generated UI. Everyone’s impressed by this novel need you’re addressing, and it’s tempting to believe you’re uniquely positioned to dominate the market. But you’re not. Your company lacks an economic moat. You’re easy to replicate.

As I mentioned in If a business can be open source, it'll be open source, an open-source solution is likely to emerge. It might take longer, but when it does, it will probably limit your ability to capture value—most likely due to its fairer pricing and superior product. Open source can afford to do this with far less capital involved.

Some companies try to defend against this by expanding their offerings. There’s no better example than CI (continuous integration) companies, which now provide a suite of development tools—from caching to test analysis—to stay competitive. But once again, many of these solutions are easily replicable in open source. Even more surprisingly, some don’t require a server at all. This expansion can be a tricky move: you risk drifting from what your users know you for, reframing yourself as something more comprehensive. That shift can take years for people to grasp. In fact, it’s a challenge we’re currently facing at Tuist, where people still see us as just a project generation tool.

Another approach companies take is capturing value through infrastructure. The software has value, but without well-managed infrastructure, that value isn’t fully realized. This depends on the type of software. For a native app with self-contained value, it’s trickier—though people are also less incentivized to open-source it in the same form. Your advantage lies in maximizing platform capabilities. You’ll always have an audience there, but don’t expect endless growth. Just ask Sketch. Betting on something other than the web might give you an early edge, but it can leave you at a disadvantage in a world that favors collaborative solutions over individual ones. People crave connection—they love the Figmas, Notions, and Slacks of software.

That said, providing value through infrastructure is easier to replicate if you’re up against a cloud giant like Amazon. All they need is enough incentive to target your market. That’s why Google acquired Firebase and Fastlane—they saw an opportunity in the mobile space, though it didn’t fully pan out as expected. I wouldn’t be surprised if Firebase gets sunsetted in the coming years. A strong example of capturing value through infrastructure is Supabase, which we use at Tuist. The software has value, but there’s even more in managing and scaling your database—something they handle for you. It’s not something we’d ever consider doing ourselves because we’re focused on building our product.

A better model is creating an ecosystem and a community around it—one built on long-term incentives, not short-term gains. This distinction matters because it’s easy to create the illusion of an ecosystem or community by throwing money at it. But the best ones take time to nurture. You can tap into basic human needs and desires—like the pursuit of higher status—but that only works until people realize meritocracy is a dystopian mirage. Take the “indie developer” dream, for instance. We all fantasize about making a living from our software. Many products target these communities, feeding the illusion that their tool is the key to success, just like the stories they’ve heard. But as YouTube has shown, it’s more complicated than that. It might work briefly, but it can quickly turn into deception.

In my view, the best model is the one GitHub, Strava, and, to some extent, Spotify have mastered. These platforms amass social capital that makes leaving emotionally unthinkable. A GitHub profile is a developer’s CV. A Strava profile showcases a healthy life and connections with others. Spotify’s profile curates your musical tastes with recommendations no one else can match. This model is incredibly hard to replicate today. It’s not just about a critical mass of users—you need a product designed to capture that value fast, before anyone else does. Years ago, who’d have thought our profiles on these platforms would become so valuable?

In a tech world moving at breakneck speed, where society grows more individualistic despite collaboration yielding better outcomes and more happiness, I believe open source—and its community component—offers a sustainable alternative. The economic moat lies in its community value, rooted in the idea of building shared commons, rather than struggling to stay afloat in an industry that commoditizes itself.

The stack

Technologies can be broken down into layers, and CI is no exception. Starting from the bottom:

• Machines: We need environments—physical or virtual—where a set of steps can run. This is already offered as a service by most cloud providers. The availability of Apple hardware has been somewhat limited, but this is changing as more players enter the space. - Virtualization: CI services run builds in disposable, virtualized environments to prevent data leakage across builds. In the Linux world, this is highly commoditized with tools like Docker or Podman. For macOS environments, Apple took the first step toward commoditization by releasing the Virtualization Framework. Tart followed with a source-available, Docker-like solution, while Lume and macvm joined the game with open-source-licensed alternatives. - Orchestration: For Linux environments, where provisioning new environments is fast, orchestration is typically handled by the cloud provider. However, macOS is a different story. Since macOS images are not lightweight, you need a system that can provision a fleet of Apple hardware, configure the environments, load them with the appropriate images, and make them available for use. - User Layer: At the topmost layer are the features users interact with directly (beyond just the UI). This includes viewing logs, retrieving them along with build artifacts, and parsing and executing pipelines.

If you use a CI service, you probably don’t think about this structure. But once you understand how it’s organized, it’s striking to realize how close we are to full commoditization. Let me highlight some key developments that led me to this conclusion.

The commoditization of the space

In 2019, GitHub released GitHub Actions, which introduced hosted runners alongside the concept of “bring your own runners.” You could either provide your own runners or use partners that integrate directly into your GitHub organization. This meant GitHub would handle the user layer and the entire stack—unless you chose to bring your own.

Let’s be honest: it’s hard to compete with GitHub’s user-layer experience. It’s embedded where collaboration happens, and its proximity enables features that CI providers can’t replicate—such as declaring permissions for the exposed GITHUB_TOKEN. GitHub also built a rich ecosystem of reusable actions to base your workflows on.

This shift gave rise to companies like Cirrus Labs, Cirun, and Depot, which handle the runner provisioning for you. From the layers above, they manage orchestration, while GitHub takes care of the rest. The adoption process is remarkably straightforward, and there’s no need to migrate pipelines from one proprietary format to another.

GitHub isn’t alone in this trend—GitLab and Forgejo also support bringing your own runners.

Another recent change is in virtualization. Tart brought Docker-like concepts to Apple’s Virtualization Framework, but now it faces competition from permissively licensed alternatives like Lume and Curie. Virtualization is getting cheaper. While Tart may still lead in capabilities, open-source projects have a knack for catching up quickly due to community contributions. I believe it’s only a matter of time before they’re on par.

What’s keeping people with CI providers?

I ask myself this question daily, and I think the answer is straightforward: vendor lock-in. By design, users are tied to platforms they chose years ago through proprietary YAML formats that are costly to migrate and ecosystems of steps that tightly couple their automation to the service.

But people are waking up. Dagger is leading the charge by proposing that automation shouldn’t be tied to a single company. Pipelines should be portable, just like OCI images. Absolutely! Dagger builds on a foundation that doesn’t yet seamlessly support macOS-dependent builds (due to its approach to virtualizing steps), but there are still many ways to make automation portable. I wrote about this in Tuist’s blog. Your automation should belong to you, not a company.

CI providers know they must offer more to differentiate themselves from GitHub Actions. However, they often lack the expertise to meet developers where they are. Instead, they double down on vendor lock-in with serverless solutions that could simply be open-source CLIs. This confuses users—CI companies were supposed to focus on CI, but now they’re tackling signing, release management, and security promises that large enterprises obsess over. Meanwhile, solutions like Runway are emerging, focusing on doing one thing exceptionally well and easily capturing customers.

Plateauing

Looking at the layers above, orchestration is the next to commoditize. We’re one open-source project away from a service where you input an AWS or Scaleway key, install a GitHub app, and you’re set. This is already happening in other domains, like app hosting and database hosting. If an orchestration layer goes open-source and invites companies to collaborate on building the best plug-and-play solution for your Git forge, CI providers could lose market share quickly.

I predict this will happen. Orchestrating virtualized macOS environments will become cheaper, potentially even offered as a foundational service for others to build upon. This could spark more innovation in the space—an area where mobile CI has lagged behind the web, largely due to innovation being locked in proprietary systems. That’s why I’m excited about this shift. We need more players thinking creatively, and commoditization enables that accessibility.

At Tuist, we’ll ride this wave of commoditization and explore how virtualization can solve some of our needs and challenges while delivering a better developer experience.

1. People are familiar with the term. 2. You don't need to go back to first principles.

This happens not just in the context of app development productivity, but everywhere else. Someone uncovers a new problem or need, for which they build a solution—not necessarily the best one today, but the best one at the time, considering the constraints then. Then, you see a stream of companies jumping into the new markets. Eventually, everything commoditizes, and we get stuck with something that doesn't feel right.

Rinse and repeat.

This is how nightly builds feel to me. The sunsetting of App Center and everyone's rush to profit from it with yet another solution like App Center smells fishy to me.

But what would be the alternative? If we go back to first principles, nightly builds solve testing changes and providing feedback. However, nightly builds are detached in time and space from where the changes originated, often pull requests. Pull requests are the place where conversations around changes happen. Trying to do something distant from that creates a source of friction and a foundation for even more complexity.

Feedback needs to happen in PRs.

And that requires creating builds (which in Tuist we refer to as previews) quickly, when needed, and from anywhere. Let's break that down:

1. Fast: You don't want to wait half an hour for a preview because, by the time you get the build, the PR might have already been merged. That's why we built binary caching, and we plan to invest in it further. 2. When needed: You should have control over when you want a preview and of what, because, sadly, macOS computing resources are still expensive. You don't want to depend on some pipeline being configured to get what you need. 3. From anywhere: By posting a comment on a PR, sending an email, asking your LLM of choice, or tapping a button in a mobile app.

We are actively working on #1, and we are building technology and infrastructure to enable #2 and #3.

Are previews nightly builds? No, they are not. They have in common that the token of exchange is an installable build. The former aligns with collaboration expectations, while the latter makes collaboration less enticing.

Does it suck from a business perspective? Oh yeah! We need to market a new concept and bring people back to the problem that originates the need for something like nightly builds. But this is the type of company we are building—one that focuses on the problems, strives to build the best solutions, and challenges the status quo, adapting as the environment changes. A lot has changed since app builds were proposed, and it's time for something different.

If you want to build a Docker image from Forgejo Actions when using Docker as a runner, you'll have to use Docker-in-Docker.

Steps

1. The first thing you'll need to do is enable privileged mode when launching task containers. This is done by setting the attribute container.privileged to true in your runner's config.yml file.

Note: This has security implications, so use it with caution. Before running actions for external contributions, ensure that they are not malicious.

2. Once you've made this change, restart the runner.
3. The next step is configuring your pipeline to start a sidecar service with Docker DinD:

name: MyProject
on:
 push:
 branches:
 - main
 pull_request: {}
jobs:
 build-image:
 name: Build image
 runs-on: debian-latest
 container:
 image: node:20-bookworm
 options: >-
 --privileged
 env:
 DOCKER_HOST: "tcp://docker:2375"
 DOCKER_TLS_CERTDIR: ""
 services:
 docker:
 image: docker:24.0.5-dind
 options: >-
 --privileged
 env:
 DOCKER_TLS_CERTDIR: ""
 steps:
 - uses: actions/checkout@v3
 - name: Install Docker
 run: |
 apt-get update
 apt-get install -y ca-certificates curl gnupg
 install -m 0755 -d /etc/apt/keyrings
 curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
 chmod a+r /etc/apt/keyrings/docker.asc
 # Add the repository to Apt sources:
 echo \
 "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \
 $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
 tee /etc/apt/sources.list.d/docker.list > /dev/null
 apt-get update
 apt-get install -y docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
 - name: Build image
 run: |
 docker build -t my-project .

Note: The above pipeline is designed for Debian as the OS, so you might need to tweak it according to your specific requirements.

That's all you need. The --privileged flag is one of the most important elements - without it, things simply won't work.

When developers regularly use their own products (dogfooding), they naturally identify and address pain points. Without this practice, teams must rely solely on empathy for users' challenges. In our increasingly individualistic society - partly influenced by current social media dynamics - genuine empathy is becoming less common.

Entire ecosystems suffer from this disconnect. Take localization tools, for instance - using them often leaves me wondering if their creators have ever experienced them from a user's perspective. Investigation typically reveals they don't localize their own tools, which explains the subpar user experience.

While dogfooding can be challenging in some contexts, leadership should integrate it into company culture whenever possible. During my time at Shopify, though developers rarely maintained their own stores, they utilized a tool called "tophat" that simplified testing new changes. This led to more meaningful code reviews based on actual usage experience rather than just inspecting code or confirming passing tests.

At Tuist, we build our CLI and app using our own tools, using them daily. This creates a natural alignment between the improvements we identify and the needs of our users. While users typically only report major blockers, daily usage reveals numerous small opportunities for enhancement that collectively create exceptional products no competitor offers.

For example, we recently began improving our CLI's user interface, not because of user complaints, but because our own daily usage showed clear opportunities for enhancement. This approach to continuous refinement is what makes products like Linear superior to alternatives like Jira.

Developer tools are uniquely positioned to benefit from this practice. Developers at GitHub use GitHub; developers at GitLab use GitLab. Companies that create developer tools without using them internally are missing a crucial opportunity, and their products inevitably reflect this disconnect.

Something that slightly bothered me about the alternatives to native development is that they were strongly dependent on Google in the case of Flutter, or Expo, which Meta recommends as the framework to use because they deemed it's not their responsibility to address that part for the community. These companies became dominant players in those spaces respectively, and that came at the cost of killing competitiveness, which fosters innovation.

Lynx challenges the status quo, in the same way AI is challenging Apple's ability to catch up with the rest of the industry. And it does so by presenting a technology that's UI framework agnostic. It comes with support for React, but people are already working on adding support for Vue, and I expect SolidJS, Svelte, and others to follow soon.

In other words, Lynx paved the way for other frameworks to support mobile development, unlike React Native, which coupled its solution to React as a framework. It also comes with a fast Rust toolchain, so technologies building upon it don't have to re-invent that part. This is an area where Meta said, "We use different tooling at our scale, so we are not going to bother to support a toolchain," and if you ask me, that's a shame. Lynx recognized that both go hand in hand, and that's amazing.

It's still early days for Lynx, so the future is a bit uncertain, but if I had to make a bet, I strongly believe the fact that it allows other UI frameworks to build upon it will create a unique ecosystem of tools, resources, and libraries that React Native won't be able to compete with.

It's a matter of time, but if ByteDance does well at building a thriving community, I think it can happen. The React Native ecosystem could have gone a similar path, owning an integrated toolchain, and providing the ecosystem with the resources to build great packages, but instead sold it to Expo. Expo is amazing. I think having only Expo is terrible.

With Tuist transforming into a platform, I want to play with Lynx to see where we could bring value on the server-side, for example easing the distribution of previews, providing sign-in to the bundling process, or conceptually compressing mobile intricacies. Or maybe helping them break the dependency on CocoaPods.

The future of mobile development is bright.

This made me think about the role that AI could play in reducing the cost of maintaining OSS. As you might know, the classic challenge of open source is the cost of maintenance. This is, in fact, the reason why we started working on evolving Tuist into a business.

Issues and pull requests pile up, you don't have the time to review them all, and you have to process the emotions that come with feeling like you're lagging behind or not meeting the community's expectations. But if most of this can be delegated to AI, that changes everything.

I believe we, open source maintainers, should invest in having the right CI checks to ensure the code that is merged is of the quality we want to ship, along with rules to guide GitHub Copilot to do its best work. How those rules are provided to AI agents is still an evolving territory, but once it settles down, I think it makes sense to invest in providing agents with that context.

Who knows... maybe we'll get to a point where GitHub Copilot can also reject PRs that don't align with the direction/vision of the project, or merge others automatically. I think that would be fantastic.

In the context of open source companies, a subject I've been thinking about a lot lately, this approach gives you access to a developer workforce that's not limited by your location or your number of employees. It means you can move much faster than your competitors, at a much lower cost, allowing you to focus on building revenue from large enterprises while innovating and watching your community foundation grow.

I don't know about you, but I think this is a unique strength. When I think of companies working in the same space as Tuist, none are approaching business this way, so I believe we're in a good position to take advantage of this opportunity.

Note this isn't true of all companies, but it's really hard to find one that stays true to a set of values. Personally, I don't care about the personal data they've collected from me, or the value I've generated on platforms like X or GitHub. Years ago, I had a different connection with the idea of reputation, but breaking dependency on that was very liberating. I don't share anything of value in those places, and if something has value, I make sure I use technology that ensures I'm the owner of my data—like Obsidian or Git forges where I can take a Git repo elsewhere if the platform becomes enshittified. Seeing X, Reddit, Strava, and many others building walls was a wake-up call for me. I still use them, but I don't engage with them beyond posting or reading small things here and there.

With Tuist, it's a different story. We are generating a lot of value—not just through the code that we bundle and release as a CLI or a publicly accessible server, but also through resources, ideas, and conversations. For many years, we didn't think much about where the value resided, or whether we were owners of it. Similarly, we had a bit of a wake-up call. @marek is more thoughtful in that regard. We moved our conversations from Slack to Discourse. We haven't fully completed the transition, but we encourage more discussions to happen there. For some people, this is uncomfortable. We are breaking the fast-paced conversation cycle that companies have conditioned us to expect, but the slower pace and the ownership of data and community experience are priceless.

I see many open source projects betting on Discord, and I'd wager we're not far from witnessing an enshittification similar to what began with Slack. If I were to start a community again, I would absolutely build it on something like Discourse. Someone might argue that it's costly, but it really just requires getting a server, connecting to it via SSH, and running a command. Sure, it's not a one-click experience, but you're choosing between surrendering to corporate control versus nurturing a community who will appreciate—years from now—being able to search for something and find what they're looking for. If you care about your community's long-term health, you should care about owning the value that community produces.

We've applied this to other areas too. We're close to moving off Google Workspace. We self-host many of the services we use and keep the data in our own databases. It's amazing how many quality open source projects exist that we can contribute to. It's about long-term investment over short-term convenience as the product of an uncertain future you don't control. I don't regret for a moment the move we made, and we'll continue to invest in this direction.

If you're just getting started and don't have the resources, it might make sense to initially be a "product" (which usually means not paying), but eventually flip the switch and become the owner of your digital assets. You'll be thankful for having made such a move.

In the case of China, I think we are witnessing the reality behind the stereotype unfolding. They are proving to be amazing at localization. When one thinks about localization, it's tempting to think about languages. But localization goes beyond that. It involves understanding the culture that you are building for and adapting your solution to fit the expectations and needs of the target audience.

This takes a lot of empathy that I believe we are losing in what people usually refer to as "the West." Here it's all about you: your success, your entrepreneurship journey, your ability to raise capital, every quantifiable aspect of your life and business. So without empathy, the awareness of the importance of localization is lost.

China has that, perhaps due to their political system. And as open source has shown, which has a community component to it and therefore more empathy embedded in it, you can easily outcompete solutions that lack that, close their systems, and try to solve everything by throwing capital at the problem.

I wouldn't say Chinese copy. Chinese learn and adapt. We build models and impose them on everyone. If we look around, we see plenty of examples of this unfolding. From DeepSeek open-sourcing their models to, most recently, ByteDance open-sourcing a technology to build mobile apps, Lynx.

The last one is particularly worthy of analysis. Meta individualistically thought that it's not their concern to package a technology in a ready-to-use solution for the community, so ByteDance went ahead and bundled framework and technology and packaged it in a beautifully productized solution.

They understood that wealth is concentrating in "the West" and that people don't want to feel they are losing their purchasing power, so they adapted many of their products to make sure people continue to feel they can purchase the same or more than before.

The perception towards the Chinese and Chinese products is changing, and "the West," particularly North America, can do little about it. Or maybe they're localizing when it's too late, like Amazon presenting a Chinese-like storefront, Amazon Haul.

Years ago, the argument they still use to this day—that the Chinese are bad—is getting weaker and weaker, especially as we see Donald Trump's administration's real interests. It's two political regimes with different stories but similar goals.

So I dare to say the war with China has already started. The US is like Leonardo DiCaprio sinking in an ocean that the Chinese have become familiar with and have learned how to navigate better. They can try to tax the world, but that will only prompt the world to reconsider their dependency on their system.

For context, project generation continues to be the reason why many projects come to Tuist—most of which, surprisingly, are trying to find a developer experience that's better than SwiftPM's.

Once you reach the inflection point of having many people using the tool (therefore demanding energy from you) while you're treating it as a side gig, you have to consider doing something about it if you don't want to burn out. In many cases, developers don't do anything, and projects stagnate. Look around; I'm sure you'll find some examples. We were once suggested to move Tuist to a foundation, but foundations don't solve sustainability. So in our case, we decided to evolve Tuist into an open core business.

Transitions like this are not easy. You are going from open source and free to partially open source with some paid features. It's natural to think, "But you didn't tell me about this," but we didn't know either that Tuist would end up being largely adopted. So it's either we do something or let it die. I know it sounds harsh, but it's the truth.

The month that followed came with a lot of learning and questioning around what we'd like the company to be like. Open source is in our DNA, so as you can imagine, that influenced how we are shaping the company.

The first conclusion we reached is that we had to introduce solving problems that required a server to be solved. Capturing value through a server (in other words, asking people to pay for it) aligns better with people's mental models. It's still tricky to this date because, since people interface through the CLI, they find it rare that they have to have a paid subscription bound to the account they authenticated with through the CLI. Yet I believe this will shift as we continue to make Tuist server-centered. Solutions like cache, selective testing, previews, or analytics were born to solve server-solvable needs.

Our limited capital and the cost of getting a business off the ground led us to making the server closed source to avoid free-riding until we could better understand the market and how to monetize it. We did so contrary to our principle of keeping things open, and as you can imagine, the idea of making it open source again is something we've been pondering since.

When I tell this to developers and other business founders, they look at me and think, "Are you crazy? Opening the sources? You won't build a business like that." But after a lot of reading, discussing, and learning about the models of companies like GitLab or PostHog, I believe more than ever that this model is feasible. Let me unfold that for you.

But first things first: the motivations. We believe the best products are built by communities of people from all over the world. Despite your efforts of hiring diverse teams, you are limited to your team of 10, 20, or 100 people to build a product that addresses everyone's needs. Our work in the CLI taught us that. Once you experience it, you want to apply it everywhere. The human force you get access to through this model is unbeatable by throwing capital at the problem. Look at Wikipedia, Discourse, or Grafana. Elon Musk is annoyed by Wikipedia, but you can't compete with a group of people motivated by a common goal.

Second, it's important to understand one thing: businesses generate most of their revenue from large enterprises. I bet it follows the Pareto Principle, where 20% of your customers generate 80% of your revenue. So with that in mind, the question is how to have the server open source while still capturing the revenue from the 20% of customers. Well... this is what we are trying to understand. There are many good references out there, like GitLab, which charges for advanced features, or Penpot, which charges for control. Our hunch is that our model will be a mix of charging for advanced features or control and for hosting a complex infrastructure.

And here comes an interesting twist: what about the 80% of users? This is where traditional business people get uncomfortable. When you look at this from a monetary angle, they might feel like you are losing an opportunity to capture value there. But what if the value they contribute back is not monetary, but marketing and contributions to the product, helping make it better for everyone? When I first reached this idea by myself, it blew my mind. I could finally understand why something like Discourse or Grafana is so successful and why few to none can compete with them. Most of the people in that 80% group wouldn't have paid anyway.

Let's take all this framing further.

We are focusing on shifting value to the server, understanding the needs of the 20% of our customers, and building a mental model around where the line can be drawn. But not just that—in that future where Tuist becomes a community effort, we need to make ourselves as dispensable as we can be. In other words, can we shape a world where we can openly iterate on the product with a minimum cost for us? Definitely.

So we are focused on putting the right foundational pieces to ease contributions. If you look at our work in the past weeks, part of our focus has been on building a design system foundation for the CLI and for the web app, such that contributing to Tuist feels like LEGO. You've got an idea for a new dashboard feature to build? Sure! Go ahead, prototype something, and open a PR. Our designers will play more of a reviewer role than an active contribution one. And what's even better than all of this is that GitHub is doubling down on tools to leverage LLMs to review PRs. A few tests that we've done yield impressive results, so our coding will gear towards providing the right rules so agents can do a great job, and we are confident that the work does what it's supposed to do and aligns with the practices of the repo.

Besides what this means for the community, we'd build the first open source app developer productivity platform for app developers. Suddenly, it positions us with limited capital but with a world of contributions to expand Tuist in two directions:

• Into other app development lifecycle phases, for example, release automation. - Into other app development technologies, like React Native or Android.

In a traditional model, the above is done by raising endless capital, but that usually comes at the cost of potential misalignment of incentives and products "enshittifying" themselves. We don't want that for Tuist. Hence, we are embracing a model that allows us to create an innovative development environment where the community is an intrinsic part of it, with a world of opportunities to help teams build better apps.

I'm damn excited about this model!.

Whenever I create a new package, I create two Mise tasks, mise/tasks/build.sh and mise/tasks/test.sh. Then using usage annotations in the scripts, I can easily add support for using --linux to indicate a different target OS:

#!/usr/bin/env bash
#MISE description="Build the project"
#USAGE flag "-l --linux"

set -eo pipefail

if [ "$usage_linux" = "true" ]; then
if command -v podman &> /dev/null; then
CONTAINER_ENGINE="podman"
else
CONTAINER_ENGINE="docker"
fi

$CONTAINER_ENGINE run --rm \
--volume "$MISE_PROJECT_ROOT:/package" \
--workdir "/package" \
swiftlang/swift:nightly-6.0-focal \
/bin/bash -c \
"swift build --build-path ./.build/linux"
else
swift build --configuration release
fi

And that's it. You can now do:

mise run build # Build in the host (macOS)
mise run build --linux # Build in Linux

As you might know, solutions start with understanding. Without it, solutions are chosen blindly and based on assumptions.

The organizations that can afford it throw more engineering resources at the problem, hoping everyone will become more motivated and productive. Others might suggest, "Let's adopt React Native because I've seen company X successfully implementing it." Or one engineer might propose swapping the build system completely with something like Bazel.

But the data is there. It's just not pleasant to obtain and work with.

Want to know more about .xcactivitylog and the .xcresult schema? Search for it on your preferred search engine. You'll most likely end up finding some parser on GitHub. The community has to reverse-engineer these formats, just as we did with the .pbxproj format to build XcodeProj.

There's an unfounded obsession with keeping everything close to Xcode, as if development didn't extend beyond your local macOS machine and your Xcode.app instance. Look at Xcode Cloud—it's built right into Xcode. Beautiful. But the capabilities of CI services haven't fundamentally changed. We're just doing the same things, or even worse, but now it's official and native.

It feels as if we're stuck on this idea of "it's native" while watching our builds take an insane amount of time, or our flaky tests blocking people without really knowing how serious the problem is.

So Tuist is jumping in because no one else is:

1. We're collecting the data for you 2. We're making it accessible 3. We're helping you act on it 4. And potentially, we'll be the ones acting on it (e.g., auto-disabling flaky tests)

For the first point, we're learning about those proprietary formats to collect and push them to a server. Yes! A server. We love native apps too, and we'll build a native interface to the Tuist platform, but that should be an interface, not the core. A server also means a database, so you can understand how the data evolves over time, and the possibility to interact with other services, integrating with things that happen outside of developers' environments and Xcode. We can't disregard that there's a lot happening out there, because otherwise we end up with a developer experience that's lagging behind in a world where LLM is challenging how we code.

We're standardizing, documenting, presenting, and making the data available to you via an API. Your project, your data.

It's that simple.

We're just a group of developers passionate about this domain. It's not our aim to monetize your data. Our business is helping you solve your problems. Period.

With all our learnings from past years and current interactions with customers, we'll codify that knowledge into a dashboard and a set of tools to make development enjoyable.

I don't understand why this hasn't happened before, but on the upside, it's a great opportunity for us to build something different—something focused on developer experience.

The data is there. We're just going to use it.

I later learned that it was just a marketing term, and a vendor-locking tool to prevent customers from switching to other tools in a market where there are already many options available. The same model is repeating across other CI companies that are rushing to build more than just CI. For example, have you noticed that they all rushed to present an App Center alternative?

Many tech companies, including those in the CI space, typically follow this pattern. They run the infinite game of venture capita. They follow the loss-leading script, first bringing and vendor-locking customers into a reasonably-priced solution, and then squeezing as much money as possible from them. Product and innovation become secondary as they focus on the value-cost trade-off.

As someone who likes to see new ideas flourishing and long-standing challenges addressed, I find it sad.

But software and communities that might form around them can be catalysts for change, and I believe we are entering a bit of a wake-up call in this space. Let me unfold that for you.

GitHub Actions started changing the game. First, they built a solution where developers could build and share steps (i.e., GitHub Actions) with others. Sure, platforms other platforms have it too. But think about it for a second. Would you rather have an action in a repository that's part of your CV on GitHub, or commit it to a centralized repository that's more distant from your GitHub profile? It's a subtle but important difference.

They then integrated the UI (e.g., logs) very tightly into the platform. You don't need to leave the platform to see the execution and results of your CI builds. It's right there, in the same place where your code is. And because it's so close, annotating PRs from your builds is as easy as following some conventions in your logs (e.g., workflow commands).

And last but not least, they embraced the freedom to bring your own hosts. This not only became freedom for companies and developers to customize their solution but for companies like CirrusLabs or Depot to provide hosted runners.

So if your Git forge, most likely GitHub and GitLab, already provides a much better CI experience than other players, gives you access to a marketplace of steps (which, by the way, Dagger is commoditizing and making CI-platform-agnostic), and many companies are emerging to provide hosted runners, what are you left with as a CI company?

I'll tell you... You need to share the illusion that you provide more than what you really do, and hope that the years of investing in vendor-locking will prevent companies from leaving you. Ehem, Mobile DevOps. But this model is falling apart. It's a matter of time. And we'll see more companies iterating on the idea that they are a CI company. Give it some time...

How are we doing things differently at Tuist? First, we are designing a company that fosters innovation over seeking value-cost tradeoffs. Innovation is in our DNA. And yes, this will mean we'll make bets that won't bring any return, but that's fine. We want to bring some innovation to the CI space, and you'll see that in the following months.

Second, we are embracing people's freedom to choose. We are not about capturing as much as we can from the value that we generate. It's about generating way more value than traditional businesses. And we are going to do that through open source, so we expect to open-source our server and everything that makes Tuist possible. We'll charge for maintaining the services up and running, and the community will be able to contribute to the project, from the CLI to the server. This will make Tuist stand out over competitors that look at openness with fear. We believe this is also the path to get to Android, React Native, and Flutter.

And last but not least, we are placing a strong bet on making everything collaborative. From the moment we have an idea for something we'd like to build, it becomes a shaping process where the community participates. We want people to feel that Tuist is as much theirs as it is ours.

In the following months, we'll see a lot of changes, not just in the CI space, but in app developer tooling, and we are going to drive the change at Tuist.

I’ve spent all this time visiting countless specialists, many of whom were in Germany. I’d like to believe I was just unlucky, but truthfully, I felt abandoned. From MRIs that never happened because they were deemed "unjustified" to doctors telling my wife to take care of me so that I could lose weight and strengthen the muscles that might compensate for my torn ligaments.

“Natur macht besser,” a neurosurgeon said, suggesting I let a nerve—which hasn’t shown any signs of recovery—heal on its own.

Another doctor seemed more surprised by the fact that I had painted nails rather than my wife. And let’s not even talk about the dismissive comments:

• “Forget about running again—only in the swimming pool.” - The casual bro-like chitchat about a German footballer who played most of his career without ligaments.

I would have appreciated a simple, honest response like:

“This is urgent, but I don’t have the resources, experience, or willingness to try a solution.”

That would have been completely fine. No one is an expert in everything.

But was it racism? I doubt it. I’d say it’s more about being on the conservative side of the medical spectrum, leading to a loss of surgical expertise. There was also a bit of the classic “I’ve never seen this before” mental short circuit. So what? The human body is complex. Interestingly, the people that couldn't admit they didn't know about something were male doctors.

And then there’s the specialization issue—“I do muscles,” “I do bones.” Welcome to the inefficiencies of the system. As if dealing with the pain and the looming possibility of a nerve that won’t recover wasn’t enough, I also had to coordinate everything myself.

I’d be lying if I said this whole experience hasn’t made me question what I’m doing in Germany. Sure, I had noticed bureaucratic inefficiencies before, but when it comes to health, the stakes are much higher. My taxes feel worthless—at least on the healthcare front.

Here in Spain, everything feels so much easier. Yes, it helps that I’m a native speaker, but more than that, they guide you through the system until they find a solution. They take responsibility for coordinating your care. I’m going through the private system here—since it was the only way to find a specialist capable of handling my case—but the public system works the same way.

People actually want to help. They generally understand what you’re going through and do their best to make the process more bearable. This is how I always imagined healthcare should be, but Germany’s system failed me.

Wish me luck. I’ll be fasting for the next six hours, and if everything goes well, I’ll update you tomorrow.

Take care of yourselves.

We’re still stuck with the same CI providers we used years ago, dealing with YAML pipelines that are a nightmare to debug, and locked into vendor ecosystems that make it hard to escape predatory sales practices. And what about all those old Ruby scripts no one dares to touch? “They work, so just leave them,” people say. Remote automation and CI are strongly coupled: you automate, push, and check if it works. Want something more intuitive, like a simple “click to release” feature? Not happening. Instead, you build in your CI environment and push the artifacts elsewhere. Need better insights into your projects? Here’s a scattered set of libraries to glue together, a server to maintain, or a build system to replace. Or even worse—an app that locks the data away, when all your manager really wants is a simple link to track team progress.

It’s too much plumbing. It’s not fun. And while Apple has made some progress here and there, they’re largely preoccupied with business priorities.

Ironically, the companies best positioned to enter uncontested markets—thanks to their IP and financial capital—are the ones suffering from the innovator’s dilemma. They’re too distracted trying to fit their products into the AI narrative. But real innovation starts by looking at problems from a fresh perspective, challenging the status quo, and reimagining what already exists.

At Tuist, we want to be a catalyst for innovation. Our approach? Commoditizing a foundational piece we believe will unlock new ideas: remote virtualization of development environments.

I know, that sounds abstract. But think about Linux containers or web browsers. You can launch software in a browser using WebAssembly or in a Linux machine with Docker. But macOS? Forget about it. We've wasted years reinventing virtualization—something every CI provider has had to solve. Yet, most see virtualization as just an enabler for CI services, rather than a tool to build new developer experiences.

Now, imagine if the cost of running virtualized environments dropped significantly, thanks to open-source technology and a simple system for orchestrating a pool of hardware. This isn’t a new concept—cloud providers already solved it for running apps and serverless functions. But no one has applied it to improving developer experiences.

Just yesterday, Vercel introduced a new runtime called Fluid. Fluid is how things should be: spinning up virtualized macOS environments seamlessly.

And then, the magic happens:

• You can release an app with a single click from the list of commits on your Tuist dashboard. - You can run any workflow locally or remotely with just a flag. - You can sign your app remotely, letting us handle all the complexities for you.

We’re assembling the pieces to make this future a reality. I can’t wait to see Tuist help the Apple ecosystem catch up with the web. We’re making Tuist the go-to CLI for teams, building the best, most powerful, and beautifully designed dashboard that people love using. We chose Elixir for its robust runtime, which will be crucial in simplifying our solution without compromising power. And we’re developing a few missing technologies, which we’ll also open source.

We’re almost there. We just need to rethink the problem and bring down some costs to make it happen. Will it be expensive to develop? Oh yeah—especially for a small company like us. But once we release it, I bet Tuist will dominate these new spaces.

At Tuist, we believe that the best way to build a productivity platform is through openness. Openness fosters accountability, which keeps us aligned with our mission and pushes us to deliver our best work because everything we do is out in the open. However, openness also presents a challenge: where do we create business value, and how do we monetize it to ensure we can continue doing what we love?

Years ago, Tuist’s value was primarily in its project generation feature, which we now consider a commodity—a gift to the community. Building on that foundation, we introduced optimizations like selective testing and binary caching, which span both the client and server. This marked an inflection point for the business, as server-side value opened up new revenue opportunities. We’ve discussed eventually open-sourcing the server as well, but in its current state—where hosting is simple by design (a necessity given our small team)—organizations might choose to self-host without seeing the value in supporting us financially.

There are interesting models to consider, such as the Fair Source Licenses, but this would distance us from a pure open-source model. Another option is dual licensing, like GitLab, where a community edition is extended with paid features. However, I have mixed feelings about this approach because it adds complexity to a product that’s already pioneering a new model in the ecosystem. For instance, Tuist started as a CLI tool, but now there’s a community server and potentially an enterprise server? It feels like too much.

My hope is that, eventually, the value will lie in hosting, maintaining, and scaling the business. At that point, we could even adopt a free software license for the server. Large enterprises often perceive self-hosting as a risk or too complex, making them more inclined to pay for a managed solution. For smaller companies and indie developers, we could offer the service for free up to a certain usage threshold and charge only when usage exceeds that limit. There will always be a group of users who prefer to self-host, and that’s fine—they contribute to improving the product and even help with marketing.

xWiki took the path of monetizing through support, but we are a product-oriented company. Our goal is to find a balanced SaaS solution that maximizes openness while ensuring sustainability. The exact model will evolve as we learn and adapt to shifting value propositions. What’s clear to us is that we want to continue contributing open-source tools to the ecosystem while presenting an alternative model for building sustainable open-source businesses.

• Tuist is not just a project generator. Project generation is one of the solutions that we offer along many others. We see project generation as a component–a commodity that we might extract from Tuist once we have the resources to execute on it. - The CLI is becoming more of a frontend to a development platform, but it’ll not be the only one. There’s a web-based dashboard and a macOS app, and thanks to our documented REST API other frontends might emerge. - We are removing the dependency on generated projects to benefit from the Tuist solutions. Our long-term goal is that you can plug Tuist into your Xcode projects or Swift packages as they are. - Our focus continues to be on development productivity, although there are early thoughts about supporting teams more directly with the quality of the apps that they build. We are also expanding our focus to support developers from the moment they have an idea, until they publish it on the store. - We started with a strong focus on the Apple ecosystem, but the problems that we solve span other ecosystems, so we might expand onto Android, React Native, and Flutter in the near future. - There continues to be an appetite to make the server code source available. We might execute on it if the business thrives. We believe this model will lead to shaping the best and more diverse solution in the space.

Tuist will look more like Vercel or Expo. Because developers will expend a lot of time in the dashboard understanding, interacting, and optimizing their development, we deem crucial to provide them with the best experience there. Therefore we are designing a beautiful design system, Noora, that all the features will build upon. We want to build the best DX and most beautiful developer tool for all developers, while building a company around it that embraces innovation and openness in ways that we haven’t seen before in the ecosystem.

The most obvious example of this, which I'm extremely annoyed by, is the dopamine addiction that social networks have created. It's a silent pandemic. When are we going to stop that? Another one is the ad industry. I was watching yesterday a movie in one of those streaming platforms, where I have a subscription, and despite paying for it, I was bombarded with ads. Then there's this whole AI hype. I get it, LLMs are useful for summarizing, but the environmental cost for society is something we can't ignore. Or most recently, local apps, like note-taking tools, that suddenly become subscription-based, or use proprietary formats to lock you in.

It doesn't need to be like that, but those patterns are becoming more common. I strongly believe we can reverse that trend. For a long time I thought open-source was the answer, but after seeing what Wordpress is turning into, I'm not so sure anymore. Governance and openness are two different things. I use Obsidian to write my notes, which is a closed-source tool. I get why they develop it that way (learned through Tuist). If you make a pure client-side tool open source there's no way you can monetize it to make its development financially sustainable. But what I like about them is that by design and embracement of standards, they give you the freedom to leave. And that's the thing, you can really build a business around a technology, and respect the people's freedom and rights at the same time.

So, whom do you trust? It's hard to say. It's not an easy question because you don't have all the information. But before betting on a particular technology, I do a bit of research to understand the design principles (e.g. standards over proprietary technology), their openness, their governance model and funding structure (this is the most difficult to find). And then based on that I make a decision. I sometimes wish governments did that for you. I can do that because I have the priviledge to have learned about these things due to my close relationship with the tech industry. But if you don't, you should know you might end up mentally sick if you use Instagram and TikTok without limits, in the same one you are reminded that alcohol and tobacco are harmful. But as I said earlier, if anything, with Trump's presidency, this is becoming even more unregeulated.

I'll do what I can in my circles and with Marek through our work on Tuist. We don't need to be like everyone else and jump on the bandwagon. We can build human and long-lasting technology, and not put people in the position of exploitation.

mise run reproduce

Yesterday, while tinkering with some Mise features, I realized Mise has the ingredients to make this possible:

• The capability to install and activate specific versions of dev tools. - An API to define and run tasks.

Let's see how we can leverage Mise to create a convention for frictionless reproduction projects.

Creating a reproduction project

1. Create a new directory: mkdir project. 2. Create a .mise.toml file with the following content:

[tools]
# Add your tools here

[hooks]
enter = "mise install"

3. Create a .mise/tasks/reproduce.sh file with the reproduction steps:

#!/usr/bin/env bash
# mise description = "Reproduce the project"

# Mise tasks: https://mise.jdx.dev/tasks/file-tasks.html
# Note the root directory is denoted by the env. variable $MISE_PROJECT_ROOT
# Your reproduction steps go here

And that's all you need to create a reproduction project with Mise. The maintainer can pull the tar file, extract it, and run mise run reproduce to reproduce the issue.

A ready-to-use gist

I've created a gist with a script that automates the steps above. You can easily run it with the following command:

curl https://gist.githubusercontent.com/pepicrft/12a2fc6433338489888d660d66d8d0b1/raw/907f33c43287c19162c79b2426015c516d4c3cd7/reproduce.sh | sh

It wasn’t always like this. I used to be quite positive and enthusiastic—a friend to friends, supportive in my interactions, and always leaning toward collaboration and doing things together. I don’t think that part of me is gone; it’s just overshadowed by these other behaviors and more primitive feelings.

It’s hard to pinpoint where this shift began. I believe social networks’ optimization for extracting these behaviors from people might have played a role. My previous working environment, which was filled with certain toxic patterns, also influenced me because I didn’t know how to set boundaries at the time. Then, of course, there was the pandemic, which isolated all of us, and let’s not forget the many winters in Berlin—those probably didn’t help either.

But here’s the thing: I believe this is something I can change, and I’ll start by leaning into positivity and constructivism. Sure, the world isn’t perfect, and there are things we’d rather not think about, but if we all collaborate more and push back against the individualism that’s been ingrained in us, I think beautiful things can happen. I want to be a catalyst for that change.

Bear with me—it’ll take time—but I really want to do this because it’ll improve my overall well-being. Being a grumpy person on the Internet hurts me deeply in my personal life, and I don’t want that anymore.

Tuist has gone through three major phases:

1. Xcode Project Generator: What we now call Tuist Projects. 2. Xcode Project Manager: Introducing CLI commands like tuist run and tuist graph. 3. Xcode Project Optimizer: Featuring tools such as Tuist Cache and Tuist Selective Testing.

Now, we are entering a new phase. Tuist is becoming a platform—a cohesive story that ties all the pieces together. Imagine a Vercel or Expo for Swift app development. A platform that guides you from the spark of an idea to scaling your app for millions of users. A trusted partner empowering you to build the best apps faster.

We aim to streamline the toolchain by peeling back years of accumulated layers of indirection. Our ultimate vision reduces the stack to just GitHub (or any Git forge), Tuist, and Xcode. Tuist will act as a platform integrated into your repository, making the magic happen. And by magic, we mean pure joy:

• Signing? We handle it seamlessly—it just works. - Remote builds? Done in our environments, hassle-free. - Analytics? Integrated with ease. Grafana? Plug it in. - Releases? Managed through a user-friendly UI.

Think of Tuist as an extension of Xcode that bridges the gaps and connects the community with Apple’s ecosystem. Together, we’re building the future of app development.

Logging is useful to debug the execution of the program, especially in situations where an invocation didn’t yield the expected result. Although often those logs are forwarded through the standard pipelines, they don’t need to be. They can be forwarded to OSLog or to a file in the file system. Apple’s Swift Log package is designed with this in mind and allows setting up what they call logging backends or handlers.

At Tuist, we dynamically plug one backend at runtime based on the user preferences at invocation time. The preferences are modeled based on two variables: how quiet or verbose they want logs to be, and where they want things to be logged.

This leads to the following scenario. The default logging configuration pipes out logs (except the verbose ones) through the standard pipelines, so developers have a sense of progress without too much noise. The problem? If things fail, developers need to run the command again, opting into verbosity with --verbose. But what if the issue is not easily reproducible, and that was the only opportunity to capture what happened? Well, the opportunity is gone. Plus, having to run the same command again just to see it fail with more detailed logs is not the best experience.

I think we should approach this differently. The default is right. You want to see a concise output that indicates how things are progressing throughout the execution. However, we should also have a second handler/backend that forwards the most verbose version of the logs to oslog and to a file in the file system. Why? Because on completion, you can point people to the logs, and they can use filtering tools provided by the Console app to get what they need. By doing that, once it completes, if you need the logs for anything—for example, to debug a failure—you have the link to the file right there, so you don’t need to run it again.

Is that enough? I don’t think so. I started the blog post mentioning that we conflate logging and UI, but that they should be different things. When I think of logs, I think of traces that tell a story of how things are being executed. But where does an interactive prompt fit into it? It’s not a trace. You use the terminal capabilities with cursors to make it feel interactive, but from the logging perspective, you are only interested in two things: something is being prompted, and the user responded to the prompt. So in non-interactive CLIs, you might just merge UI into logging, but in more interactive CLIs like Tuist’s, I think it’s better to treat it as something independent.

UIs are for developers using the tool. Logs are usually for developers debugging the tool. The needs are different. When you design the text to be an output for the user, there are traits like formatting and spacing that are very important. These traits are not relevant in the context of logs. All you care about in logs is understanding the sequence of events. Therefore, separating the two things forces you to think more deeply about the presentation layer of your CLI. I like to say that text output is the UI layer of CLIs—SwiftUI, if you will. The UI is something you might also be interested in testing with snapshot testing techniques, in the same way you do with your SwiftUI views. It’s tightly connected to the DX, and you don’t want it to be an afterthought.

So at Tuist, we are correcting the course. We are drawing a line between logging and UI, plugging our verbose logs to oslog, and revisiting the UI of every component to ensure the experience of each command from the UI standpoint is the most consistent and beautiful that we can ship.

Social networks have made us more individualistic. Much of the content shared online revolves around “me”: the lessons I’ve learned, the products I’ve built, the places I’ve traveled to... It’s as if these platforms have hit the narcissism button, and we’ve forgotten the value of collaboration. Interestingly, research shows that collaboration leads to better outcomes. However, when the primary goal is to feed an algorithm designed to capture attention, collaboration might feel like a wasted effort.

Unfortunately, this pattern is also apparent in how many tech companies operate today. Months are spent working behind closed doors on what could be the next big success, only to emerge and hope for “product-market fit” to materialize. It’s like throwing a dart and hoping it sticks. They buy expensive domains, design flashy websites, hire influencers to promote their product, and hope that self-promotion will eventually lead to success. Even small wins are often packaged into narratives to attract more capital—much like how chickens are overfed to grow rapidly. The result is either building a big business or failing fast.

What surprises me is how secondary the actual problem—and the people experiencing it—has become in this equation. Many companies are busy building “serverless X” without truly addressing what it means or whom it serves. It’s reminiscent of the clickbait culture on YouTube, where influencers use catchy thumbnails and titles to reel you in. Companies employ similar tactics: “Pay for what you use.” Sounds appealing, doesn’t it? Yet, you might end up paying more without even realizing it. This lack of ethics is becoming normalized—anything goes as long as it stays within legal boundaries.

Building a different kind of company requires only a small yet significant shift: focusing on people instead of the company itself. But this isn’t an easy shift. It demands overcoming ego and suppressing narcissistic impulses. It requires listening, becoming a platform for others, and enabling their success. It’s costly because it introduces a social component to the business, which might feel unfamiliar to more logical thinkers. Yet, the value it brings far outweighs the costs.

When I think of one of Tuist’s key strengths, it’s our strong focus on people. These values stem from our open-source roots and permeate how we shape the business. Every decision we make prioritizes what the community wants, rather than what we want to sell. For example, in 2025, we’re launching a newsletter, Swift Stories, to curate ideas from the community that might otherwise go unnoticed. We open-source components like XcodeGraph and XcodeProj to empower the community and foster innovation, rather than keeping them private as competitive advantages. Another example is our localization efforts—seemingly small initiatives that make our project more inclusive and accessible, but carry significant meaning.

When you focus on people, remarkable things happen—things that aren’t often talked about.

1. You don’t have to search for “product-market fit.” By creating a safe space, people naturally share what they need and what they’d pay for. 2. Customers gravitate toward you because they’re inspired by your values and prefer supporting you over competitors.

Every customer we’ve gained so far has come from our community. Some have even told us they’d prefer a CI service from us over others simply because of our approach. This shift in focus has a profound impact. For example, our most recent blog post from Trendyol happened without us prompting them. When things occur organically, they carry a unique energy that money can’t replicate.

If you’re building a company, I encourage you to put people first. It’s challenging and may feel like swimming against the current, but believe me—people value connection and collaboration. They’ll appreciate your authenticity and the unique way you do things.

Open-source is better than closed-source software. We've learned that story throughout the history of software. Yet, we get irritated when open-source mentions the word "sustainability". Let's pause for a moment.

If a software is closed-source, which comes with high risks for the person or company using it, they are comfortable not only with the idea of paying for it but also with being a product of the company. But if the software is open-source, which significantly reduces the risks of using it, people are rarely comfortable with the idea of paying for it.

The paradox of OSS

Let's break down this paradox in the context of developer tools.

You are willing to pay for a service to bring CI/CD to your project. You come across a closed-source service that everyone talks about. They don't list the price on their website, and after some back and forth with the sales team, you end up paying an expensive subscription. Your product leans on proprietary design decisions because you are a product of the company.

Your entire company has migrated to this service, and two years down the line—in the spirit of meeting their VCs' expectations and knowing that moving away would be extremely difficult—they multiply the price by 10.

Back then, you had the alternative of paying for the cloud service of an open-source project. They offered a cloud plan to sustain the development of the project. But you could not wrap your head around the idea of paying for something whose source code is available. Not many people were talking about it at the time, so it felt more natural to pay for that flashy closed-source service that could afford to pour millions into marketing and associating their brand with the open-source community.

Now you find yourself having to decide between paying 10 times more for the same service or stopping business development for months to migrate to a service you could have paid for initially.

Supporting OSS Sustainability

If you come across an open-source project figuring out sustainability, offer them a hand. Sustainability can take many shapes:

1. It can be an AGPL-3.0 license with a dual-license for enterprise. And despite what you've heard, AGPL-3.0 is not a viral license. Businesses want you to believe that, but a license only enters into effect when you distribute the software, which is not the case when you use it internally. In case of doubt about what "distribution" means in this context, the developers behind the project are usually happy to clarify. 2. Sustainability can also mean building cloud services, like we are doing with Tuist. If we were privileged enough to have the time to build open-source without worrying about money, we'd happily do it, but unfortunately, that's not the case.

We need to draw a line between what's free and what's paid. We do this for three simple reasons:

1. We want the project to thrive and continue supporting users. 2. We want to do more open-source work to advance the Swift ecosystem. 3. We want to move the ecosystem away from closed-source tools.

Making informed decisions When choosing a tool, consider the following:

1. Open-source, even if not fully, is better than closed-source. You eliminate risks for your business. 2. If you can afford it, pay for the open-source tools you use. It's a way to support the developers, the ecosystem, and even your brand. 3. If you can't afford it, contribute to the project in other ways. Report bugs, write documentation, or spread the word about it.

We are not privileged to have the time to build open-source without worrying about money. But we hope to reach a point where we don't have to think about finances, so we can gift more open-source tools to the Swift ecosystem and foster innovation through the commoditization of the tools we use to build software.

I emphasized "solely" because some businesses provide value beyond their software, either through infrastructure or connections to external systems that are difficult to replicate. For example, an open-source e-commerce platform that competes with Shopify can be built. In fact, it exists. But what about card readers? Payment processing? Taxes?

On the other hand, Calendly? Done. DocuSign? Done too. GitHub? Absolutely—here’s one example, and another. Even CI, telemetry, and analytics have open-source counterparts.

What do all these successful open-source products have in common? Something money can’t easily buy: stronger communities and better products. When you embrace open collaboration and welcome ideas from diverse perspectives, your product becomes more inclusive and innovative.

The alternative? Designing what you think is the best product from a conference room in San Francisco, assuming it solves problems for people in South Korea. Spoiler alert: it probably doesn’t.

And here’s the best part: AI is reducing the cost of maintaining open-source software, a cost that has traditionally been higher than developing behind closed doors.

At Tuist, we want to set a precedent in the Apple developer tooling space. Too often, closed-source and proprietary solutions emerge, plastering "contact sales" buttons on their websites and finding shady ways to lock developers into their ecosystems. But it doesn’t have to be this way.

We’re committed to building open solutions for scaling challenges and making them accessible to everyone. We’ll continue to commoditize tools—not just for accessibility but to push the ecosystem to innovate. Because we believe the time for closed-source developer tools is over.

When I was younger, I was very passionate about, and sometimes even religious about Swift. You know when you try to take the language everywhere, that was me. However, as I've grown older, and got to work in other technology stacks, I've realized that Swift is just a tool. I worked with Ruby building CLIs, then I built CLIs with JavaScript and NodeJS, and tinkered with web technologies like Ruby on Rails in between.

This distancing of Swift felt at times like a betrayal and a lose of identity, and other times like a liberation. My wife loves to say that learning spoken languages opens your mind, and I think it applies to programming languages as well. I have my opinions and preferences, and love to learn from the communities around them, but I'm not married to any of them. I'm seeing them as tools to solve problems.

The mistake that I sometimes make, that's mentioned in the blog post, and that I should work hard on stop doing, is comparing and commeting on how one programming language is better than the other. It's just a subjective opinion, and it's not helpin anyone. All programming languages have their pros and cons, and are surrounded by social and technical contexts that make them unique.

The world is better of if we all work on making our tools better, and cross-pollinate ideas between communities. So I'll stop comparing and commenting on how one programming language is better than the other. If I love something about Elixir, I'll say it out loud, because I think it's important to share the joy, but I won't do so in the expense of another language.

But when growth becomes the ultimate goal, the people you’re building for often become an afterthought. Instead of creating for them, you use them as tools to achieve growth. This dehumanizes them, leading to strategies that often feel exploitative.

For example, some businesses publicly criticize others’ work to exploit “schadenfreude.” They actively look for people making mistakes to capitalize on the audience’s curiosity for negativity—using it as a marketing tool. How crazy is that? Sure, anything is possible in business, but come on—it’s perfectly fine to grow more slowly if it means contributing to a better, healthier society instead of making it worse.

Another practice I find exploitative is what I call “open-washing.” Some companies, desperate for shortcuts to growth, think they can buy everything with money—including the intangible assets of open-source projects, such as their brands and communities. They treat these assets as mere marketing tools. They throw a few crumbs in the form of donations or sponsorships and then loudly claim to be "an open-source company." It’s not much different from brands sending cheap promotional items to influencers, hoping for exposure. This is capital-rich companies taking advantage of the human-centered work of others who truly know how to build and nurture communities.

This insatiable appetite for growth shows up in many areas—not just marketing. Products are riddled with “contact sales” buttons, proprietary technologies designed to create vendor lock-in, and intentionally opaque pricing models that exploit customers’ negotiation skills. The list goes on. Sadly, when you search for companies that define success differently, the options are few and far between. These companies exist, but they’re rare.

We could follow these same exploitative paths ourselves, but we refuse to fuel those strategies. In fact, we’re actively working to reverse these models. We believe we need healthier, more human ecosystems—where individualism gives way to community, proprietary technology is replaced by open solutions, and people’s agency to choose the best tools for their needs is respected rather than manipulated.

This shift is only possible if we prioritize people’s joy over growth—and that’s exactly what we’re doing at Tuist.

The first thing that you'll need is a Hetzner server. It can be a server from any other provider, which provides you with a Linux machine and SSH access to it. In my case I selected the x86 (Intel/AMD) CX22 machine in Germany with Ubuntu 24.04. Note that the steps that follow assume Ubuntu as the operating system.

Once the machine is up and running, SSH into it using its IP address and the root user. Once in, install Docker, which Forgejo runner can use to virtualize the execution of CI/CD pipelines:

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
 "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
 $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

You can verify that Docker is installed correctly by running:

sudo docker run hello-world

Then run the following command to ensure the engine starts on boot:

systemctl enable docker

Install the Forgejo runner

The next step is installing the Forgejo runner.

sudo apt-get install -y curl jq wget
RUNNER_VERSION=$(curl -s https://code.forgejo.org/api/v1/repos/forgejo/runner/releases/latest | jq -r '.tag_name' | cut -c 2-)
wget -O /usr/local/bin/forgejo-runner "https://code.forgejo.org/forgejo/runner/releases/download/v$RUNNER_VERSION/forgejo-runner-$RUNNER_VERSION-linux-amd64"
chmod +x /usr/local/bin/forgejo-runner

Once the runner is installed, you'll have to register it. To do so, you'll need a registration token, which you can get from your user or organization's settings on Codeberg under the "Actions" tab. Then you can run /usr/local/bin/forgejo-runner register, which will guide you through the registration process.

INFO Enter the Forgejo instance URL (for example, https://next.forgejo.org/):
https://codeberg.org
INFO Enter the runner token:
xxxxxxxxxx
INFO Enter the runner name (if set empty, use hostname: ci):
ci
INFO Enter the runner labels, leave blank to use the default labels (comma-separated, for example, ubuntu-20.04:docker://node:20-bookworm,ubuntu-18.04:docker://node:20-bookworm):
ubuntu-22.04:docker://node:20-bullseye
INFO Registering runner, name=ci, instance=https://codeberg.org, labels=[docker:docker://ubuntu:22.04].
DEBU Successfully pinged the Forgejo instance server
INFO Runner registered successfully.

The registration will create a .runner file in the current working directory, which if you haven't changed it, will be /root. The file will contain the runner's integration configuration.

You can then run the following command to create a configuration file to configure the runner's runtime behavior:

/usr/local/bin/forgejo-runner generate-config > config.yml

You might want to modify the runner.capacity attribute from the configuration file to specify the maximum number of jobs the runner can handle concurrently.

The last step is to configure the runner as a systemd service, which allows it to start automatically when the machine boots up. You'll have to create the following file at /etc/systemd/system/forgejo-runner.service:

[Unit]
Description=Forgejo Runner
After=network.target

[Service]
WorkingDirectory=/root
ExecStart=/usr/local/bin/forgejo-runner daemon --config /root/config.yml
Restart=always

[Install]
WantedBy=multi-user.target

Once the file is created, you can enable and start the service by running:

systemctl daemon-reload
systemctl enable forgejo-runner
systemctl start forgejo-runner

After completing all the above steps, you should see the runner showing up in the "Runners" tab of your Codeberg organization or user's "Actions" settings.

Solomon Hykes, the founder of Docker and now Dagger, shares our love for building developer products. Both Docker and Dagger are open-source businesses, meaning their core revolves around open source, community, and open discussions—even when those discussions lean more toward the business side of things. I believe this is how the best and most enduring companies are built. However, as he points out, achieving this is not easy. Why is that?

He differentiates between products and components. Components are open-source, standardized pieces that become industry commodities. They often evolve from a product once they’ve matured. It makes sense for such components to belong to a foundation once they’ve reached critical mass. Examples of components include Kubernetes and containerd. Typically, their licenses and trademarks, which are usually managed by foundations, are permissive. This allows businesses to use them as enablers or even integrate them as part of their offerings.

However, Dagger and Docker are not components—they are products. What’s the distinction? Products are fully integrated developer experiences that deliver value, often have ecosystems around them, and monetize certain features to fund further development. This funding often extends to investments in components. Solomon emphasizes this distinction as critical for building great developer tools, and we agree.

Some organizations may dislike this approach because it prevents them from leveraging communities and streams of capital to outcompete you and extract value from the community. They often argue, “You’re not open enough,” as Bitrise did when they suggested that Tuist should be part of the Mobile Native Foundation. It was amusing to see them use the same tactics that cloud providers once used against Docker. We don’t have anything against the foundation; in fact, we’re considering extracting Tuist’s generation logic into a component. However, Tuist itself is not a commodity—it’s a product, most of which is open source. This distinction is subtle but important.

Since Tuist is a product, it has features like the login command to authenticate with Tuist itself, the vendor behind the product. We see being a product as a critical distinction with significant implications. For example, it’s the reason we’re gradually transforming Tuist into an integrated extension of Apple’s tooling. This evolution wouldn’t have been possible if Tuist were a commodity, which would have led to stagnation. Simply put, we don’t want Tuist to stagnate.

We expect some organizations to dislike this model, and that’s fine. But there are many others who understand the need for this approach—especially from a financial perspective—and are eager to participate in shaping Tuist and its community. Like Docker in its early days, this is where our focus should be. Only by focusing here can we create a truly great product.

I always conceived of technology as an extension of our lives to make certain things more convenient. For a long time, I assumed good intentions from the makers of those technologies, from the executives of Facebook to those from Apple. Isn't it amazing to have the tools to be connected to so many people? Or hardware like iPhones that lower the entry barrier to technology? "We aim to make the world a better place." I also bought into this story when I joined Shopify and stayed there for many years. Their version of making the world a better place was making e-commerce better for everyone. I'd call my 20s a phase of illusion with technology. How naive I was...

Fast forward to today, what I feel is a lot of disappointment with the tech industry. Seeing the leaders whom I long respected celebrating Trump becoming the winner makes me sad. Years ago, they didn't dare to talk about such things publicly. But we've normalized a reality where they feel comfortable doing so. It's all about money, and which millionaire isn't happy with their taxes being cut? And the worst part is, many of us are so exhausted, confused, and driven by primitive emotions whose buttons were pressed by these same people, that we are unable to think clearly. This is not the tech industry I want to be part of. But whom do I trust?

If anything, I think this whole experience has taught me whom to trust and why. First and foremost, I trust the tools that don't push solutions that could work offline into a service behind a subscription for the sake of monetization. For instance, I'm on board with paying a license for a macOS note-taking app. But a subscription? No way. Recently, I came across an app that had note features built in and forced you to pay once you went above x notes. Sorry, not for me.

Then from those solutions, I prefer the ones that choose standard formats and/or expose APIs to enable interoperability. I believe someone should stay with a service because they like it, not because the service made it hard for them to leave. As we are building Tuist, we see that pattern in the developer tooling space, and we are working on changing it. We believe the right to freely choose the solution to one's problems should be respected. When a service respects that, it signals what values they stand for. Sure, this can change, but once you stand for certain values, changing them is unlikely because it would damage your reputation. This is why I choose tools like Logseq or iA Writer that use plain markdown files, which I can store in a Git repository for synchronization.

If the solution is open source, even better. I'll gladly support the developer or the organization behind it financially. This often means a drop in UX compared to the closed-source alternatives, but I've learned to appreciate that instead of being negative about it. I care much more these days about the values than the presentation of the solution itself. Note that open source doesn't necessarily mean longevity. But if they steer the direction of a popular tool poorly, it's likely that the community will fork and continue its development. I can also contribute my own ideas and code to improve the tools that I use, which I think is amazing.

I'm fine if the tool is VC-backed as long as the investment is reasonable relative to the value the tool is generating and its market. When a tool has been thrown onto a hyper-growth path, I can tell because their desperation to meet investors' expectations is often reflected in the tool becoming a Swiss army knife, releasing one feature after another. Alternative models are possible, but rare. The reason why I'm fine with tools that receive investment is that there are creators who are not financially privileged enough to quit their jobs and start their own businesses without initial funding. Investment solves this, and good investment can yield amazing outcomes. Penpot and Zed are examples of that, and I'm optimistic they'll get off the ground business-wise and become references in their space.

Choosing the right technology that's future-proof, respects people's values, and is fair is getting trickier, but I now have my own framework, and it has been working great for me. It often means I don't jump on the hyper-marketed trains that come and go, but I'm fine with that. I'm no longer excited by the shiny technology but by the human one.

For my personal account, leaving was easier than I expected. Sure, my account held value through the connections and reputation I’d built over the years—but so what? In the end, that value is abstract and can evaporate overnight. The constant pressure to build a reputation and stay active for the sake of "growing a brand" was seriously affecting my mental health. I was barely present in my real life because most of my mental energy was spent figuring out what to post next. These past weeks off X have been the healthiest and most present moments I’ve had in a long time.

Tuist’s account was harder to step away from. Every company in the developer tooling space seems focused on building their reputation and brand by throwing money at the problem—buying badges or paying for visibility in someone else’s feed. Since we’re working to get a business off the ground, the thought that haunted us was: Will we be forgotten? But the more we reflected on it, the clearer it became that there are other, better ways for people to discover us. In fact, those ways align more closely with the values we want our company to represent. A side benefit is that we’re not contributing to a platform that’s causing harm to society. Sure, as a business, making money is important—but we believe moral and social responsibility are equally important and should hold the same weight.

So, we decided to do the same for the Tuist account. We’re now active on Bluesky, Mastodon, and other platforms, as well as our community forum. These alternatives are SEO-friendly and eliminate barriers, making it easier for anyone to find our content and ideas without being manipulated by algorithms. We’ve noticed some players in our space adopt tactics similar to insurance companies, pressing the buttons of fear and other primal emotions. We’ve chosen a different path: putting out good content, being open about the problems we’re solving, and inviting people into the process. We trust that approach—and the people it reaches—to spread our message naturally. We don’t need an X account for that.

Personally, I plan to use this blog more actively too. I’m considering building a small Phoenix publishing tool to create internet "digital gardens"—simple, personal spaces that support syndication and other formats, like photos or save-for-later articles. It would be fun to work on and a great way to share ideas.

The internet is amazing without walls. We’ve decided we won’t contribute to building them or making society worse.

So, I thought, why not move it to an open-source Git forge backed by a non-profit organization? That's exactly what I did. The website is now hosted on Codeberg.

Unfortunately, as you might expect, these transitions come with some costs. Platforms like GitHub have invested heavily in providing a high level of convenience and free services, such as CI for open-source repositories. Losing those perks is frustrating, right?

On Codeberg, I have issues, pull requests, and a file explorer—but no CI. So, how am I going to continuously deploy my website on every commit to main? #shade

So my nerdy self couldn't resist and explored what a self-managed CI solution integrated with Codeberg would look like. This blog post is a documentation of the setup I came up with, which I expect to be useful to my future self, and also to anyone else who might be in the same boat.

Woodpecker CI

One of the best aspects of open-source is that there are powerful alternatives for nearly everything. Codeberg recommends Woodpecker CI, a robust CI solution written in Go. Sure, the UI might not be its strongest feature, but it gets the job done incredibly well. It even includes advanced features like auto-scaling, which might interest more experienced users.

Our setup will involve a publicly accessible server running the Woodpecker server, the Woodpecker agent, and CI workflows within Docker containers. Additionally, we’ll configure a reverse proxy to handle TLS termination with Let’s Encrypt certificates.

Installing Docker on the Host

Having obtained a server that's accessible via SSH, which in my case is one of the cheapest options from Hetzner with the x86_64 architecture and Ubuntu pre-installed, you can install Docker by following the official documentation. To verify that Docker is up and running, you can run the command:

sudo docker run hello-world

The success of the command will indicate a successful installation.

Note about the connection: You'll need to have SSH access to the server. In my case, I use VSCode's SSH capabilities not only to open a terminal session but also to edit files directly on the remote server.

Creating a Docker Compose File

To orchestrate the launching of all the services, we are going to use Docker Compose. Create a file at /opt/woodpecker/docker-compose.yml and add the following content:

services:
 traefik:
 image: "traefik:v3.1"
 container_name: "traefik"
 command:
 - "--log.level=TRACE"
 - "--api.insecure=true"
 - "--providers.docker=true"
 - "--providers.docker.exposedbydefault=true"
 - "--entryPoints.web.address=:80"
 - "--entryPoints.websecure.address=:443"
 - "--certificatesresolvers.ci.acme.httpchallenge=true"
 - "--certificatesresolvers.ci.acme.httpchallenge.entrypoint=web"
 - "--certificatesresolvers.ci.acme.email=postmaster@pepicrft.me"
 - "--certificatesresolvers.ci.acme.storage=/letsencrypt/acme.json"
 ports:
 - "443:443"
 - "80:80"
 volumes:
 - "./letsencrypt:/letsencrypt"

 woodpecker-server:
 image: woodpeckerci/woodpecker-server:v2.7.1
 container_name: woodpecker-server
 ports:
 - 8000:8000
 labels:
 # Web secure
 - "traefik.http.routers.woodpecker-secure.rule=Host(`ci.pepicrft.me`)"
 - "traefik.http.routers.woodpecker-secure.entrypoints=websecure"
 - "traefik.http.routers.woodpecker-secure.tls.certresolver=ci"
 - "traefik.http.routers.woodpecker-secure.tls=true"
 - "traefik.http.services.woodpecker-secure.loadbalancer.server.port=8000"
 # Web
 - "traefik.http.routers.woodpecker-http.rule=Host(`ci.pepicrft.me`)"
 - "traefik.http.routers.woodpecker-http.entrypoints=web"
 - "traefik.http.routers.woodpecker-http.middlewares=redirect-to-https"
 # Redirect middleware
 - "traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https"
 volumes:
 - woodpecker-server-data:/var/lib/woodpecker/
 environment:
 - WOODPECKER_ADMIN=pepicrft
 - WOODPECKER_OPEN=true
 - WOODPECKER_HOST=https://ci.pepicrft.me
 - WOODPECKER_FORGEJO=true
 - WOODPECKER_FORGEJO_URL=https://codeberg.org
 - WOODPECKER_FORGEJO_CLIENT=client_id
 - WOODPECKER_FORGEJO_SECRET=secret
 - WOODPECKER_AGENT_SECRET=agent_secret
 - WOODPECKER_SERVER_ADDR=:8000

 woodpecker-agent:
 image: woodpeckerci/woodpecker-agent:latest
 command: agent
 restart: always
 depends_on:
 - woodpecker-server
 volumes:
 - woodpecker-agent-config:/etc/woodpecker
 - /var/run/docker.sock:/var/run/docker.sock
 environment:
 - WOODPECKER_SERVER=woodpecker-server:9000
 - WOODPECKER_AGENT_SECRET=agent_secret
 - WOODPECKER_MAX_WORKFLOWS=8
volumes:
 woodpecker-server-data:
 woodpecker-agent-config:

Now that we have three services, Traefik, Woodpecker Server, and Woodpecker Agent. Traefik acts as a reverse proxy and a TLS terminator for Woodpecker Server. One cool thing about Traefik is that the configuration can be passed through CLI arguments or Docker labels, which makes it super easy to manage the configuration of the services. Note that we are mounting the /opt/woodpecker/letsencrypt directory to store the Let's Encrypt certificates and reuse them across runs.

The second service is the Woodpecker Server. This one starts the HTTP service that orchestrates the CI/CD pipelines and provides a web interface to manage the workflows. In my case, I'm using Codeberg, which uses the Forgejo Git forge, but you can use GitLab, GitHub, and the handful of others available out there. To authenticate, you'll need to create an OAuth application in your Git forge account and use the client ID and secret in the WOODPECKER_FORGEJO_CLIENT and WOODPECKER_FORGEJO_SECRET environment variables. Or the respective ones for the other Git forges.

You'll also need to create an agent secret and use it in the WOODPECKER_AGENT_SECRET environment variable. You can do so by running the following command:

openssl rand -base64 32

And last but not least, you'll need the agent service, which is the one that will run the CI/CD pipelines. Note in the environment variables that we are setting WOODPECKER_SERVER to instruct the agent to connect to the server we just started. And WOODPECKER_MAX_WORKFLOWS to limit the number of workflows that can run concurrently.

One thing that's important to call out is the following volume that we mount:

- /var/run/docker.sock:/var/run/docker.sock

If your workflows don't need Docker, you can skip this volume. However, if you plan to use Docker from your workflows, you'll need to mount the Docker socket. In my case, I need it for the deployment pipelines because I'm deploying the website using OCI images built using Docker.

Note that with that line you are escalating the permissions of the woodpecker-agent service to have access to the Docker socket, which runs on the host machine. So I'd recommend that you configure the workflows from branches opened by external contributors to require approval from maintainers before running the workflows.

Systemd Service

To run the services we just created, we can create a Systemd service. Create a file at /etc/systemd/system/docker-compose@.service and add the following content:

[Unit]
Description=%i service with docker compose
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=true
WorkingDirectory=/opt/%i
ExecStart=/usr/bin/docker compose up -d --remove-orphans
ExecStop=/usr/bin/docker compose down

[Install]
WantedBy=default.target

The service will start the Docker Compose file we created at /opt/%i/docker-compose.yml and remove the containers when the service is stopped. Note that the systemd service is generic, which means you can use it with other Docker Compose files by just changing the directory.

To start the service, run the following command:

sudo systemctl start docker-compose@woodpecker

And voilà! You should now have a fully functional CI/CD service running on your server.

DNS

Remember to point a DNS A record to the Hetzner server's public IP address. In my case, that was ci.pepicrft.me.

Many APIs back then remained synchronous, wrapped or not in an awaitable promise—similar to how some Foundation APIs, like FileManager, are still synchronous today. Wrapping calls to FileManager in something awaitable doesn’t actually make a difference since FileManager will still block the system thread until it finishes. This means you can’t reuse that thread to do something else while FileManager is busy.

In other words, to truly take advantage of async/await, the underlying APIs need to be designed to leverage it. Otherwise, you’re just wrapping synchronous code, gaining syntactic benefits without performance improvements.

This is why we began replacing FileManager with NIOFileSystem, which is designed with concurrency in mind. Unfortunately, its design has some flaws that lead to worse performance than FileManager’s blocking API. Plus, it doesn’t shield consumers from the limited number of available handles.

I’d love to see Apple invest resources in revisiting foundational APIs, so code built on top of them can fully utilize hardware capabilities without requiring too much additional effort.

When I have an open PR waiting for review, I start working on something else, but that PR still lingers in my thoughts. If, while working on the new task, a Slack message comes through, I pause what I'm doing to respond, all while keeping track of the pause so I can return to it. If an idea pops into my head, I let it simmer for a bit. On days when I let my brain juggle multiple things like this, I end up feeling mentally exhausted.

So, what am I doing to manage this? I’m practicing holding fewer things in my mind by using a queue system. When I finish a task, like reviewing a PR, I add it to the queue. If a new idea comes up, I put it in a queue for later. If a support request comes in, I queue that as well. Instead of a single queue, I have multiple ones, and I allocate specific time slots for each. My email inbox is a queue that I only process once a day. The same goes for support issues and PRs. I don’t let them distract me throughout the day.

The downside to this approach is that it can feel like working on a production line—doing one thing after another until the day is over. What about the creative work our brains thrive on? I make sure to leave space for that too. The chain-like tasks are important but often not the most exciting. Creative work, on the other hand, is the most exciting but doesn't always have an immediate impact on the project at hand. Balancing these two types of work is key to maintaining my mental well-being, and I’m continuously working on finding that balance.

What about you? How do you manage your mental input and workload?

Recently, I’ve examined the dashboards of various tools in our space and was astonished by the neglect evident in their design. They bombard users with banners urging upgrades to higher plans, overwhelming amounts of competing information, and a persistent push to contact sales. While I understand the need to generate revenue, such an obsession often sacrifices the craftsmanship of the product.

At Tuist, we refuse to compromise on quality. This commitment is deeply rooted in our principles. We prioritize creating a product that sparks joy, which is why we’ve invested in hiring a product designer, even within our limited budget. We believe that aesthetics are crucial for evoking positive emotions when using our tool. As a result, our growth may not match the rapid pace of other players in the industry, but that’s not our goal. We are focused on building for the long term, emphasizing slow and steady growth driven by product quality, our open-source contributions, and ongoing community support.

Our relationship with open source is genuine; it’s not merely a marketing strategy like brands paying influencers to promote their products. We are committed to leveraging open-source as a means to drive innovation in the industry, dedicating our time and resources to make it a reality.

We are turning Tuist into a commercial business so that we can do more MIT open source for the Apple ecosystem.

This mindset also shapes our technical decisions. As a small team, we recognize the need to keep our technology stack simple, as we cannot afford the complexity of maintaining a convoluted system. There’s a crucial distinction between a system that is inherently simple and one that merely appears simple because a third-party service manages the complexity. For this reason, we’ve chosen Elixir, and we couldn’t be happier with our decision.

Embracing simplicity has significant advantages, particularly for our on-premise customers who need to self-host the server. The requirements are minimal: a server, a PostgreSQL database, and S3 storage. If scaling is necessary, it’s as easy as adding more cores and memory to your instance. Furthermore, we prioritize standards across the board. Our stack doesn’t rely on a build tool; we write vanilla CSS and JavaScript—yes, no Tailwind. This approach is liberating, as the web platform is designed for longevity, and we intend to leverage that durability.

Do we worry about breaking changes in Next.js? Not at all. What about Tailwind or TypeScript? We remain unconcerned. While others may spend time updating their toolchains, we focus on building useful features with our straightforward CSS and JavaScript. Our productivity has never been higher, and once we establish our design system using web components, creating new features in Tuist will feel as effortless as playing with LEGO.

Eventually, we plan to open-source our server, allowing you to contribute and extend it as you wish. We are steadily building momentum that will become unstoppable.

Will we reach every corner of the app development ecosystem? I doubt it. However, we will gradually convert teams into believers in our craft and contributors to a common vision that advances the industry. Will this take years? Absolutely—so what? We are designing our company to maximize momentum with minimal resources while ensuring that everyone involved in making Tuist possible enjoys the best professional experience of their lives as they build our product.

Trying to find reasons why it sometimes feel exhausted is pointless. When it happens, I take breaks. Specially now, where as part of building Tuist, I feel I’m constantly switching between different areas of the brain.

When I’m responding emails, it puts my brain in a mode that’s not inspired to code. When I’m coding, it’s not inspired to be social. And if I force it, it’s not natural so I exhaust it and reach frustration. Tricky, isn’t it?

Impostor syndrome invades me a lot too. I boycot myself. What if Tuist doesn’t work? What if we don’t reach the point of financial sustainability that we are aspiring to have? What if we disappoint the organizations that are betting on us? What if I don’t have the mental clarity to pull this off?

And social networks don't help here. I'd isolate myself from the world and focus on the craft, which brings me a lot of joy, but how would people know about Tuist? But if I spend too much time in it, envy and comparison start to creep in. Are we doing enough? Should we do more?

I don't have answers. But I know what makes my brain feel good, so I'm giving it what it needs. I enjoy creating things. I enjoy writing. I enjoy going for long walks. I enjoy sleeping a good siesta. So I'm prioritizing those things throughout my day, because otherwise, I'm not good to anyone.

Brains are complex, treat yours well. I didn't listen to mine for a long time, and it's time to change that.

Open source and free software are non-excludable and, contrary to what many believe, rivalrous—because the resources available to maintain and improve them are limited. This makes them a common good, a concept I first encountered while reading the book Working in Public.

However, I hadn't fully realized that, from the perspective of open source companies like the one we are building at Tuist, open source is also rivalrous in another way: the shared resource is the customer, who cannot be shared by two companies at the same time.

Tuist has become a common good. And like any common good, it began to experience the tragedy of the commons—sustaining the project became increasingly difficult. When you reach that point, you must consider how to balance the makers and the takers. Otherwise, the project will die. This is something I’ve observed in many open source projects in the ecosystem where Tuist operates: they struggle to keep up with demand and slowly fade away.

In his blog post, and drawing on ideas from past research, Dries shares three patterns to address this issue, which we have considered at Tuist:

1. Self-governance: This is unfeasible at a large scale where many takers have conflicting interests. Making this work would require most of the limited resources available to be spent on governance. 2. Privatization: This is the approach we are currently exploring at Tuist, similar to what companies like Mozilla have done. Through our paid server features, we gain a commercial advantage over takers, while still creating a positive social impact for all users of the open source project, including the takers. In other words, privatization allows for a win-win scenario. 3. Centralization: This approach mirrors how governments manage common goods (e.g., highways). In open source, we see this in foundations that govern projects. The challenge with this model lies in the accuracy of monitoring and the effectiveness of rewarding (or sanctioning). As Dries notes:

Because Open Source contribution comes in different forms, tracking and valuing Open Source contribution is a very difficult and expensive process, not to mention full of conflict. Running this centralized, government-like organization also needs to be paid for, and that can be its own challenge.

It's reassuring to see that what we are experiencing at Tuist is not unique. The imbalance created by having more takers than makers is a common problem in open source, and there are ways to address it. We've discarded self-governance and centralization for now due to the costs involved. Instead, we are exploring privatization as a way to bring in funding to support continued open source development.

Not long ago, a new group of licenses emerged: fair. These licenses look promising as a way to explore open-sourcing the innovations we are bringing to the server.

Why bring this up? Because I think I’m stretching my brain to hold too many programming languages and paradigms. Over the past year, I’ve gone from being highly proficient in Swift to learning and familiarizing myself with Ruby, JavaScript (in the context of Node.js), and most recently, Elixir. I’ve also explored Rust and, more recently, Zig. There’s something valuable about staying informed—you gain new ideas and consolidate concepts across languages. For instance, many concepts in Swift are rooted in Rust, and learning Rust helps deepen your understanding of Swift. But this juggling act is becoming overwhelming for my "monkey brain."

What makes it especially draining is that much of my mental energy is now focused on understanding the complexities of building a company. I’m asking my brain to absorb information like it did 10 years ago, which often leads to days of mental exhaustion—a situation I’m not happy about. I need to become more comfortable focusing on the essential knowledge required to build the company, while maintaining a sense of curiosity without the pressure to master everything. It’s simply not feasible.

At the same time, Tuist has the potential to make a significant impact in the Swift ecosystem, particularly in developer tools and packages. With more focus, we could capitalize on that opportunity. For example, I want to create a design system for the CLI, which would elevate the Tuist user experience and lay the groundwork for other CLIs. Or I could dive into Swift’s concurrency updates and develop a resource that benefits both us and the broader community. Unfortunately, I haven’t been able to pursue these goals because I’ve been preoccupied with learning other technologies. It’s time for a change.

Moving forward, I’ll concentrate on three areas: building the company, Elixir, and Swift. Going deep in these areas will enable me to make meaningful contributions to Tuist.

Licenses

Licenses define what you can and cannot do with a piece of software. Some, like the MIT, Apache 2.0, or GPL, are approved by the Open Source Initiative. Others, like the group of Fair Source licenses, aren't, yet they remain equally valid and enforceable.

It's important to highlight three things:

1. A license grants you rights over the code. 2. However, it doesn't give you the right to decide the project's direction (often misunderstood). 3. The existence of a trademark prevents you from using the project's name freely (often overlooked).

Many conflicts stem from the mistaken belief that having rights over the software also grants rights over its direction, which is entirely incorrect. Companies and developers should remember that while disagreements over a project’s direction are inevitable, unlike with closed-source software, open-source projects allow you the freedom to fork the project and take it in the direction you desire. Though it's often easier to lobby maintainers to change their stance, it's not the only path. This is why companies like Shopify or GitHub ensure they have a voice in the direction of Ruby and Ruby on Rails or join foundations like the Rust Foundation.

The world is diverse, and different developers and companies have different visions for a project, which is perfectly fine. Expecting a single direction to please everyone is utopian. Disagreements over the project’s direction are normal and valid, and expressing them publicly is encouraged. However, depending on the project's governance model, you might have more or less entitlement to influence its direction. Let's delve into governance.

Governance

The governance of an open-source project refers to the rules and processes that define how decisions are made. Many projects lack formal governance, often resulting in the benevolent dictator model, where the project’s creator or a select group of maintainers have the final say. This is the model that Rails follows. I'm not here to debate which model is better, but I will say that the absence of governance is a problem and often the root of many conflicts.

At Tuist, we currently lack a formal governance model, so we implicitly follow the benevolent dictator approach. We are working to change that. Bitrise could have publicly raised concerns about our lack of governance, and that would have been a fair point. Due to this lack, they wrongly assumed our intentions:

"The maintainers are showing more interest in extracting revenue from their community than in making decisions that are best for the project and its end users." — Zach Gray, Bitrise

This is completely false. Our focus has always been on making the project sustainable. The work we've done, not only since committing the first line of code but even after that blog post, is a testament to our true incentives. We closed off some parts of the code to prevent an unsustainable imbalance they were unwilling to help us solve.

Here’s the thing: When you're just starting out, you don't spend time crafting the perfect governance model or considering the legal implications of your licenses and trademarks. But as your project grows and garners community value, you're inevitably drawn into capitalist dynamics you never wanted to be a part of. Suddenly, you need to learn and adapt to those dynamics quickly, with far fewer resources than the companies challenging you.

More democratic models are rare in open source. One exception is the Berlin-based Git forge Codeberg, which has a non-profit foundation backing it, with a board that makes decisions. Anyone can join the board and vote on matters. But this is unique—most projects follow the benevolent dictator model, and that’s okay. While the dictator may act democratically at times, they still have the final say.

If having a say in a project’s direction matters to you, consider this when choosing open-source software. If not, accept the risks of misalignment. You can voice your concerns publicly and try to lobby for changes, but don’t expect maintainers to comply.

To summarize:

1. Governance determines how decisions are made in a project. 2. The absence of governance usually implies a benevolent dictator model. 3. Pure democracy is rare in open source. Benevolent dictators may adopt some democratic practices, but they have the final say.

Trademarks

Lastly, let’s talk about trademarks. Open-source projects develop a brand around their name. It’s an intangible asset that represents the project’s values and quality. Registering it is essential to protect it from misuse.

The creator of Docker acknowledged the mistake of not registering the trademark earlier and took a different approach with Dagger, registering the trademark early and publishing guidelines on its use. We did the same with Tuist. The Tuist trademark is owned by Tuist GmbH, and we’ve published guidelines for its usage. Without these protections, anyone could use the Tuist name to create a fork, misleading users into thinking it was the official project, potentially damaging the project's reputation and years of work.

But note this: The trademark must be registered under a legal entity or person. If there’s no company or foundation behind the project, the creator must own it. The creator of WordPress initially registered it under his name, transferred it to the WordPress Foundation, and later granted rights to Automattic for commercialization.

Problems in this area often arise from the subjectivity around trademark usage. I can somewhat understand Matt's concerns about the WordPress trademark’s use by WP Engine. Based on his comments, it seems he had been in talks with them for over a year, expressing these concerns. This reminds me of conversations we had with Bitrise about Tuist's sustainability (we didn't have a trademark at the time). They forked Tuist, directed their customers to use it, and had full freedom to do so, misleading their customers into thinking it was the official project. Naturally, customers didn’t want to rely on a fork not maintained by the original team, and Bitrise didn’t want to work with us to make the project sustainable. It's a bit of the issue between Automattic and WP Engine but a small scale. Automattic wanted a share of WP Engine's revenue or more active contributions to the project, and we only wanted to make the project sustainable. We could have reached good terms, and they'd have benefited from partnering with us, and we'd have benefited from their contributions. And since they were not only unwilling to help us, but also marketed their service as much better than ours, we had to act to protect our project.

In my opinion, having a trademark is crucial. If you maintain an open-source project, I recommend registering the trademark under a legal entity or person as soon as the project gains traction. You'll thank me later.

To summarize:

1. A trademark is an intangible asset that represents the project's values and quality. 2. Without it, misuse of the project’s name can harm its reputation. 3. The trademark owner controls its usage. 4. Guidelines for trademark use can be subjective, leading to conflicts.

Closing Words

Licenses, trademarks, and governance models are the three pillars of open-source projects.

As a maintainer, you shouldn't neglect any of them. Define these aspects early, communicate them clearly (where we could have done better at Tuist), and ensure they are respected. Most importantly, iterate on them as necessary, as the environment and the needs of your project evolve.

As a consumer of open-source software, define what matters most to you. Choose projects that align with your values. If direction matters to you, find a way to influence it. Often, in a benevolent dictator model, contributing actively can give you that influence. If you don’t care about the direction, accept the risks and costs of potential misalignment. You can voice your disagreement, but don’t expect maintainers to change their minds. Remember, you often only have entitlement to the code, not to the direction.

Finally, open source is still better than closed source. You may disagree with the direction of an open-source project, but you can fork and maintain it yourself. You can’t say the same about closed-source software—companies providing critical services can shut down anytime, and you won’t get access to the code.

In my view, we need more open source and more education and awareness around these topics.

When I something complex, I like to go deep into understanding where the complexity comes from. Because only then I'll be able to make an informed decision on how to approach it. Through Erlang, I realized that a problem space with the right modelling can make layers of complexity disappear. Erlang does it through their concept of processes. So my wonder with Swift and data-race safety was: "Is its complexity avoidable?"

Swift is in a bit of an unfair position to make that avoidable. First, it had to reconcile Objective-C's OOP paradigm, which is known for embracing mutability, which is the culprit of data-races. Wouldn't it have been awesome if they didn't have to support compatibility with Objective-C? Definitively! But Apple and many developers couldn't have afforded that.

Moreover, Swift was pushed beyond the Apple ecosystem, more specifically to the server-side. Server-side applications are known to be highly-concurrent, which means, data-race issues become more apparent. This explains Apple's recent push for the actor model and structured concurrency, which you need to propagate the cancellation of work, when for example a request is cancelled. All this push makes sense when looked from the angle of Swift in the server-side, but from the perspective of an app developer, or in our case a CLI developer, it feels somewhat unnecessary.

Because Swift's origins had a strong focus on Apple platforms, not as highly concurrent as servers, some language design patterns were not optimized for concurrency. Erlang started with processes, and everything built from there. Imagine if Swift had started with a similar concept, and built all the frameworks on it. The story would have likely been different.

So Apple has done a great job navigating how the language has been evolving and reaching new environments. However, the debt is accumulating and taking shape in the form of language complexity. Or at least that's my perception. Perhaps in a few years, we'll all become that familiar with it, that it won't conceive it as complex anymore. This poses a very interesting question, somewhat philosophical about the future of Swift: Is trying Swift to do too much?

I understand why Apple is trying to take Swift to many places. And it's quite impressive to see what the community is achieving with it. For example the PointFree folks coming up with patterns for cross-platform UIs, compiling Swift to Wasm, and potentially leveraging that soon for expanding Swift Macros, or running Swift on the server with projects like Vapor or Hummingbird. It's truly inspiring. Yet, I can't help but have a feeling that Apple is just partially supporting the idea that Swift can be a language for everything. I sense a bit of fear in involving the community more in the governance of the language and finding incentives to make it more community-driven. Some frameworks remain closed-source, and the language evolution is still very much driven by Apple's needs.

The question is, is Apple going to change that and throw themselves full into taking Swift everywhere? Or will we forever be in this let's try Swift here and there adding language features and needed without a big picture of how the language should evolve?

In an effort to balance building a company and coding with activities unrelated to work, I’ve recently returned to painting—this time, using an iPad. I was genuinely surprised by the power of these devices, which I had previously used only for reading. It once seemed almost pointless to own one, but now I understand why creatives gravitate toward it, and why Apple markets it to them. It’s a remarkably powerful and portable tool for creative expression.

I’m even considering exploring video editing with it, using some short clips I recorded in Berlin—just to see how far I can stretch my creativity. It feels like there’s a part of my brain that’s been dormant, waiting to be reawakened. There’s also something truly beautiful about engaging in these activities without any expectation of outcome, unlike coding, which has become more outcome-driven now that there’s a company to build. If there’s one thing I’ve learned, it’s that my mind thrives when it has room to roam. To code for the joy of coding, to paint for the joy of painting, to walk for the joy of walking...

Anyway, I’m on a flight to Madrid to attend NSSpain, and I thought I’d share some thoughts on iPads after spending some time drawing on mine.

Money can buy a false sense of community. People may gather because you send them freebies or because they follow what an influencer, paid by you, says about your product. But this engagement fades when the money stops flowing. Their motivation is purely extrinsic, and there’s nothing in your product that makes them stick around. You're just a sales-oriented company. If you truly cared about community, you’d build your company around it from the start, not the other way around.

Building a community takes time. It requires putting people first, being open to them, and involving them in how your product is shaped. Interestingly, involving them also brings a diversity of ideas, which can improve your product. It also means building for the community without expecting anything in return. Using your privileged position to commoditize the space reveals a lot about your values. When you care about advancing the ecosystem and inviting others to participate, everyone wins—the community, the ecosystem, and ultimately, you. But when you only focus on your own gain, greed may become your worst enemy, whether that happens down the road, or after you’ve exited or gone public and can claim you've succeeded.

Many challenges faced by tech organizations aren’t technical, but social. It’s not just about how big or crowded a market is or how feasible a technical solution might be, but about how willing you are to focus on your community and gain their trust by building for them without expecting anything in return. I’ve noticed that many companies aren’t willing to do this, and that’s why they fail in the long run. It’s inconceivable for them to do something without an immediate return.

And this doesn’t necessarily mean going open source. Look at Fly.io—they offer incredibly valuable resources for free, which they create themselves, rather than paying for low-quality content like I’ve seen other companies do. They also hired and provided a safety net to maintainers of popular projects, like Phoenix in the Elixir ecosystem, indirectly supporting the community and the broader ecosystem. You can also earn a community’s respect and trust by betting on open standards instead of locking users into your product. This is especially important when building for developers, who understand the significance of standards and their role in the long-term health of the ecosystem. If your solution is walled off, developers might use it out of necessity, but sooner or later, someone will come along with a solution built on different values, and your entire platform could fall apart.

For seven years, we were privileged to have jobs while working on Tuist on the side. Our focus was on solving problems, advancing scalable app development, and building tools that others could build upon. Now, we are working on turning this into an open business that embraces the same values. It requires setting the right boundaries in certain areas, but if we get it right, we’ll continue building these tools while supporting the communities we serve. This isn’t about trying to dominate every corner of the app development space. It’s about building a healthy business that supports the communities we’re building for.

We are embedding seven years of open-source experience into how we’re shaping this company. Though our progress might be slow at first, we see this as a marathon. We’ll keep running and building for the long term.

Remember the revolution that containers brought to the shipping industry? Suddenly, transportation methods adhered to a standard, allowing innovation at different layers. There are many examples of this on the internet, and the phenomenon is called the “narrow waist.” Narrow waists shift focus from redundant efforts to new forms of innovation.

What we are missing in automation is the equivalent of containers or narrow waists. Fortunately, Dagger is building just that. No more vendor lock-in through proprietary pipeline formats or walled-off automation experiences built into SaaS products. A brighter future for automation is on the horizon, and Tuist is betting on it.

Mobile DevOps? Free Automation Ops is better. It’s free because it gives organizations the freedom to choose and move across services with minimal costs. As a result, it forces existing CI providers to innovate. My guess is that many will fall victim to the sunk cost fallacy, throwing money at marketing their Mobile DevOps solutions. Good luck! We need to bring freedom back to organizations.

Dagger will not only be instrumental in gaining freedom but also in transitioning automation from languages like Ruby or bash scripts to languages such as Swift, Kotlin, or any other language of choice. Yes, you read that right: transitioning away from Fastlane is possible. Fastlane is fantastic, but when you blur the line between automation and CI—allowing workflows to run locally or remotely, as needed—the developer experience becomes truly magical. Developers will also have access to a community-driven ecosystem of steps from Dagger.

Tuist will enable Dagger pipelines to run in macOS environments, triggered by a CLI command or a GitHub event. It’s simple:

tuist workflows run test –remote xcode-15

This command means: “Take my project, run the workflow in a remote environment with Xcode 15, and make it feel like it’s running locally by forwarding the standard pipeline events.”

Want to see a running build? Easy:

tuist workflows logs 1234 –tail

There’s no need to build web-based terminal experiences when developers already spend their time in terminals.

In 2024 or early 2025, Xcode developers will be able to do this and choose a CI provider that maximizes their freedom.

I’d describe my 20s as the decade of professional success: get a higher salary, climb the ladder, and get recognized in the industry. The dream was suddenly spoiled, and I was overwhelmed by many feelings. I was disappointed about the reality of the tech industry and how businesses work, which I hadn’t realized before. I also found myself with an identity toxically intertwined with my professional self. My work defined myself. Coding had evolved from a pure craft activity I loved into a tool to be recognized or successful in an industry filled with entrepreneurs and indie builders. I ought to be like them; I thought many times: work, work, work, and work. I made my health and the Pedro outside of work secondary. As bad as it sounds, I forgot about myself. I became addicated to working.

“Hacking Capitalism” by Kris Nóva started to open my eyes. It helped me better understand capitalism and the tech industry and shift the focus toward myself and my passion for the craft. However, we needed to turn Tuist into something we could make a living off, so I inevitably threw myself into the industry I had come out disillusioned. On one side, I conceived it as an opportunity to codify its values and a healthier approach to doing business with technology, one that values openness and empowers both the people who use our tools and the people who make it possible. However, you still need to navigate the unfair practices of the industry: people saying that you have no chance to succeed with two founders being technical, companies refusing to correspond to the value that they get through financial contributions, or feeling tiny against the giants that have endless streams of capital to outcompete you or take their privilege position to shit on you. It has been challenging to navigate, but I learned something about it. Perhaps I’m still too connected to work?

Another book further opened my eyes here. It’s called “Technofeudalism” by Yanis Varoufakis. It talks about the idea of cloud capital and how it tore down the walls that gave us freedom in this capitalistic world. The freedom to be someone else outside of work. The freedom to think without thinking about whether something should be posted. The freedom to take a nap without thinking about meetings. The freedom to have a timeless hobby. All of that is gone in this world that Technofeudalism is shaping, and I fell victim to that. This is not only due to the amount of thinking that went into work but also the peripheral X doom-scrolling and the ongoing feeling of having to work on my and Tuist’s brand to succeed in building a business. I succumbed to the cloud capital participating in it with my attention and time.

I think establishing limits there is needed for my mental health, and my mental health is, in fact, needed to build a healthy company, so I’m not doing either myself or Tuist a favor by trying to be always online and giving away investing in myself. So I started to change that. It won’t be easy because I have to revert to many patterns that I acquired over the years, but it’s a must-do to remain mentally healthy. I uninstalled Slack and removed my work email address from the phone. I’m also limiting my time on social channels and stopped using X. More and more, it’s becoming a very hostile environment. I like it in Mastodon, and while the reach of what we post there is smaller, I’m becoming comfortable with that. It’s not my role to capture people’s eyeballs with shiny posts on X, but to share humane stories that people can read at their own pace if they feel like it. This last thing aligns more with our values, but it feels odd having jumped on the Twitter and X train for many years.

I’m trying not to do things outside of work: resting, walking, or exercising. I’m reverting this idea that my life has to feel productive. I’m not a machine, and therefore, I shouldn’t treat myself like that. I have emotions, a complex brain that I need to take care of, a family to love and spend time with, and a life to live and enjoy instead of spending it jumping on the hamster wheels of becoming successful, whatever that means.

I want to live a simple life with the people I love. Really.

I've been following Pieter for some time, and I really appreciate his ability to cut through the noise and focus on what truly matters. This is a skill I find difficult to acquire, partly due to the many years I’ve spent perfecting software craftsmanship, which often leads me to analysis paralysis. You know, before you build that tech piece, you have to find the perfect technology, set up continuous integration, choose the right framework, and by the time you have everything set up, you've lost the motivation to build the actual product. I’ve been there many times, and if you’re a software craftsman like me, I’m sure you’ve experienced it too.

You can’t imagine how many times I’ve wondered if I should be more scrappy in my work, focusing on making money quickly and monetizing the skills I’ve acquired over the years. I even feel guilty at times for not doing so. Am I foolish or what, Pedro? You might be like those people who are always waiting for the perfect moment to start a business and capitalize on the frenzy of the ecosystem, because if you don’t, someone else will. All that open-source work I’ve done is great, but it doesn’t pay the bills. That’s a mental struggle I often go through, especially when I see indie hackers like Pieter Levels discussing their MRRs and how they’re making a living from their work.

But you know what? My conclusion is often the same: I’m not like them. My motivations are intrinsic, and this is something I can’t ignore. When I hear them talk about people as mere tools for making money, I can’t help but feel disgusted. I know we live in a capitalist society and money is important, but I view it as a result of the work I do in supporting others, not as the sole goal.

The best technologies we’ve seen were created by people who worked for fun and were intrinsically motivated: Linux, Git, Wikipedia, Ghost, Ruby, and many others. If you ask me, that’s the kind of technology I want to build—one that leaves a lasting impact on the world and inspires others to do the same. The challenge is achieving this in a world where we are increasingly selling the image that we should be obsessed with money and fame. Those who chase extrinsic motivations often find it has a unique momentum that can’t be stopped. Microsoft knows it well.

So yeah, it’s tricky being an intrinsically motivated person in an extrinsically motivated environment, but the happiness of doing what you love is worth it.

Ideas like code reviews through pull requests, which have a sophisticated diffing interface, or LICENSE.md, which makes it possible to bind contributions to a specific license, are rare in design. Figma and Pentpot are trying to lay out the pieces, but we still have some way to go. Imagine if designers built curricula through open design projects, which would be the counterpart to open source but in design. They could review each other's work before merging it into a "branch" (or the equivalent of that concept in design) and be able to license their work under a specific license.

We were eager to explore this idea in Tuist, so we joined some communities, and we were lucky to find Asmit Malakannawar, who immediately connected with us, the ideas behind Tuist, and our vision for a fully open platform to extend the capabilities of native tools. Like us, Asmit turned out to be a huge advocate for open source. He is involved in the GNOME community, where he made significant contributions in the past. Marek and I could not believe we crossed paths with him, but this is the beauty of open source. You cross paths with very talented people who place a strong focus on the people and the craft, and they can impact the software in very distinct ways.

It's been a few weeks since he's taken on some ownership from us, exploring ideas that have been in our backlog for some time, and taking the lead design role in the Tuist project. As part of that work, we'll explore the idea of open design, make designs open under a permissive license so that anyone can use them, including developers who will be able to extend the platform in the future. We'll also contribute design-related pieces of technology to the Elixir ecosystem, which is a language we're passionate about. We want to inspire more designers to get involved in open source, and make our small contribution to making "open design" a reality.

I won't cease to repeat this: Being open, and balancing that with building a thriving business that can support working in the open, is a unique strength in a space where people have become secondary in how we do business. We are placing people at the forefront of our business, and inviting a diversity of ideas to give existing native tools the superpowers necessary to use them at scale.

Welcome, Asmit, to the team!

We achieve this by:

1. Building on and embracing standards over proprietary formats. 2. Exposing and documenting programmatic interfaces so developers can access the data from Tuist's domain. 3. Opening the code that powers the platform.

It sounds fantastic on paper, but in practice, 3. poses the most significant challenge. How do we prevent putting Tuist at risk?

Open Source and permissive licenses like MIT and Apache bring freedom but don't protect the business. Companies can try to benefit from it in a predatory way without ensuring a healthy balance that benefits all stakeholders. They even dare to go wild publicly when you spoil their plans to protect Tuist.

Other organizations seek protection by adopting AGPLv3, which many companies have policies against, and selling dual licenses and enterprise features. Those businesses are often referred to as Open Core. However, companies are still facing litigation risks, which we do not want for our customers. So what's the alternative?

I think the answer for Tuist is Sentry's new license concept: Fair Source, particularly their Functional Source License (FSL). The license beautifully strikes a good balance between the freedom of Open Source and the protection of the business.

The code is available (Customer freedom). You can check out the code, use it, extend it, contribute to it, and host it as long as you don't try to compete with the business (Business protection) so that the project can thrive and benefit everyone. And after two years, the code becomes MIT, so if the business dies, anyone can take it over and continue to thrive.

David Cramer puts it very well in his blog post Open Source is not a Business Model:

"If they choose AGPL they’ll deter all but the most determined competitors, but given its a GPL-based license, it might also scare off certain customers. If they choose MIT they might as well rely on thoughts and prayers, as nothing protects them from predatory companies. So what do they do? Well, most of them choose Closed Source."

So I think a fully open Tuist platform could unfold this way:

• We expand our current narrow TAM. The milestone here will be releasing Tuist Workflows. This continuous integration blurs the line between CI/CD, a build system, and local and remote environments, opening Tuist up to many ecosystems. Swift will become the ecosystem where we started and the tool to enable the best developer experience of the Tuist platform. - We open the server code under FSL allowing companies to self-host and charge companies for hosting the software ourselves, which we'll be experts at.

Not everything needs to be FSL. Some components like the Tuist CLI or technologies we'll develop to enable this vision can and will be MIT. They'll be our gifts to inspire others to build thriving open businesses.

Marek and I are still sleeping on these ideas, but we intend to make this happen. We can only build the best in class productivity platform if we embrace openness.

This pattern, which originated in the consumer space, has also infiltrated the developer tooling space. Companies argue that runtimes and ecosystems like JavaScript are too complex, so they create coupled abstractions for their services. Tasks that can be solved client-side are often pushed to the server to sell services. While some problems genuinely require server-side solutions, those that can be handled on the client side should be, in my opinion.

Need a database? Use a remote one we manage for you, with a CLI to interact with. Implementing authentication? There’s a remote service for that too. Running your app in the same environment as production? Use a proprietary runtime accessible through the company’s CLI. Want to avoid environment setup? Use the browser, and we’ll provide an environment for you.

This not only causes a loss of control over your data and content but also over your development experience, costs, and the ability to craft software offline. I can't subscribe to that model.

Elixir and Erlang might not be trendy, but they don’t create unnecessary complexity like JavaScript does with its “Complexity Abstraction As A Service” (CAAAS). Proprietary abstractions rarely claim to solve problems that can be easily addressed with a few lines of code in Elixir. Long-running server processes? Mainstream solutions suggest serverless, but serverless doesn’t handle background jobs well. So, there are additional services for that. You’d think production uses the same local NodeJS runtime, right? Not exactly; you need the platform’s proprietary environment. And the list goes on.

If this is the future of software development, I’m out. I’ll invest my time in learning and using tools and standards that allow me to craft software the way I want.

In recent years, I’ve learned through life circumstances that a simple life brings a peace of mind that’s priceless. This is hard because sometimes the environment pushes you to seek happiness through material possessions, but those, in the end, bring additional problems that I wouldn’t have had in the first place. For example, I wouldn’t have felt angry at Apple wanting to charge me €250 to fix an AirPods Max that they broke with a software update if I hadn’t bought them. Now I use old earphones with cables, and not only do they last longer, but I don’t have the responsibility of having to charge them. I don’t have a car, and I don’t plan to buy one. I fell into the trap of buying an Apple Watch, and now I have to remember to charge it every night. I don’t know... life is simple, and we are pushed to make it more complicated. I think that complication puts us in mental exhaustion, which is the perfect ground for hyper-capitalists to keep pushing more stuff on us. Note that I say hyper-capitalists to differentiate from other forms of capitalism that bet on circular economies.

I never felt the need to buy to show off. If I was lucky enough to get a bit of extra money through my work, I saved it or took my parents on holiday in return for all they invested in me over the years. Their happiness is priceless and something that I’d pay for endlessly.

When I scroll through X or LinkedIn, a lot of what I see makes me allergic to those platforms. There is a definition of success based on how many impressions your publications got or how large your last round of investment was. They are pushing us to redefine happiness and success based on monetary and fame goals, and it’s very common to fall into that trap and pursue the same things, only to realize that you might end up being more miserable despite all those impressions of your posts. I feel allergic to that, but I must admit I fell into that a few times in the past. Those platforms were designed for that.

And now that we are building a company, it feels like rowing in a different direction, but it’s a lot of fun doing something based on our own intuition and definition of happiness. Companies build proprietary walls that we tear down. We make others angry by protecting a piece of software to ensure every organization can continue using it for as long as they can. We step into established domains like CI with the energy to do things differently. We share what and how we do it because we’d like to inspire others to do the same and build trust through transparency.

So yeah, a simple and social life optimizing for fun is what I see myself doing in 10 years. And I’ll push away anything that tries to steer my life in a different direction.

To achieve that, I used a tool that I discovered recently through Mise, git-cliff, which automates the generation of changelogs based on the repository's local and remote history (e.g., GitHub pull requests). Once the tool is installed, something that you can achieve easily with Mise:

[tools]
"git-cliff" = "2.4.0"

You can initialize it by running:

git cliff --init github

The argument github instructs the initialization command to use the vendored GitHub template. You can check out this list of other templates. The command generates a cliff. toml with a default configuration, which in my case I left as is.

The workflow

We use GitHub Actions, so the first thing we'll need in the release workflow at .github/workflows/release.yml is the configuration to run for every commit in the main branch:

on:
 push:
 branches:
 - main

As one of the first steps after checking out the repository, we'll need to check whether a release is necessary. We can do that by comparing the persisted CHANGELOG.md, which I had previously generated with git cliff -o CHANGELOG.md, and the one that would be generated with the bumped version, which I can obtain with git cliff --bump:

- name: Check if there are releasable changes
 id: is-releasable
 run: |
 bumped_output=$(git cliff --bump)
 changelog_content=$(cat CHANGELOG.md)
 if [ "${bumped_output}" = "${changelog_content}" ]; then
 echo "should-release=false" >> $GITHUB_ENV
 else
 echo "should-release=true" >> $GITHUB_ENV
 fi

Note that I set git.filter_unconventional = true to only consider releasable those commits that follow the conventional commit format.

From there, we can obtain the next version (note that we skip if we shouldn't release):

- name: Get next version
 id: next-version
 if: env.should-release == 'true'
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 run: echo "NEXT_VERSION=$(git cliff --bumped-version)" >> "$GITHUB_OUTPUT"

And the release notes:

- name: Get release notes
 id: release-notes
 if: env.should-release == 'true'
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 run: |
 echo "RELEASE_NOTES<> "$GITHUB_OUTPUT"
 git cliff --unreleased >> "$GITHUB_OUTPUT"
 echo "EOF" >> "$GITHUB_OUTPUT"

The remaining steps are just updating the CHANGELOG.md, committing the changes tagged with the version, pushing the changes upstream, and creating a release on GitHub.

- name: Update CHANGELOG.md
 if: env.should-release == 'true'
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 run: git cliff --bump -o CHANGELOG.md
- name: Commit changes
 id: auto-commit-action
 uses: stefanzweifel/git-auto-commit-action@v5
 if: env.should-release == 'true'
 with:
 commit_options: '--allow-empty'
 tagging_message: ${{ steps.next-version.outputs.NEXT_VERSION }}
 skip_dirty_check: true
 commit_message: "[Release] Command ${{ steps.next-version.outputs.NEXT_VERSION }}"
- name: Create GitHub Release
 uses: softprops/action-gh-release@v2
 if: env.should-release == 'true'
 with:
 draft: false
 repository: tuist/Command
 name: ${{ steps.next-version.outputs.NEXT_VERSION }}
 tag_name: ${{ steps.next-version.outputs.NEXT_VERSION }}
 body: ${{ steps.changelog.outputs.CHANGELOG }}
 target_commitish: ${{ steps.auto-commit-action.outputs.commit_hash }}

I'm quite happy with the result, which you can check out completely in this file.

If your software has low packaging, distribution, and scaling costs, you’ll have a hard time building a source of revenue for the project—at least with an open-source license. Examples of those are CLIs or client-side desktop or mobile apps. Anyone can easily repackage your app and CLI and throw resources that you might not have into monetizing it. We’ve seen many examples of this, from storage solutions like MongoDB to Tuist itself. It’s such a known thing that it’s gotten a name—being “Jeff’ed”—which comes from the idea of Jeff Bezos packaging your software and selling it as part of their cloud offering. I said earlier that this is a model that happens when the cost of scaling is low, but if you are an Amazon, that’s not really a problem because you have a large pool of resources to figure out scaling. They might be able to offer a better and cheaper solution, and there’s no way you can compete with them. Tuist was close to being Jeffed. Thanks to that, we learned an important lesson: companies can embrace this model without feeling any need to support the underlying pieces of technology. If this had happened at a different moment in the lifecycle of Tuist, we wouldn’t have minded, but at the time this happened, we were very limited in resources, which is something we were open to them about, and the additional bump in support and feature load would have put us at risk of burnout. So we had to put a pause on our idea of everything being open source.

There are some models to prevent this. Some embrace what’s called source available. They choose a license that’s not approved as an open source license by the Open Source Initiative, like Functional Source License or Fair Source. The code is available in those cases, but the license limits what companies and developers can do with it, usually putting the focus on financially protecting the project. For example, Tart limits the users that can use the license. I personally like the balance that this model achieves because small companies or indie developers can use it in their projects, but if they grow, which usually means they have financial resources to support the project, they can pay for another license. It’s called dual licensing. There’s one caveat to this model: you might get fewer contributions because you have to require developers to sign a contribution license agreement to own the rights of their contributions to be able to provide a dual license for that code. Those same rights can be used to even close the source code, change the license down the road, or sell those rights to another company. When using an open-source license and no CLA, in scenarios like those, the community has the freedom to fork the project and continue its development in a different direction and most likely under a different name. For example, when Terraform changed their license, limiting the freedom of the software, a bunch of companies with the support of the Linux Foundation forked the project under the name OpenTofu.

Soon after being close to being Jeff’ed, we learned through the creator of Docker, Solomon Hykes, about the importance of trademarks. He mentioned in a podcast that we developers tend to put a strong focus on the license and forget about trademarks, despite this one playing a crucial role in situations like the one described above. When someone builds a project, there’s value in the code, but also in the brand that emerges and the community around it. Terraform and OpenTofu have a point in time in common, but the brand of the former might have more value and support, which the latter does not. That’s why when forks happen, they either happen with enough support from a big portion of the community and companies, or you are prone to have a difficult time promoting it. Imagine if AWS had to sell Redis under a different name. Do you think people will be more inclined to get it from there vs from the organization that created it? A brand is something that takes many years to build, and shortcuts with money don’t usually yield good results, especially if the people that you build for are developers.

We have a trademark now in Europe and the US, but we didn’t have one back then, so a company took the freedom to fork the tool and use the brand to market an integration from their service. An open conversation with them about our concerns went nowhere, so the question of whether trademark guidelines would have nudged this in a different direction remains. I have high doubts we’d have reached an agreement, but at least we could have pushed to stop using the Tuist name under their umbrella of services. In hindsight, I think close-sourcing part of the code was the right move. That was not an easy decision emotionally, but we felt it was the right thing to do, and I’m proud of the job we’ve done to navigate that and think about a future where we can go back to everything being open source.

There are open source projects that fit the above model and remain with a permissive license and in some cases no trademark. In those cases, maintainers have a full-time job at a company and treat working on open-source as a gift for a community that they do in their free time. I respect that model and admire maintainers that are able to do it sustainably, especially if the project is successful, because the maintainer’s limited attention and time are impossible to scale. Hence why there are many cases of burnout. And at the end of the day, the project itself also suffers because they tend to stagnate, often with the hope of not increasing more the load of requests the maintainers receive. Tools like Fastlane, Mise, or many Swift Packages fit into that model.

There are companies like 37Signals that open source some of the tools that they develop internally to support the development of products that are not related to the tools they are open sourcing. For example, Ruby on Rails or the many utilities that the company open sources. I like this model. That open source is often a gift and is published with no strings attached. It’s a bit like we are doing well, and we are contributing some of our work to some commons for others to build businesses upon. However, the closed-source products miss the opportunity of bringing diversity of external contributions. I think it’s beautiful, but the more I familiarize myself with sustainability models, the more I realize that it might not be possible with all kinds of products. I’ll expand on this later on.

A different model, which is the one we are starting to embrace, is providing value from the server side. Because it comes with some costs and complexity of hosting and keeping up with the software updates, some companies will be inclined to pay, especially if the complexity of maintaining the service running is significant. An example of that is Cal.com. Most people will pay for their hosted version because they are not developers and most likely don’t know how to self-host. The ones that do know, and that’s ok. You might think that they are not contributing back, or at least financially, but there’s a chance that they do so through code. They sometimes also become evangelists of your software, which is an excellent marketing tool. Some projects extend this model with some features that are released under a paid license. Those are usually the ones that large enterprises need. They also do dual licensing for companies that have strict policies against copyleft licenses like AGPL3.0. However, do note that hosting AGPL3.0 software on your server is entirely compliant with the license. An Amazon could still take a service, host it, and sell it, but without owning a trademark, that’s a very unlikely thing to happen because they’d need to make a huge effort to understand software that they are not maintainers of and market it under a different name.

The challenge with the above model is that if your market is small, and it’s mostly developers, then you can find many companies, especially the ones outside of the US, that are willing to take the little risk of hosting AGPL3.0 software on their servers, and some are willing to go even further and self-host the pieces that are under a different license. At the end of the day, it’s impossible for you as the creator of the software to know if something like that is happening, and even if you knew, would you go the legal path against a small random company somewhere in the world? Cal.com can afford this because their market is huge, but ours is small still, so doing something like that will slow down reaching financial viability and be detrimental to the product. There are products like Supabase that can afford that, even if they haven’t captured a big chunk of the market yet because their value of the software lies also in the complexity of scaling a database. In our case, the value at the moment is mostly on the client, so until we have more value on the server and some complexities or enterprise features that make the product compelling to pay for, I doubt we’ll make the server open source. We believe we can get there, but it’s a matter of time to do that shift in value. What we know for sure is that we are not going to introduce complexity for the sake of making paying for Tuist compelling. For instance, once we step into the continuous integration space with Tuist Workflow, that might change the story. We could become the first CI service for app developers that’s open source, and the complexities associated to that are worth having company dealing with them. Note though that there are projects like YunoHost or Cloudron that make the installation of services like GitLab, that are in theory complex to run and update, a one-click action, so I believe having a few features for large enterprises under a different license will be key too.

We discarded other models like Pointfree’s of selling courses. We’ve learned a lot about Xcode and Xcode projects and that’s certainly a sellable thing, but we find joy in building a useful platform, so we went this path instead. Along the journey we’ve been open-sourcing, and we’ll continue to do so, MIT-licensed gifts to lift innovation at a layer above the layers that are common across similar businesses out there so that we don’t waste time building proprietary technologies in silos.

We see in 5 years an open-source Vercel or an Expo that bets on standards to support teams in the journey of turning an idea into something that they can share with people (not users). It’s a matter of shifting value to the server and expanding the market that we can open source everything. Can’t wait!

Everything feels urgent: that message on my WhatsApp, the email I just received, or those RSS updates I need to go through. If everything competes to be urgent, what is truly urgent?

I sometimes feel as if a concurrent world of urgencies were competing for my parallel mental processing. For non-tech-savvy people, concurrency and parallelism are not the same thing. I jump from one thing to another, considering everything urgent, and ending up exhausted at the end of the day. I think it's normal, considering those jumps are sometimes between non-related domains.

I did not realize my tendency to consider many things urgent and my consequential mental exhaustion. I've been thinking about it for some time, but with the building of the company, I'm noticing I have to get better at identifying where the urgency lays, if any, and how to deal with it.

Suppose you wonder how it manifests. I can have the mail application closed, but it feels uncomfortable because I do so with the feeling that something urgent might come up. Or some message shows up from a person seeking support, and I feel like stopping what I'm doing to provide help. Or I have some spare time, filling it with checking social channels just in case something worth my attention is happening. Is it an addiction? Maybe? It's as if my brain was constantly alert, waiting for the next urgent thing. It's exhausting.

Brains are damn difficult to understand.

And to make matters worse, I'm terrible at establishing systems or processes. My brain is a bit chaotic, and I think some of my creativity is rooted in that chaos. In the connections that emerge from there. However, the mix is dangerous if you combine that with the constant feeling of urgency.

So, despite how comfortable it might feel, I'll try to establish some system, both at work and at the personal level. First, I'll treat the stream of things as a queue, where the focus is not on the urgency (or the importance) of something but on whether it is well-categorized. Then, I'll devote the last 30 minutes to review, assign urgency and importance, and plan my next day based on that. This one step is the one I need to build a routine around.

If something comes up during the day, I'll resist jumping into it and instead add it to the queue. Then, review it at the end of the day and repeat the process. And I'll establish a boundary between work and personal life:

• Work: Slack, GitHub, Desktop Mail - Personal: Telegram, WhatsApp, iPhone Mail, In-person

I used to have work things on my phone, but that blurred the line between work and personal life in a way that was not healthy for me or the company.

Will this work? It will if I commit to building the habit and stick to it. Whether I'll be able to commit is a whole different story, but let's talk about that in a future blog post.

If you are going through some mental struggles or learning about mental health and want to chat, I'm always up for it. Just reach out.

As newspapers developed, they took the role that centuries before letters. Letters served as a tool between royal courts and the distant parts of their kingdom to send information to be acted upon (e.g., grain shortage). Newspapers took this role and expanded it to the general public. When reaching someone's doorstep in the morning, much of this information was liable to feel urgent and alarming. This led to a paradoxical state of mind in modern democratic states: one is at once extremely well-informed, deeply exercised–and completely powerless.

The sense of urgency and alarm that newspapers brought to the general public and the need to feel informed and up-to-date with the latest news became the perfect channel between governments and the public to share their views and influence public opinion. The public expected them to be impartial and objective–an accountability tool for the government. However, as history has proven in many countries, like Spain, they can be easily manipulated, leading to societies losing trust in both the media and the government. But what's the solution?

We see similar patterns when we look at the tech industry, which is the result of technology embedded in capitalism. Through stories, we've been told about aspirations where technology will save us from our problems or make our lives easier. It became the modern newspaper that also made us well-connected and informed, yet with the same powerlessness. We were convinced that every problem should be solved with technology and were forced to trust the people behind it to make the right decisions. We put our privacy aside (except for the Germans), and we gave them our data to make our lives easier. We put all our photos and documents in unlimited cloud storage. We traded our free time in our pursuit of feeding the algorithms with reactions or content. Being a content creator was the new cool thing.

And we ended up in the same situation as with newspapers. Sooner or later, they can't hide the power structures and the real interests behind them. The interest of a few people who want to become wealthier and more powerful at any cost, whether they are politicians or techno optimists (e/acc). They can go as far as postponing sustainability plans, laying off workers to increase market value, using slave labor to fine-tune their AI models, building the largest pyramid scheme in history, or laying out an echo chamber that leads to civil wars.

I don't know about you, but I have low trust in many technology organizations and leaders, such as newspapers and politicians. The loss of trust grew as I gained perspective on the industry after Shopify's move after some of my colleagues started to form a union. When I looked around, I noticed the number of proprietary technologies, hyper-growth companies, the lack of transparency in the industry, and the ongoing re-shaping of the story to keep us engaged, from the metaverse to the AI through the blockchain. Connected to the Internet, but more exhausted than ever. Something is terribly wrong. I want a technology that's closer to how Aaron Swartz envisioned it. We need to stop this.

We might feel powerless in front of these giants. But I strongly believe there's one tool that can help steer the ship in the right direction: openness. When a government or a business is open about its decisions and actions and builds solutions that are also open in nature, we can build trust through transparency and not through the words of a PR department or a newspaper. We'd still rely on them telling the truth, but we'd tear down the walls to make them accountable for their actions. We wouldn't rely on institutions realizing that damage is serious and worth reporting. If Meta had shaped their systems in the open, a public debate would have surfaced that what they were doing would have caused a lot of harm. They could have connected us without making us more individualist, polarized, and addicted. Who knows, maybe Twitter wouldn't be the shitshow it is today, where a clown does whatever he wants.

Moreover, openness has the power to attract communities of people to build wonderful technology. Look at Linux, Wodpress, Wikipedia, Ghost, Plausible, Codeberg. Suddenly Microsoft, and many others are interested in open-source, yet do little to support the most critical pieces of today's infrastructure. There's something beautiful in the idea of a community of people building something together, where everyone can contribute and benefit from it. That's why Marek and I don't believe Tuist is a traditional company. We want it to be an open and calm company with a community of people who share the same values and want to build something great together.

I made openness and the usage of standards requirements when choosing the tools I use these days. I still have a long way to go, but I'm happy with the progress I've made. I can right away recognize which tools I'd rather stay away from. For example, you won't see me something like Notion. Or I'm migrating from Figma to Penpot.

I gave governments and technologies my trust, and they failed me. It's my turn to take it back and put it in the hands of the people who deserve it. I believe healthier, long-lasting, and human technology is possible if we embrace openness, both as a consumer and as a producer. And I'm going to do my best to make it happen.

I'm excited about it because it addresses an issue that has remained unaddressed for many years and that motivated many people to adopt Tuist or SPM as a project manager. However, I wonder if adding more dynamically-resolved features, like the resolution of packages,

Whether that'll lead to the best developer experience is something we'll see down the road, but that's not the point of this blog post.

If you wonder what the changes mean at the .pbxproj file level, a format I got very familiar with thanks to my work on Tuist, here's an overview of what I learned today. Groups can now have a child of type PBXFileSystemSynchronizedRootGroup. They reference a folder whose files will be automatically synced and tied to a target. For example, there are a bunch of Swift source files. In the example below, that folder is Frameworks, relative to the parent containing this group:

/* Begin PBXFileSystemSynchronizedRootGroup section */
		6C14E0CA2C4BC30C00635BF3 /* Framework */ = {
 isa = PBXFileSystemSynchronizedRootGroup; 
 exceptions = (6C14E0E62C4BC38800635BF3 /* PBXFileSystemSynchronizedBuildFileExceptionSet */, ); 
 explicitFileTypes = {}; 
 explicitFolders = (); 
 path = Framework; 
 sourceTree = ""; 
 };
/* End PBXFileSystemSynchronizedRootGroup section */

The glue between that object and the targets happens in the new fileSystemSynchronizedGroups property of the PBXTarget object.

Then Apple also introduced another object, PBXFileSystemSynchronizedBuildFileExceptionSet, which is used to provide "exceptions." Those exceptions are used for three things, and maybe others that I'm yet to uncover:

• Filtering out certain files and folders. - Overriding the default file type. - Configuring the type visibility.

Those are the only two models that are needed to enable this functionality. Once we land this feature in XcoeProj, I'll explore what the API could look like in Tuist for users who want to opt into it, although the value is not that significative in this case since git conflicts are not that much of an issue in Tuist land.

The specified item could not be found in the keychain

It turns out that even when passing the keychain with flags like --keychain, if the keychain is not made the default one, it fails. Therefore, I ended up making it the default:

security create-keychain -p $KEYCHAIN_PASSWORD $TMP_KEYCHAIN_PATH
security default-keychain -s $TMP_KEYCHAIN_PATH
security import $CERTIFICATE_PATH -P $CERTIFICATE_PASSWORD -A

So, this blog post is a note for my future self because I'm sure I'll come across this again. Or perhaps for anyone coming across the same issue.

Humans love stories. Stories bring us together. Capitalism, democracy, and religion are all stories that we tell ourselves. We need stories to identify ourselves with, and developer tools are no exception.

But what's Tuist story you might wonder? At first, Tuist was a solution to a problem: Xcode projects are hard to maintain. We didn't have a story back then, but organizations felt so much pain working with Xcode, that the pain led to the adoption of Tuist. And we kept adding on top of that, so as you can imagine, the story was not clear. What is Tuist? A project generator? A project generator and a Fastlane? A CLI for automation? A tool to optimize the development experience?

When there's no story, or the story is not clear, people don't know how to identify themselves with the product. Note that I prefer to talk about people and not users because the term users dehumanizes the relationship between the product and the people using it.

So for the past few months, I've been thinking about what the story of Tuist should be, and I'm starting to see it. The common denominator of all the features we've been adding is that we want to make developers happier and more productive. We believe this leads to better apps. We also believe there's a possibility to take this to other platforms, but as of today, that feels more like a new chapter in the story.

But "happiness" and "productivity" feel too abstract. I'm already happy with my Xcode project. I don't need you. It's very natural to feel that way. Hence why we are presenting it as something developers are familiar with. We aim to become a virtual platform team. Or like the AI jargon likes to say: a copilot.

But that's not enough. By talking about platform teams, developers might have a vague idea of the role that Tuist plays, but how do you present the features? Are you going to say that you are just providing tools X, Y, and Z where X, Y, and Z are just some random marketing names that you came up with but that mean nothing to the developer? That doesn't sound like a good idea.

It's already an effort for developers to understand what a virtual platform team means, so we shouldn't add to that. Therefore, we are going to build on stories and mental models that developers are already familiar with. We are going to use the same terminology that developers use, and place them in various phases of the app development lifecycle: start, build, share, and measure.

You don't need to explain what those are. Every developer, even non-Apple developers should be familiar with them. Tuist is just integrating into mental models to increase the level of happiness and productivity.

So we are currently in the process of iterating in the story or coming up with one since I wouldn't say we had a well-defined one before. And going forward, we are going to make sure we treat it as a dynamic organism that evolves with the product and the people using it. I'm very excited about this new chapter, and all the possibilities that it opens up.

Similarly, Tailwind enabled the portability of styled components. And developers loved that. So much, so that it’s rare to see a UI tool kit or design system that’s not built on Tailwind. Developers prefer to learn the semantics of an abstraction, instead of the semantics of the underlying standard. It’s bizarre when you think of it, but portability is key, and it’s becoming even more apparent with all those AI tools that generate a website for you.

The problem with it is that if your stack is not JS, you feel left out. Developers find themselves having to decide between having access to that ecosystem of paradigms and reusable component kits at the cost of adding a JavaScript runtime to their stack, or not adding any JavaScript runtime and having limited access to resources and DX. Many end up leading on the former, which often also means building an SPA, and you know all the implications that come with it. The cost is high.

For some time I've been thinking about whether JavaScript is required to enable that experience, or if it was more of an accidental implementation detail because React started with a focus on the client (browser) where a JavaScript runtime is available by default. The more I thought about it, the more it became clear that it's very likely an accidental implementation detail. At the end of the day, those technologies are functions from components and data to HTML, CSS, and JS (or Wasm). So why not have the compiler in let's say Rust, with bindings for the many languages and runtimes with popular web frameworks like Ruby, Python, and Elixir? I believe pushing the solution one level down and making it runtime-agnostic would suddenly decide on technology more of a language preference than anything else.

Such a solution could come with a registry to share components. Imagine a design agency bundling a design system and distributing it to you to consume regardless of your technology stack. We'd save all those organizations an insane amount of time and money having to port their solutions to the multiple technologies they support. It'd become the missing narrow-waist in how people build UI for the web. Or imagine something like Storybook too. It'd unlock a whole new world of possibilities and perhaps a new type of discipline: UI developers, which would feel comfortable writing components and iterating on them without the distractions and complexities of a full-stack application.

Where am I going with this? I don't know, but I want to tinker a bit with the idea in my spare time and see how far can go. It's also an excuse to write a bit of Rust :).

Happy Saturday.

It’s impossible to live these days without the ongoing feeling of falling behind:

• News you have to read. - Podcasts that you have to listen to. - Recommended restaurants to try. - X posts to catch up with. - Emails and Slack messages to read. - GitHub notifications to go through. - Travel experiences to experience. - Technologies to catch up with. - Workouts to do. - Kilos to lose to match the stereotypes. - WhatsApp audio messages to listen.

I feel the world around me has got so hectic so quickly, that my brain hasn’t been able to scale. In fact, I don’t think it should. Trying to scale puts me in the perfect mode that capitalism likes: over-consumerism. But what about our mental exhaustion? That’s something only the person suffering cares about.

These days I feel a lot like falling behind, like jumping from one thing to another until I go to sleep. Everything ends up being irritating as a consequence.

And this is a mode I don’t like. I’m aware I don’t like to go through my days that way, nor that is something healthy, but somehow I find it hard to escape. When I manage to ignore all of that and put the focus on myself, which for instance happens a lot when I’m flying, then I have the most mental relief and joy. It’s a forced disconnection that I wish I could force myself at any time without having to step on a plane. It’s a gift being able to do that in a so connected world.

So I’m figuring my way out, but I don’t have the formula yet. I’ll try to go through the pain of reverting some mental patterns that are the consequence of many years of mindlessly embracing a lifestyle that has proven not to be healthy at all. Hopefully, I’ll get through it and restore some mental sanity.

When you are open, you are more broadly accountable for your work, and your craft is at stake, so people show the best version of themselves.

When you are open, people can build trust through your work and not through third-party auditing companies and certificates. If you had anything to hide, you wouldn't open it.

When you are open, you can invite external people to contribute, which means a diversity of ideas flowing into the project, which leads to better solutions.

When you are open, anyone can find the information they need to have the agency to make decisions. The organization is more agile.

When you are open, people might end up using your work without paying for it, not worrying about complying with it legally, but those who wouldn't have paid for the software in the first place become evangelists instead.

When you are open, you inspire others to create more open businesses on commodities you might have created.

When you are open, you might make some people uncomfortable, but they decide to go a different path.

We chose This one for Tuist because we want to build a different type of company—openness for the win.

This is something that I used to have years ago, but that I lost when I was embedded in a working culture of making great decisions fast with tight deadlines and a very competitive environment. When something spans several days, weeks, or months, I feel like I'm not making progress. Part of me thinks that those are steps in the right direction, but the other part of me feels like I'm not moving fast enough. And because we are limited in resources, I wonder if we are making the right decisions. Suddenly I'm flooded with doubts and fears.

When I look around, I see companies in a similar space that are moving fast, raising money, and hiring people, part of me feels like we are falling behind. However, if I look closely, all I see are attempts to run sprints one after the other, fear of being open and transparent about their business, obsession with growth at all costs, complex pricing models to squeeze as much money as possible from customers...

We are running a marathon, and that takes time. And I need to get comfortable with that regaining the patience and perseverance that I once had.

And when I calm down, I notice I can show the best version of myself. I'm inspired to help, to bet on unique ideas, to be open and transparent, and to build a company that I'm proud of. It'll just take a bit of emotional work to get there. But I'm confident that we'll get there.

Developers often say that the technology doesn’t matter, that if you prove a solution solves a problem, you can always rewrite it. But Tuist was already a validated idea, and we had just learned about how nicely Elixir can help achieve and scale so much with a simple stack and very few resources. It felt uncomfortable at first because we were not entirely familiar with the syntax, but more and more we are realizing it was such a great decision.

The most recent reaffirmation happened when we tried to add telemetry to the instance for on-premise organizations. Erlang provides a standard telemetry API that many packages use to report telemetry information, including packages like Phoenix (the web framework) and Ecto (an ORM to access databases). Without a single line of code, we had all that information available, and with just a few lines, we had it converted and served to Prometheus via a /metrics endpoint. Mind-blowing.

Phoenix LiveView was another reaffirmation that took us some time to appreciate as we familiarized ourselves with the technology. It’s common to see many companies bet on React as a way to have a top-notch experience for building UIs, without realizing the pile of complexity and abstractions that becomes their technical debt forever. With LiveView, you get the former without the latter. You barely need to write JavaScript and can declare UI that’s a representation of state entirely in Elixir.

So in our particular case, technology does matter, and it matters a lot. And that’s without even mentioning anything about the concurrent model and the many data races that don’t happen because of it, saving us time we’d otherwise waste on debugging.

If you are building a web service and can afford to learn a new technology, Elixir is a great resource to have in your toolbox.

Open Source as a Foundation, Not Just a Marketing Tool

Unlike many companies in our space that treat open source merely as a marketing tool, we view it as the foundation for building better tools. We believe that openness and diverse contributions are crucial for long-term success and inspiring others to create their own open-source solutions and businesses. We plan to open-source our entire business, including the server implementation, following in the footsteps of successful open-source companies like Ghost, GitLab, Posthog, and Penpot. We’re committed to commoditizing many of our technologies with permissive licenses, as evidenced by our work on extracting Xcode project generation logic into a Tuist-agnostic package. Stay tuned for two new open-source projects we’ll be announcing in the coming months!

Embracing Standards for Long-Term Sustainability

We’re betting on widely-adopted standards when choosing technologies, formats, and designing our product. This approach aligns with our goal of building a long-term solution that can withstand the test of time. We aim to avoid the pitfalls of constantly refactoring due to rapidly changing frameworks or vendor lock-in. For example, our web setup uses raw HTML, CSS, and JS, intentionally sidestepping the complexities of the JavaScript ecosystem.

Openness Beyond Software

Our commitment to openness extends beyond our code. We’ll be transparent about our pricing (with the exception of custom on-premise solutions), drawing inspiration from Posthog’s model. Additionally, we’ll maintain an open handbook documenting our company’s operations. This transparency will help potential clients make informed decisions and support our goal of building an asynchronous remote company by fostering a culture of comprehensive documentation.

Simplifying the Developer Experience

We believe that teams shouldn’t have to rely on complex scripting to glue tools and services together by default. Tuist will continue to help teams streamline their setups, advocating for simpler, more integrated solutions. Our goal is to provide a single, cohesive tool with multiple well-integrated features, rather than a collection of independently negotiated tools that prioritize profit over user experience. We put people first, and unnecessary complexity is not part of our equation.

Challenging Convention and Fostering Innovation

We’re leveraging our culture of innovation to challenge cargo-culted solutions and move the ecosystem forward. In the coming months, I’ll be sharing more ideas on how we plan to approach common problems in novel ways.

Building Tuist is like working with a blank canvas, allowing us to create the company we envision based on our values. We’re not simply copying what’s been done before, but rather reflecting deeply on what we want to achieve. Our goal is to build a unique company that embraces open source without fear.

This is a need that we sometimes have when working on any of the Tuist repositories, and I found it a bit annoying having to note them down in issues that can get lost over time. The need for introducing a breaking change, and the rationale behind it, needs to be part of the Git history of the repository, close to the changes that prompted the developers to consider it. Therefore, I decided to introduce a new convention across Tuist repositories: a BREAKME.md file.

As its name suggests, it contains a list of breaking changes that we would like to introduce in the future. Every change should include what needs to be changed, and the rationale behind it. When working on future releases, developers can refer to this file to understand the breaking changes that we have been considering.

With that file, I feel more comfortable proposing breaking changes, since I know that they won't get lost in the noise of issues and pull requests.

Still, Swift and its approach to concurrency was not meant to be the subject of this post. I wanted to talk about concurrency in parallelism in programming languages, and how to achieve those without compromising the ergonomy of the language and the complexity of the programs.

There are interpreted programming languages like Ruby or JavaScript that can run IO-bound operations concurrently but require introducing complexity to do things in parallel. That's why they are very suitable languages to validate business ideas, but are costly to scale after validation. Costly not only in terms of complexity but also in engineering time and production infrastructure. Programs also get harder to reason about and maintain, because parallelism is often achieved through the persistence of a state and pool of processes that subscribe to state changes and run tasks in parallel. If that's a model you are happy with, then you are good to go. However, it's not mine.

Then there are programming languages that have built-in primitives to run tasks in parallel. Programming languages like Swift, Java, or Zig. But they all share one thing in common. They put the burden on developers to prevent data race issues. As a developer, that's not something I'd like to think about. Apple is well aware of this and is trying to move to a model where the compiler can help developers prevent that. But sadly, and as mentioned earlier, it does so by compromising the ergonomy of the language to hint the compiler about the intention of the developer.

An interesting programming language in the above group is Rust, which prevents data races with a new approach to memory management. However, there's a bit of a learning curve associated with it and is a cost that many want to avoid, especially if they are just getting started and want to validate the business idea. An approach that one could take is starting with something like Ruby and JavaScript and doing a rewrite later on if the business proves to be successful. But who wants to go through that pain? Another question that I ask myself often is, why would you adopt a programming language that, even providing parallelism, can't catch data races potentially causing production servers to blow up?

Functional programming languages can solve the above issue by not sharing mutable states. But like Rust, many functional programming languages, especially the ones that are pure, have a learning curve that many want to avoid. I've seen the DX of Clojure, and it's mind-blowing to experience, but it's a whole different approach to building, debugging, and testing software. Is it worth it? What's clear though is that there's something unique in the functional programming paradigm that we can't ignore. When the state is mutated as it's passed around, data race problems are gone and you can take full advantage of the hardware where the software is running. Your production servers and development scales by throwing more CPU cores and memory. Does your test suite take a long time to execute? Increase its parallelism. And the best part? You can do that without being worried about flakiness levels increasing. It's beautiful.

The best of all is that there's a programming language that blends the best of both worlds: Elixir. From Ruby and JavaScript, it draws the high-level abstractions and the ease of use. It's also hot-reloadable, which at the end of the day is a productivity booster (this is achieved through the Erlang VM). From Rust, Java, and Swift, it draws the ability to run tasks in parallel without worrying about data races. It just doesn't happen because there's no shared mutable state. Logic is encapsulated in processes that communicate passing copies of the state. It's amazing. It's the most productive and amazing stack I've ever worked with. Zero complexity. Full parallelism. So yeah, if you are looking for a programming language that can scale with your business idea, I'd recommend Elixir.

This is a non-sponsored post. It's a love letter to Elixir.

With many developers on Mastodon and X talking about WWDC, I can't avoid but think: Should I watch some of the talks? Part of me thinks that I should because I might get ideas for problems to solve with Tuist. But the other part of me thinks that the ideas presented in it, and which I've seen people talking about on various social networks, are enough for me to envision the problems that I could solve with Tuist. When the time to work with them comes, for example enabling complete strict Swift concurrency in Tuist, I can simply look up the documentation and learn what I need to know. I feel it's a more effective way of learning because it's goal-oriented. I decided to call it lazy-learning.

So I'll try to apply this approach going forward. I'm currently diving into Apple's Virtualization Framework, Swift Testing, and how to flip a German company to the US, because these are the problems I'm facing right now.

And you? What's your approach to learning?

The design principle that I followed was to make it as simple as possible. I used the same font-size and font throughout the website and played with the font-weight and gap to create a visual hierarchy. I'm quite happy with the result.

I took the opportunity to add new pages. I added a feed page to surface my posts from Mastodon, and photos to do the same with my Pixelfed posts. Since those pages are rendered on the server, I fetch the data from the respective APIs and populate the pages with it. I also added a now page that I plan to keep up to date with the latest ideas, thoughts, and things I'm interested in.

After having done this work, I'm quite excited about using the web platform in its rawest form. No TailwindCSS, no static site generators, #nobuild setup.

Don't people say that solving a problem starts with acknowledging it? I feel I'm going through that phase. I'm trying to demand less from myself.

Less perfection. Less pressure. Less being online. Less you need to succeed. Less pleasing everyone but myself. Less work taking all my mental space.

I guess this is part of the journey of life. Learning about ourselves and our mental health. The largest disregarded part of our health.

I'll prioritize the things that feel great in my brain. Running feels great on me. It's my meditation. It's the fresh air. At which moment did I deprioritize it?

How do you deal with emotional breakdowns?

In simple words, the problem is that the linker overoptimizes the binary removing symbols that are needed at runtime. The linker's dead-stripping logic can't delete dynamically referenced symbols. And this is something that happens not only when referencing Objective-C symbols, but Swift too. For example, when integrating Composable Architecture, when integrating it with Tuist via Xcode targets, developers might need to add explicit references to those symbols or the flags above to the build settings.

What's the solution? There are a few options:

• The package maintainer can add static references to those symbols to prevent the dead-stripping logic from removing them (e.g., Promises, IGListKit) - You set the -force_load or -ObjC flag in the OTHER_LDFLAGS build setting of the target that links those packages statically. Note that this has some effects, like potentially increasing the binary size. - You turn those dependencies into dynamic targets, which as a caveat might end up increasing the launch time of your app.

This is a bit unfortunate because it requires developers to go a bit deeper in understanding their dependencies , but hopefully this write-up helps you understand the problem and the potential solutions.

As you might know, we migrated Tuist's server implementation from Ruby to Elixir. Whenever we brought this up, it was common to hear developers saying that it sounded unnecessary. Almost as if we didn't care about the problem space and we were distracted by the technology. But the reality is quite the opposite.

Many organizations bootstrapping businesses treat their initial work as a disposable prototype. If it works, they'll rewrite it with a more robust technology. But Tuist is a validated product and foundation that needs to be as future-proof as possible. And it's bootstrapped, which means we don't have the luxury of throwing extra money at problems or paying for services that abstract complexity away. And that's where Elixir shines.

So our approach to building a future-proof platform for App productivity builds on the following principles:

• Embrace simplicity - Embrace the platform - Embrace standards

Erlang's programming model enhanced by Elixir's language is what we'd describe as a simple yet powerful technology that scales well. Dot. It's been three decades since Erlang was created to solve telecommunication challenges that resemble the ones that we face today with Internet companies and that we are trying to solve with endless layers of abstractions. Will we have access to less resources and talent than other technologies? Very likely, but the few that we'll have access to will last longer compared to ecosystems like JavaScript, which are in constant flux.

Note that abstracted complexity is still complexity. It's just deferred complexity. Down the road, you'll have to deal with it yourself, either by throwing expensive resources at it (e.g., engineers), or paying for services that abstract it away while creating a vendor lock-in. This is in a nutshell the JavaScript ecosystem, which on top of it adds the disposable and fragmented nature to the layers of abstractions. How fun is that?

Then there are the platforms that we build upon, Apple's platforms and the web. They might not be perfect, but they are the most stable and future-proof platforms that we have access to. We are intentionally avoiding abstracting them. For example, we don't use build tools on the Tuist web app. Instead, let the browser load CSS and JS files. We love and believe in CSS. Our Swift codebase doesn't use any convoluted architecture or code patterns. It's just classes and structs (and soon actors) that pass data around trying to follow good programming practices. Is it perfect? No. But anyone can jump in and look around without having to learn abstractions. It's priceless in open-source, which we expect to embrace end-to-end.

And last but not least, we are embracing standards over proprietary formats. Many companies these days have incentives to create proprietary formats that lock users in. We bet on platforms that bet on standards. For example, our cloud provider, Fly, uses Docker containers as a deployment format, a runtime-agnostic solution, Flame for elastic auto-scaling of applications, or Grafana for data visualization. Standard is something we are going to embrace too when designing the Tuist product, drawing a lot of inspiration from Fly, which is a company that we admire.

We are in the early days of building a productivity platform for app developers, but we believe that by embracing simplicity, the platform, and standards, we'll build a future-proof platform that will last for decades.

Ecosystems traditionally have their default or broadly adopted build systems. Android has Gradle, the JavaScript ecosystem has Vite (among many others), and the Swift ecosystem has Xcode's build system. They might not be as advanced as Bazel, but over the years, they defined building blocks, mental models, and extensibility APIs upon which ecosystems have been built. Vite is a great example of the latter. Extending the build system is as easy as adding a plugin, usually distributed as an NPM package, and adding one line to the configuration file.

When you use Bazel, you are trading off not only the ecosystem of tools, but very likely a lot of ideas, patterns, and resources from the community. This is a big deal that can't be underestimated. If the community innovates in a particular direction, you might not be able to leverage that innovation because you are using a different build system. Oftentimes, you have to port those ideas over to Bazel yourself or wait for someone to do it for you. In an ideal world, everyone uses Bazel, and everyone innovates on the same foundation, but how likely is that to happen? Very unlikely I'd say. I believe this explains why many organizations remain hesitant to adopt Bazel. Put differently, the few that adopt it, are because they adopt it across the board and therefore the cost is more justified.

My stance, and also Tuist's stance, is that we embrace the limitations of existing build systems, and try to innovate within those constraints. By doing so, we don't disrupt organizations' workflows, and they are still able to leverage the community's innovations. Moreover, we also meet developers where they are by embracing elements that are familiar to them. For example, we purposely chose Swift over something like Starlark to describe projects. It might seem like a subtle thing, but it's not. Developers love using Swift and Xcode, so why not leverage that? We also reused the same concepts that Xcode uses: schemes, targets, build settings... Why push a new language onto them if the existing one works? When you combine all these elements, then organizations find a tool that's a joy to use. Sure, it won't reach the level of sophistication of a build system like Bazel, which has been battle-tested by Google and many other companies across various tech stacks, but it provides organizations with the right trade-offs.

I strongly believe that problems should not only be looked at from a technical perspective. Ecosystems have opinions, trends, and communities, that can either be embraced and integrated with, or ignored. Doing the latter often leads to a tool that's technically superior but people don't want to use.

If you asked many citizens to contribute financially to the construction of a park where they’ll be able to relax and bring their kids to play, most will refuse, saying that they expect those things to be free. Now imagine the same thing but with digital infrastructure that many can’t see and on which many for-profit organizations build. Why would they pay if, by doing so, they’d increase their costs? They’d rather not. Not only that, but they take part in echoing misleading ideas such as GPL licenses, like considering them infectious. Why not say my software is incompatible with this license instead? Infectiousness places the blame on the open source software. Would you consider someone infectious because their need to receive a salary for the service they provide as an employee is incompatible with the company’s cost structure? Most likely not. So why do we do that to people who have contributed hours to develop something and therefore have the right to publish it under a license of their choice?

As I mentioned in past blog posts, the backlash from developers often arises when you have to make some changes in a model to protect the project’s sustainability, like we had to do with Tuist. But it was so hard for us to imagine how much work Tuist would require 7 years later, that we couldn’t have agreed on an ideal model when we started. This is not unique to open source, but companies have to go through decision-making that won’t please every user, and that’s alright.

So, going forward, the model that I’m embracing is similar to 37Signals’. I’ll layer the paid software that I build, and publish as MIT-licensed those layers that I believe would benefit from commodification and that the community might be interested in building upon and contributing to. For example, we are going to extract all the generation logic from Tuist, so anyone could build their own project generation tool upon a battle-tested logic to understand graphs and translate them to Xcode primitives.

Open source sustainability is hard, and while it’s necessary to have the tools to reward and pay contributors for their work, the problem requires more of us, developers, speaking out loud about the importance of contributing to the software that we depend on, like we do directly through our taxes to have spaces where we can live and enjoy. Software is no different there, just something more abstract.

As Adriana points out, unlike digital infrastructure, in physical infrastructure boundaries are more clear and the need for maintenance is more evident. Although it's common in societies to only realize the importance of infrastructure when it's not working. The thing is, and I feel this is something that many developers are unable to realize, that a piece of open-source software that you developed in your spare time can become the infrastructure for many companies. It's not that you set out to build infrastructure for the world, but you accidentally end up doing so.

Most companies know about this. Looking from the financial perspective, it's cost savings. This allows them to gear their resources towards other things, for example innovating at a different layer, which is fantastic. The problem is that along with most societies, which haven't yet realized the criticality of digital infrastructure, many turn a blind eye to the importance of maintaining it. The response is often in the shape of a donation, which is appreciated, but it doesn't solve the problem in most cases.

I've seen some companies emerging to solve this problem, but I'm highly skeptical about their approach. They approach the problem thinking that it's a technical one, but I believe it's a social one. Hence why I'm excited about the German government's initiative to create a sovereign tech fund to create awareness and support the maintenance of open-source projects. Sure, you can try to remind companies about the importance of maintaining the infrastructure they rely on, but "reminding them about a cost they should take care of" is not something that they want to hear.

In the case of Tuist, we had to start evolving the project into a company to ensure that we could maintain it. Our mental health was at the table, and we were running a bit out of energy trying to maintain the project in our spare time. Did everyone like the move of turning Tuist into a company? Not everyone. Some thought "I chose Tuist because it was open and free, and now there's a portion of it that is not." They felt betrayed. But we didn't know anything about what the project would become and what that would mean for us in terms of time and energy. So we decided to place our mental health and project long-term sustainability first over the interest of getting everything for free yet at the risk of the project dying.

I wish more companies and people would realize the importance of maintaining the infrastructure they rely on. But until that happens, or until governments like the German one step in to create awareness and support the maintenance of open-source projects, open-source developers like us will have to come up with creative ways to ensure that the infrastructure we build is maintained healthily.

Luckily AppSignal supports sending webhooks when anomalies are detected, but the schema of the payload and the headers didn't match what Incident.io expected. For example, Incident.io expects the requests to come with an Authorization: Bearer xxx header.

To make the integration work, we decided to use Cloudflare Workers. We created a worker that transforms the payload sent by AppSignal into the one that Incident.io expects, and adds the Authorization header. The worker is deployed to Cloudflare, and we configured AppSignal to send the webhooks to the worker's URL. Below is the code of the worker:

const token = "...."
export default {
 async fetch(request, env, ctx) {
 const alert = await request.json()
 const { alert_id, metric_name, human_comparison_value, trigger_description } = alert;
 // https://docs.appsignal.com/application/integrations/webhooks.html#exception-incidents

 await fetch("https://api.incident.io/v2/alert_events/http/....", { headers: {
 "Authorization": `Bearer ${token}`,
 "Content-Type": "application/json"
 }, method: "POST", body: JSON.stringify({
 "title": `${metric_name} peaked above ${human_comparison_value}`,
 "description": trigger_description,
 "deduplication_key": `${alert_id}`,
 "status": "firing",
 "metadata": {
 ...alert
 }
 })})
 return new Response(JSON.stringify({status: "success"}), {status: 200, headers: {"Content-Type": "application/json"}});
 },
};

Hopefully, Incident.io will provide an integration with AppSignal in the future, but until then, this solution works well for us.

• Why opt for Figma and its proprietary file format when you could use Penpot, which utilizes SVG? - Why use serverless proprietary JavaScript runtimes when you can deploy OCI images to platforms like Fly? - Why choose Tailwind for styling your website when you can achieve the same with standard CSS, which has improved significantly over the years? - Why use Notion when you can write your content in Markdown files and manage them with tools like Obsidian or Logseq? - Why bind yourself to the complexity of React when you could embrace the platform and use web components?

I understand... standards can seem dull. They often lack the flashy, modern websites that play on psychology to convince you of their worth, yet they possess a unique value. They will outlast any proprietary format. React? It will eventually lose its appeal, leading people to chase the next trend. You have the chance to decide whether this results in a burdensome migration for you or has no impact at all. Should Notion decide to change its terms of service and raise the price for accessing your content? You can choose to avoid that situation entirely.

With the current overload of noise on social channels, it's easy to mistake something's value for how frequently it's discussed. You won't find many tech influencers evangelizing Markdown because it's not deemed "cool." It's more fashionable to talk about a React-like Markdown format that blends Markdown with JSX. Unfamiliar with it? Consider introducing it to your project.

The JavaScript ecosystem undoubtedly epitomizes the realm of proprietary solutions. The absence of standards beyond the language itself has transformed the ecosystem into a Wild West. Try to name a single problem layer where solutions are standardized; you'll find none. Take runtime as an example: each attempts to introduce a proprietary set of APIs until they realize the inevitability of Node's standards, forcing them to ensure compatibility with Node's APIs so that packages in the NPM ecosystem work seamlessly. Or consider cloud runtimes that mimic Node but aren't actually Node. The code that functions locally fails in production because you're using Node locally and something different in the cloud. As a result, new layers emerge to shield developers from the myriad proprietary solutions, like Honos, which abstracts the various methods of handling HTTP request-response cycles.

There are developers who enjoy hopping from one proprietary solution to another. I don't. Perhaps it's a sign of aging or a decreasing tolerance for trends that distract from creating anything of value. However, the moment I see a company promoting something proprietary, I instantly become wary. That's why I prefer CSS over Tailwind, Fly over Vercel, Markdown over Notion, and runtimes like Erlang over Deno or Bun. The peace of mind that comes from betting on standards is invaluable, granting me the focus needed to build great tools with technology.

I noticed that I like to build with other people and leave a lasting impact on them. I have a similar personality outside of the context of open source, and I noticed that my dad is the same. I also enjoy empowering others through my work, sharing thoughts like these, or collaborating with them on exciting challenges. This might sound odd in a very capitalist world, but the peace of mind this creates is priceless. I wouldn’t change it for anything else.

The problem is that money will get in your day whether you like it or not. The most common case is when you are an open-source developer and realize that you need to do something to make a living from it. Many open source developers get a job and continue to work on open source in their free time, but this might be a huge mental stretch, especially in some life phases. That was the case when I got the job at Shopify. They met me through my work on Tuist, which received no support from the company, neither by using it internally nor allowing me to spend some time contributing to it. I was younger and emotionally more dynamic to navigate it well.

In other cases, the open source developer gives the company the unique value that companies can’t compete with, such as a community and the recognition that comes with it. So, the developer becomes an influencer for the company, on top of meeting their daily responsibilities. If you look around, you’ll find some examples of that–a developer X who built Y and works now at Z, and therefore, I want to work for Z too because X is there. I sometimes wonder if open-source developers should charge for that or be paid more because, in terms of responsibilities, they are bringing tons of value to the company. At Shopify, I hired people who came through my open-source work. Even I talked so many times publicly about the exciting stuff my teams were working on. I did it naively, not knowing how those organizations operate, and to this day, I still feel guilty and somewhat stupid for having done that. But as I said earlier, whether you like it or not, the intrinsically motivated work that builds communities sooner or later meets the extrinsic motivations of a company that wants to profit from it. I won’t get into Bitrise because I have already talked about it.

The one model, which a few try because it requires wearing a different hat, is evolving the open source model to have a commercial component associated with it. This is the approach that we are taking with Tuist Cloud. We build something on the open source foundation but to build the source of revenue necessary to maintain the open source side. My Northstar is a product developed in Spain, Penpot, an open-source alternative to Figma that embraces standards over proprietary formats with rugged portability. It’d be my dream if we could achieve that with Tuist.

This is a model that we are seeing getting popular as COSS. However, I’ve seen some of those projects taking a different approach. Rather than being intrinsically motivated by open source values and what they enable, they are extrinsically motivated by making money and embracing open source as a marketing strategy. Most of them have VC funding and have contribution license agreements (CLA) to make them owners of your contributions. So even if they pitch it as “it’s open,” which is very sexy on a landing page.

The above model doesn’t align with my principles. I’d rather have a permissive component that anyone can take and do whatever they want and a closed-source extension to ensure funding for the project. Ideally, everything is open source, but we might make things unnecessarily challenging when bootstrapping a business. Our goal with Tuist Cloud is to open-source it eventually.

Re-connecting with the things that bring me joy is bringing back the mental health that I lost by being embedded into an environment designed for competition with all sorts of psychological tricks to make you overcommit and squeeze every gram of creative energy. Not anymore. I love collaboration, building, and empowering people, and doing that makes me stay mentally healthy and happy.

I don’t like the debates around a technology’s ability to scale because, at the end of the day, any technology can scale if you throw enough money at the problem. However, since we are a small bootstrapped company, we can’t afford to throw money at a problem—we need low-cost, easy scaling of not just the production servers but also development, and Elixir and the VM (BEAM) are uniquely positioned there. Thanks to the virtual machine and the functional nature of the language, you can scale by increasing cores and memory instead of horizontally adding more servers, which comes with its part of complexity.

Someone at this point might wonder: Isn’t this easy scaling also achievable in JavaScript with serverless JavaScript runtimes? Yes and no. The provider of the serverless environments supposedly abstracts that away from you, very likely with a proprietary runtime that looks like Node but it’s not Node. But that, at the end of the day, is a loss-leading commercial strategy for you to eventually pay more than what you’d pay if you had it as a long-running process in a server. And that goes without talking about the pain points of having inconsistent runtimes across environments. A JavaScript/TypeScript developer would tell you WinterCG is here to fix all these fragmentations caused by cloud providers, but that’s just a flat illusion, like many things in the ecosystem: Serverless, Lambdas, Functions, JamStack. They are constantly trying to reinvent everything to try to sell services with significantly more costs than value. So as you can imagine, JavaScript was a no-go for us.

Swift’s production servers can scale easily and cheaply. However, development might not because of Apple’s continuous strong focus on their platforms. The ecosystem lacks many tools and workflows that can play a significant difference in productivity. One of the workflows, for instance, that we find extremely valuable these days is being able to open a remote console with the runtime and run code in it. Obviously, this is a workflow that’s not a good idea long-term, but in this current phase, it’s life-changing.

We had a bit of a moment of thinking: should we bet on Swift and help move the ecosystem forward? However, we don’t have the financial luxury of making this investment. We were afraid the decision would lead us to rabbit holes of Swift issues in Linux environments that would distract us from shipping a great product. We are not entirely opposed to using Swift on the server. We just think that right now is not the best time for it. We remain excited about what the future holds for Swift on Linux and Server.

It was also important for us to have access to an ecosystem of community packages to help us with various problems and needs we’d face. Swift was way behind here compared to ecosystems like Ruby, NodeJS, Rust, or Go, which have plenty of tools for building server apps that run on Linux servers. From that list, we also discarded Rust and Go because we’d lack hot-reloading, which is a small issue at a small scale but can become significant when reached a certain scale. We deem it important for our productivity to change code and see it automatically hot-reloaded in the runtime. Once again, the combination of functional programming in Elixir plus Erlang’s VM capabilities make that possible. It’s insanely fast.

And last, and potentially very important in the future, is having access to primitives that will allow us to build real-time features around collaboration, without having to introduce additional pieces of infrastructure. Elixir makes that extremely easy. So easy that even platforms like Supabase offer that as a service for other ecosystems. We can see some Tuist Cloud features being real-time, like seeing builds test results data flowing into a dashboard and getting automatically refreshed.

We believe this is the best decision for the project, and we can’t wait to start investing in a unified dashboard for Xcode teams.

The service has a very basic UI, which might change soon, and a REST API that the CLI interacts with. Most of the interaction with the service is done through the API because teams interact with it through the CLI. By design, we aimed at keeping an S3-compliant storage, provided by Cloudflare in this case, as the source of truth for whether a given binary exists or not. We didn't think it made sense to replicate that state in the database, and add additional synchronization logic to keep both in sync. That meant that all the requests would spend around 90% of their time waiting for IO operations to complete. To our surprise, we started seeing slow requests that timed out, and some which came back with 500s. What was going on? I started searching, and I came across this issue by @dhh. And there was a piece of his comment that grabbed my attention:

It's not a good default for apps with quick SQL queries and 3rd party calls running via jobs, which is the recommended way to make Rails applications.

3rd party calls are what we were doing (against Cloudflare's APIs), so he was clearly referring to our use case, but I couldn't wrap my head around the idea of having to use jobs for that. I mean, I don't mind adding jobs, but I'm a huge advocate of simple solutions, and that didn't feel simple. So I continued digging into how Puma works, how they use Ruby threads and system processes, and how you have to figure out the sweet-spot configuration for your service to have the latency and throughput intended. I learned that the issue that we were facing with Tuist was related to having a low number of threads, which resulted in requests having to wait a long time in the Puma queue, and eventually timing out or being rejected. I added some additional cores to the production machines, did some tweaking of processes and threads, and got it to a point where it was acceptable. But still, it didn't feel right. What are we going to do with our on-premise customers? Are we going to provide them with guidelines to figure out the right value for the production machines? Are we going to point them to lengthy guidelines around Rails and performance? It all felt wrong. Sorry Rails. You scale, but the cost of it is barely talked about.

All we want is a solution that's able to use all the resources available in the machine, without much configuration or tweaking to find the ideal values, and a runtime that's able to handle IO-bound operations efficiently. At the same time, we want to keep the productivity that Rails provides. The good news is that such technology exists, and I've already talked many times about it in the past. It's Elixir. It feels like the right tool for the job. I don't have to use jobs because a runtime's global lock is not going to be optimal for the nature of my app. We can scale the service by throwing more cores at the machine. Look at Discord, Pinterest, and Supabase, which are all powered by Elixir. Development is very scalable too. You can use also all the cores available in the machine, and because it's a functional language, you do so with minimal risk of introducing flakiness.

So as you might have guessed at this point, we'll transition to Elixir. We won't do a full rewrite. Rather, we'll place a proxy in front of the Rails service, and run the Elixir service in parallel. We'll route the traffic to the Elixir service as we migrate endpoints. It's going to be awesome when we give our on-premise customers a Docker image that can use all the resources available without any configuration required on their end. Or even better, gear our energies toward building products instead of figuring out how to scale our API.

Rails scales, but Elixir scales better.

PS: Despite our excitement for Swift on the Server, we decided to go with Elixir because of the productivity and the ecosystem around it. Erlang's hot-reloading of modules is an unbeatable productivity tool.

To do so, I've been trying to change my habits. The first one is to prefer asynchronous communication over synchronous. For instance, in the Tuist Slack group, we encourage more users and contributors to move the discussions to GitHub issues and pull requests. They could theoretically move the same communication style from Slack to GitHub, but the long-form body of the issues and pull requests makes it harder to have a synchronous conversation. It makes the initiator of the conversation think more about the message they want to convey, In Slack it's natural to feel entitled to grab someone's attention and expect an immediate response.

Another thing that I started doing is using X less. The algorithmic feed is designed to keep me scrolling and scrolling and engaging with the polarizing content. Instead, I'm using Mastodon, where the feed is chronological and feels so much more peaceful. It sometimes feels so boring that I don't use it at all. It almost feels like an intermediate step to get rid of the addiction. I don't know if it's because of the people that I follow there, but I don't have the feeling that people are trying to grab my attention. Every conversation that I see is meaningful and respectful. X makes me anxious, and Mastodon doesn't.

I'm also working on caring less about what people think about me. What does it have to do with attention? I started to notice that I sometimes did work to get the approval of others. I liked getting that attention. I think it's an X/Twitter-induced behavior because it keeps me engaged and active on the platform. I still like sharing the things that I learn and think about, hence why I'm writing this blog post here. But similar to asynchronous communication over Slack, I'm trying to use more this website over X or Mastodon. Not only does writing here relax me, but makes me the owner of the content. I'm getting a bit fed up with all the companies using AI to ruin the content humanity has been generating for years. Do you like the content here? Sweet, there's an RSS feed for you to subscribe to. Do you want to engage in a conversation? Just send me an email. F***ck the algorithms and enshittification of the Internet.

It's time to gain the attention back and have a more meaningful and calmed relationship with myself and others on the Internet.

Swift allows having global state, whether protected or not, to prevent data races. It all starts with a stateless singleton instance for memory optimization purposes and better ergonomics: Client.shared, FileManager.shared... Sooner or later, someone adds state, and you end up with code making assumptions on the value of that state. The breakage of these assumptions is often not covered by tests, but that’s a subject for another post. So, part of your codebase is directly or indirectly dependent on mutable state. What could go wrong? Nothing if you run your tests sequentially. Run them in parallel and wait for the first signs of flakiness to arise. But it doesn’t happen to me, Pedro, because I'm mostly writing unit tests where I mock all the subject dependencies. And you are right, but in some scenarios, integration tests can bring a lot of value, and in those, your stateful components are very likely far from the subject under test.

To run the code in parallel, you need to be able to scope that state to the test being executed. How do you do that in Swift? Well... using dependency injection, which will lead to a lot of refactoring and some boilerplate in function signatures.

I started working on the above for Tuist, but I find it very annoying, honestly. Elixir solves this very beautifully through the concept of processes and their unique ids. Because a test is a process, and a process has an id, you can leverage that to swap modules depending on the id of the process the module is accessed from. Mind-blowing. Swift, please, bring that.

I’m now fully aware of it, and I’m taking steps to protect my creative energy. I've started allocating some time to work on stuff that was not a priority but that I enjoy doing and that I believe can have a high impact on the community. At first, I felt guilty. My brain was telling me that I should be doing something else that was more urgent. And I felt bad for feeling that way. Sure, there’ll always be something more urgent, but I can’t be working like that all the time or I’ll feel like a hamster on a wheel. I think my creativity is one of my most valuable assets, and I have to protect it.

For instance, I recently started working on new MIT-licensed gifts for the Swift community under the Tuist umbrella. One of them is a design system for building CLIs. I noticed that unlike other ecosystems like Go’s and Rust’s, Swift lacks a proper toolchain for building stunning CLIs. So I started building it. Is it a priority? Hell no. There’s a business to run. But through that work, we can positively impact the experience of Tuist users and the users of many other Swift CLIs that might be built in the future. I’ve also been playing with Apple’s virtualization and containerization technologies. I find it's such an unexplored area in the Swift community, where we could also have an impact with some open-source work that could serve as a foundation to diversify our Tuist Cloud offering. If no one tries those things, we’ll never know if they are worth it.

Do you feel the same? If so, how do you protect your creative energy? This is one of the topics in my therapy sessions, and we are coming up with strategies to protect it.

I'm not a fan of pure functional programming languages because their syntax and semantics don't click with me. However, and having learned that the hard way, it became clear to me that global state is future debt that sooner or later you'll have to pay. If this sounds too abstract, let me guide you through what I mean by that.

When writing software, it's easy to add global state for the sake of convenience, for example via the singleton pattern. A singleton is not necessarily a bad thing, because you can use it as a tool to use memory efficiently, but by introducing it you are laying the ground for global state to grow. Developers will plant the seeds, and you won't notice it in your PR reviews. CI pass, developers will continue shipping features, and everything will seemingly work fine. It will until it doesn't. You notice it when you have concurrent access to the global state, and the behaviour of your software becomes unpredictable due to race conditions. In some cases, you'll notice it because users will report bugs that are hard to reproduce. In other cases you'll notice it because parallelizing the execution of tests results in an increase in flakiness. In any case, it's painful for your organiation because you'll definitively have to throw resources at preventing and mitigating it. And the larger the software becomes, the more unmanageable it becomes.

There are some programming languages and runtimes where global state can happen so easily that it's hard to avoid it. For instance, with the JavaScript ES module system, where variables can be defined at the root of the module and modules are singletons, it's very tempting to use global state. In the ecosystem, they tooling refer to them as "side effects". And not only it makes the software harder to reason about and unpredictable, not just for the developers but for the tooling that's unable to understand the software well enough to optimize it. Hence why Webpack decided to introduce a convention at the package level to mark the side effects of a package. Other technology stacks like Ruby and Rails, where global state is common in databases, provides testing tools to scope databases to a particular test so that it's not shared across different tests. Did you notice? Still, nothing prevents a Ruby class from using global state. And once again, a developer is not thinking about that while writing the code. It's a natural inclination towards convenience without thinking deeply about the implications of the decision. That's why when I hear that about Ruby or JavaScript scales, I can avoid it but to think about how many resources are required for that, and how much of the organization's time is going into making that scale. But because that's hard to measure, the framing is often about the number of requests per second.

The nature of the program makes the problem less or more common. For example, in web applications, that follow a request-response model, things are naturally modeled more functionally. A request comes, a set of functions pass that state around, and eventually generate a response that's returned to the client. CLI's are a bit like that too, where a command is executed passing a set of flags and arguments, which resembles a request in an HTTP server, and is passed through a set of functions that transform the state until it's returned to the user. Still, global state can happen and will happen. It happened in Tuist, and now it's limiting the test parallelization that we can achieve in some areas. It's still manageable, and we are working on it, but I find it crazy that we reached this point without noticing it earlier.

So what can we do about that? For example, in the context of Tuist, which is a CLI implemented in Swift, we'll have to resort to dependency injection to escape global state, and use it to isolate the execution of tests. Similar to what Rails and many other web frameworks do with databases. It's feasible, but it comes at the cost of making the code more verbose. Suddenly all your functions take similar arguments, and developers wonder why they have to pass the same arguments over and over again. One could suggest to use a service locator, or a dependency injection framework, but that comes at a high cost too. It's a new piece of technology that developers have to learn, and that you need to maintain. For example, Uber has an open-source tool, Needle, which requires an additional code-generation tool installed in the environment. Having required that in the past for Tuist contributors, and learning that it was a source of friction, we are not going to do that again. Sorry. It's dependency injection at the cost of boilerplate the solution? Most likely yes in the context of Tuist, but we'll try to model it to reduce the boilerplate as much as possible.

Someone familiar with functional programming languages like Clojure might read this and think: "I told you so". But as I said earlier, the syntax and semantics of those languages don't click with me, and the purism that naturally comes with them doesn't either. Isn't there a solution that's more pragmatic?

Once again, Erlang and Elixir shine. Elixir feels like Ruby with a more functional touch. It really clicks with me. And they have one of the most powerful concepts I've seen since I started my career: processes. First, the language is functional. Not as pure as Haskell, but it embraces the functional paradigm, so global state is less likely to happen. Do you remember that trick that I mentioned earlier to scope databases to a particular test? Imagine being able to do that with any piece of state. In Erlang or Elixir, processes are like classes in OOP. They are cheap, can form a hierarchy, can communicate with each other by sending messages, can hold state, can be supervised, and most importantly, they have a unique identifier–a process ID. Tests are processes, and they have their unique ID (and state). Elixir leverages that to allow swapping a module's implementation at runtime, for a particular test. So you can mock a module's implementation for a particular test without having to pass the mock all the way down through the call stack. And this is truly powerful. I wish many other programming languages had that.

Anyways, because I can't write everything in Elixir, I changed my approach to writing software to avoid either creating state myself or laying the ground for global state to grow. In Tuist we'll have to refactor the code to escape global state, and in future projects, I'll embrace the everything is a function paradigm, and figure out the right balance there with the readability and maintainability of the code.

Avoid global state.

I was on my own. Often with no idea of what I was doing. But filled with curiosity and determination. I remember every single moment of my life when I learned what other people have the privilege to learn earlier, due to the education system in their countries or the higher education of their parents. For example, it took me more than a year working at Shopify to understand that what I was given as part of my compensation alongside my salary were real shares of the company, and they had value. To put things in context, my parents have always been firm believers in not putting the money in the bank but under the mattress. Every one of those moments brings me a feeling of unfairness, but also a bit of: I'll throw myself into it and figure it out.

Being determined has been key to many of the successes and also happiness that I've had in my life. It's what has allowed me to push through the challenges of building something new, like Tuist, and to keep going when things get tough. It's what has allowed me to keep pushing for new ideas, like the idea of a web compiler, even when people tell me that it's not possible or that it's not worth it. If you listen to the naysayers, you'll never get anywhere. You have to be determined to keep going, even when things get tough (I just learned about the concept of naysayers thanks to the wonderful Copilot helping structure my thoughts).

I feel so lucky to have learned this, that I feel extremely entitled to empower others to go through the same, regardless of their starting point. And that's why I like open source so much. OSS connects me with people who have the potential to create a lasting impact in the world, but they might not feel the confidence to do so. They instead remain quiet and don't share their thoughts, ideas, and code with the world. Because the world is noisy with people who have the privilege to be loud.

Having gone through the Tuist journey and up the corporate ladder at Shopify, gave me a window into a world of privileges where it's about oneself and not about the collective– about not valuing you because of your background while we throw resources around to train people on unconscious bias. A world of I'm more than you. A world purely looked through the lenses of numbers and financial productivity. That world is not for me. It makes me extremely uncomfortable. I don't enjoy it.

And it's tremendously unfair because the best leaders who might be able to stop the most pressing problems the world will be presented with are quietly waiting for someone to empower them. I enjoy working on Tuist because I see others being empowered to build things that they wouldn't have been able to build otherwise. I'm pouring some of my spare time into Glossia, because María José is one of those people with huge potential that could have a long-lasting impact in the world, but she's faced with one rejection and question after another. I like to tinker with ideas in the open because they can be a foundation for other ideas to emerge and empower others to build things that they wouldn't have been able to build otherwise. And that's why the layoff at Shopify, although feeling like a punch in the stomach, was one of the most liberating things that could have happened to me.

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.

Erlang taught me that with the right modeling of the problem space, you have the potential to eliminate a whole set of problems that emerge at higher layers. Erlang does so with its concept of processes, and Elixir added the layer of programming language that we are used to. What if we need to peel layers, escape JavaScript, and move down levels to model the problem at a different layer?

If we look at the common denominator across all of them, what we find is a function that goes from a domain where we find components like .svelte, .vue, .jsx to .html, .css, and .js that our browsers can read. They all support being hydrated on the client, and some do it through a virtual DOM. We have a compiler. And this is the foundation upon which many of the tools emerged. But so many emerged that using the compiler directly became unthinkable to the point that React doesn’t recommend it anymore. This made the layer upon the compilers another foundation for frameworks to emerge. Their aim? Abstract away the absurd amount of complexity underneath. Some even went further, like Vercel, which built a business upon it. And having so many layers has a cost that depending on who you ask, they say they are willing to pay it. JavaScript developers do; they’ve internalized the brittleness and the frenzies of the ecosystem. They are fine spending days understanding how a deep dependency update resulted in crashes in their apps. Organizations, on the other hand, don’t want this. Still, they don’t want to miss out on the productivity that JavaScript concepts and tools can bring.

Among the ideas that emerged at the JavaScript layer, there was one that I believe played an important role in the state of things. I’m talking about sharing components in NPM packages. Components could be encapsulated in an NPM package, distributed through the NPM registry, and integrated by build tools like Vite, which can be instructed via plugins for how to do so with every available UI technology. This addresses the natural need that developers have for sharing code of their project. Code that represents UI in this case. Do you know why Tailwind is so successful? I believe one of the important factors is that they allowed a way of sharing components, copying and pasting, in this case, without requiring developing your UI at a JavaScript layer. It’s not a surprise that DHH supported it. It was solving something that neither Rails nor other technologies that are not based on JavaScript had solved.

And all of this leads me to the most important question: Does all of this have to be solved at the JavaScript layer? Or have we cargo-culted from UI frameworks like React, normalizing the layers of complexity along the process? I believe more the second.

I think the industry is missing a** platform-agnostic and technology-agnostic compiler that can be plugged in as an in-code backend for rendering purposes in any other stack (Rails, Phoenix, Express).** The compiler would support features that developers have grown accustomed to, like writing styles in the component and getting them estranged into CSS or having state that changes over time and that the system takes care of mapping to HTML when it changes. We don’t need to reinvent the wheel at a low level when web components exist. They are not there in terms of capabilities, but we can augment the missing bits and bet on the future of them. Moreover, the compiler can support sharing components via packages, making them easier to integrate. For example:

compiler install shadcn

And I can just write the following in my project:

 Click me

No more do you have to have Tailwind CLI, set it up this way, and have React too, and have this config file at the root. What an absurd amount of unnecessary tools. I just want to install a design system and use it.

If you notice, being able to write and share UI opens a lot of exciting opportunities. For example, giving design agencies a standard format to share their work and even charge for it. Instead of having to export it in many formats or just one that the customer uses, you can export it in a universal format that’s easily integratable. Or imagine training AI models with examples of design and having a tool like Vercel’s V0 that’s not coupled to React or Next and doesn’t try to lead you into becoming a customer of anything. Imagine too a Git platform that’s able to visually render the diffs.

I believe this would positively impact the tools built upon it because instead of having to waste time supporting every new UI framework that comes out, they can focus on one and make that experience the same.

Sounds like a giant effort, like Tuist seemed when I started working on it, but incrementally and with a lot of time, we arrived at where we are today. I feel I need to give this a shot in my spare time. I dream of enabling an ecosystem of sharing UI like the one that we developers have the luxury of having access to. The impact that a tool of such nature would have on the tech ecosystem is immeasurable. It would also align the experience of all the web frameworks, regardless of the programming language, and the decision of using one or another would be more nuanced.

I threw a repo and started dumping ideas on it at https://github.com/glossia/noora. I named it after Noora, which is an Arabic name that means light—the light in this ocean of complexity in the JavaScript world. Send me an email at oss@pepicrft.me if the above idea sounds cool and you'd like to contribute.

Luckily, we have an excellent foundation in Tuist to tackle that. The first thing that we built was binary-caching, which skips some compilation steps. Tuist Cloud is a service that spans that incrementality across environments. The second feature that we landed to take that incrementality to the next level is selective testing. Leveraging the same hashing solution that we use for binary caching, we can run only the test targets that are impacted by the changes. The combination of binary caching and selective testing can cut CI times quite significantly. But we are not done yet, we are going to bring binary caching to the tuist build workflow too. And, last but not least, we are going to skip the dependency resolution via Swift Package Manager, which can easily add a pair of minutes to every CI build.

The best of all? It's built into Tuist. If your project is described using Tuist's DSL, you get all of the above right away.

tuist cache # Warm the cache with binaries
tuist fetch # Fetch dependencies from the cache (seconds)
tuist test # Use selective testing and binary caching
tuist build # Use cache binaries

We are working hard on providing organizations with the best balance between convenience and performance.

The music quality was astounding. However, occasionally, they would disconnect automatically, requiring a hard reset and reconnection. This was somewhat annoying, but not enough to warrant a trip to the Apple Store. Despite these issues, I enjoyed listening to music with them and considered it a great purchase.

That feeling lasted until they suddenly stopped working. I attempted to reset them, but instead of the sequence of blinks being three ambers and one white, it was just three ambers. The headphones had become useless. Consequently, I visited the Apple Store in Berlin, where I currently reside.

I explained the issue, and after examining them in a private area, the staff returned, ready to discuss the problem, starting with an unexpected question: "I'm sorry, Mr. Pedro, but do you have insurance for the headphones?" I was surprised. Insurance for headphones? They informed me that the repair would cost up to 250 Euros. I was shocked. "What happened to them? Why are they broken? It's only been two years," I questioned. I asked if I could send them for an estimate of the repair costs, suspecting a software issue. However, they informed me that if sent for repair, I would have to pay the full amount and would receive a 90-day warranty. I was puzzled and felt like it was a case of planned obsolescence. The Apple employee added that if I had reported the intermittent connection issues earlier and had a record of them, the repair would be free. I left the store feeling a mix of disappointment and anger.

At home, I researched the three amber blinks issue and discovered I wasn't alone (Reddit, Reddit, Apple Discussions). Others had similar problems; one person fixed theirs with a software downgrade, which failed again after an automatic update. Some had their headphones replaced for free. Others got it working by putting them in the freezer for a while. It was unbelievable that Apple could potentially cause hardware issues through a software update without any liability, shifting the responsibility onto the user.

I secured another appointment at the same store in Rosenthaler Straße, Berlin. This time, the employee, after consulting with his superiors, offered to cover 50% of the repair cost. I inquired about the specific issue and the warranty duration, but they were unable to provide detailed information about the fault and only offered a 90-day warranty. It seemed they could temporarily fix the issue and charge me 250 Euros without a guarantee of a long-term solution.

Apple seems to have found a legal loophole to charge users, but this is unfair, and I am determined to seek a resolution. If you're reading this, I would appreciate your help in spreading the word. I am also considering approaching consumer agencies in Europe to file a complaint.

There are a handful of examples in Xcode. For example, the Find implicit dependencies option in Xcode schemes. It opens an interesting debate about whether a graph with dependencies not explicitly declared in the project should be a valid graph. What we learned with Tuist is that the more explicit and side-effect-free the build graph is, the easier it is to reason about it and optimize it. So developers lean on the side of implicitness, which is alright at the beginning because you can type import MyFramework and declare a dependency with MyFramework in code, but a few months later, when the project grows, some features like Xcode Previews don't work and you don't understand why. We've seen organizations adopting Tuist and reporting that their build times became faster after they migrated or that Swift Previews started working. So part of the work that we do with Tuist consists of designing APIs that prevent implicitness in projects.

Another example is Xcode exporting the built products into a directory that's linkable from any target of the project. So if you have a dependency scenario like A > B > C where > represents "depends on", A might be able to import C because by the time Xcode starts building A, the built products of C are already available in the directory that Xcode uses to link the products. You might think this product principle is unique to Xcode projects, but the Swift Package Manager has inherited it too. Package libraries can mark themselves as automatic, letting the build system decide what the best linking strategy is. I want to make that decision myself. Especially when the linking might impact the size of the output bundle, for example by having the same static library linked from multiple dynamic frameworks. Once again, leaning on the side of convenience, at the cost of presenting developers with other issues.

As you might have noticed, all this convenience is achieved by making Xcode's build process more magical. You hit compile, and there are a bunch of things in your project that Xcode might be able to resolve magically, or maybe not, and you end up with one of those cryptic errors that developers try to resolve by cleaning the derived data folder.

The more I think about this, the more I think Apple should go back to first principles, flag those as anti-patterns, and provide a migration path for existing projects. The reason why that implicitness was introduced in the first place is because declaring a dependency graph in Xcode exposes a lot of complexity to the user. For example, when a dynamic framework should be embedded or not into a final product is something they can infer based on the graph, why are they requiring users to do so? We do that for users and they love it because it's one less thing they have to worry about. What about potential bundle size increase due to static libraries liked in different parts of the dependency graph? They could detect that too and present the user with a warning before they hit compile. There's a lot they could do to make Xcode a tool and a build system that works with large-scale projects, but I guess they are not incentivized to do so. The organizations that have reached that scale, can resort to other build systems like Bazel, or tools like Tuist.

Imagine if they took the opportunity to build a foundation that's extensible like Gradle is so that developers don't have to replace their build systems or resort to additional tools. I think I'm dreaming too much.

Tuist uses XCFrameworks to binary-cache framework targets (soon libraries too). Xcode supports defining links to XCFrameworks and Xcode takes care of using the right framework or library based on the destination. It's very convenient. XCFrameworks is a directory with a convention around how to structure libraries and frameworks for different platforms and architectures.

But Tuist needs to be able to cache resource bundles too, and they are not supported by XCFrameworks. It'd be a huge stretch for the XCFrameworks name :). So I started pondering about creating our internal container, XCBundle. The structure of an XCBundle would be similar to the one of an XCFramework, but it'd be used to bundle resources instead of libraries and frameworks:

MyBundle.xcbundle/
 Info.plist
 ios-arm64/
 MyBundle.bundle
 ios-arm64_x86_64-simulator/
 MyBundle.bundle

This is going to be an internal container not exposed to the public. When generating Xcode projects, we'd introduce the necessary script build phases to copy the right one based on the destination. This is something that Xcode does automatically for XCFrameworks, but we'd have to do it manually for our own container.

This will most likely be worked on after we release Tuist 4, which is going to be a big milestone for us.

If you have read my work for a while, you might have noticed that I advocate for it. Many of us are introduced to building craft outside of work. It’s fun. If it goes well, and people use it, you can meet very talented builders. You also build public recognition through the work. Your OSS becomes your CV. This is net positive for you. I know some maintainers who, once they reached a point of recognition, moved on. OSS was the lever for their professional career.

You’ve probably built a community, and a sense of responsibility has grown within you. At this point, it’s common to hear among contributors, I devote all this free time to the community. But how much of that is pure altruism, and how much is self-interested altruism? I ask myself this question every day. Because we humans have a natural inclination towards recognition and appreciation from others. So, it might just be an exchange of your time for that recognition, which feels great. But you are putting something limited on the table, your time and attention. So, you might end up stretching it too much to the point of burning out, as is common to see in our industry.

Having reached the inflection point of being unable to satisfy community demand with limited resources, some projects decide to maintain their status and juggle all the demands by setting low expectations for responses. Being emotionally stable and good at prioritizing is key here. I’m quite impressed by projects like Homebrew and Fastlane that have managed to do this continuously. Still, I feel bad for the maintainers who need to take part of their free time for their project duties. I can’t help but think: it’s unfair.

Having reached that point, you can alternatively start thinking about ways of funding the project beyond donations, which, in my experience, it's tricky. And depending on the nature of the project, you might have more or less trouble trying to achieve this. For example, if your plan is to provide a cloud service, and the code is OSS, you are competing with cloud providers like Google and Amazon, who can implement a much better and cheaper solution faster (I learned recently that some developers call this being "Jeff'ed"). This happened to Redis, and a handful of other projects that had to leverage licenses to avoid exploitation by large tech companies.

I couldn't realize the seriousness of this, especially seeing large tech companies so devoted to OSS these days, until I experienced it myself. There’s a lot of hypocrisy. Companies support OSS because it gives them a great reputation in the developer community, and they might end up getting free (gratis) layers of software to build upon. They design a supply chain where most of it is free developers’ labor. Which business doesn’t like OSS when presented that way? Companies like Microsoft and Apple like being the ones creating and maintaining OSS layers, for example, TypeScript, VSCode, and Swift, because it gives them a great reputation in the developer community, and they might also get some contributions for free. It's a sort of OSS-washing. However, when it comes to contributing to other OSS projects that they heavily depend on, the story is completely different. They don't feel a sense of responsibility towards the external OSS tools that they use. The model is perfect for companies.

So despite the importance of OSS in the world, with great examples like Linux, we haven’t figured out sustainability, and I doubt we will. We can approximate sustainability, but the closer we get, the further companies will move it. Because while you see it as a lifestyle, as a hobby, as a creative space, as a community, for them it’s just free blocks. If a company like GitHub, which is in the position to deploy a frictionless solution to fund OSS, doesn't, who else will?

There's one last model, which I've been seeing a lot lately, and it's the idea of doing OSS because "you are gifting something to the world." DHH uses it a lot with every piece of OSS the Basecamp folks release. Many developers in Ruby do it too. It's a model I'm starting to align more closely with. So rather than starting with an OSS project, you start with a business. You focus on making something that delivers value to society and that can financially sustain itself. And then, you extract the pieces that could be valuable for others. You extract layers of value to support others in their entrepreneurial journey. Rails is a good example of that. And you don’t necessarily need to set high expectations. Quite the opposite, indeed. You can put something out there for people to learn, fork, and extend, but they should not expect you to treat that as your first priority.

I wish a developer could make OSS sustainable without having to delve into the business side of things. But OSS is embedded in the tech industry, which is embedded in capitalism. So the sooner you learn about these dynamics, the better you'll be able to navigate them. It took me years to realize and internalize this. But I'm glad I did.

Going forward, I'll lean on the side of creating businesses that gift OSS bits to the community. And those businesses will inherit goodies from OSS like transparency, open communication, or extensibility. Those traits are not exclusive to OSS. And we have plenty of examples of closed-source businesses doing it beautifully.

When your program has global mutable state that's shared across different parts of the system, the result of your tests might depend on the order in which they are executed. This might go unnoticed if the test runner has a deterministic order, but if it does not, you might end up with flakiness that's hard to debug and fix. The matter gets worse when you try to run the tests concurrently or in parallel (Difference between Concurrency and Parallelism). And this is something that happens sooner or later in the lifecycle of a project. You first run the tests sequentially in every commit. Then, as the test suite grows, you introduce concurrency or parallelism if the runtime allows it. But that comes with flakiness that's not fun to deal with. You could not anticipate it because you chose a programming language that allows global mutable state (e.g. Ruby). Eventually, you might consider selective test execution, but for that, you need compiler-lever knowledge that either the compiler doesn't provide, or your programming language is compiler-free.

At Tuist we are at the point where we'd like to enable more parallelization, but we have some global mutable state that's preventing us from doing so. At some point in the past, we decided to lean on the side of developer ergonomics over test scalability, and now we are paying that debt. For example, every module has a logger instance that they use to output information to the console. For most projects, having a global instance might be fine. But for CLI tools like Tuist, it does not. It does not because what we output and how we output it is connected to the experience of Tuist, and therefore we test it. And what happens if multiple tests are interacting in parallel with a global logger that's storing the logs to run assertions on them? We'll run assertions against logs coming from multiple tests interleaved. Voilà, flakiness. As I talked about in the past, it'd be great if each test run had a unique ID that we could tie global state to, like it's possible in Elixir, but unfortunately, we don't have that luxury in Swift. What's the solution then? Passing a logger instance down from the command, to the deepest function that needs it. The challenge is to do so without adding too much noise to the codebase.

Another example of a global mutable state is any system cache that the CLI might need. For example, Tuist uses a global cache to serialize the compilation of manifests and speed up future command executions. Back when we implemented this feature, we added an API to customize the cache directory via an environment variable. We could use that API from our Cucumber-powered Ruby acceptance test suite to have a cache directory per test. However, since we moved the tests to Swift, using environment variables is not a viable option anymore because all the tests run in the same process with the same environment variables. Once again, we need to pass that information down to the deepest function that needs it.

Since this is something that we'll have to do with multiple global states, I'm starting to think it might make sense to have a Context struct that we can pass around and that'd represent an interface with a global state. I'll play with it and see how it goes. Ideally, this is not necessary, and Apple's new testing framework in combination with actors, solves this by assigning unique IDs to each test run, but I'm being too optimistic here. That uniqueness is what makes Erlang and Elixir special, and everything builds upon it. I doubt they'd introduce it just for the sake of solving this one isolated problem.

This developer experience is far from ideal. Some organizations decide to ignore the problem, perhaps because they are not aware of it. Others like Shopify have an entire team dedicated to solving it, which comes at a huge cost for the business. What if you could solve the problem with little to no effort and cost? That's what Mise is for. We are making it the default installation method for Tuist, and also evangelizing it to the Swift community, where project setups have multiple tooling requirements. For example, Ruby to run Fastlane, SwiftLint to lint the Swift code, or Sourcery to do meta-programming. Imagine managing these tools without a unified method that's consistent throughout the local and CI environments...

How does it work? Easy. Once you've installed Mise and added the hook to your shell, you can create a .mise.toml file at the root of your project:

[tools]
tuist = "3.39.3"
swiftlint = "0.54.0"
sourcery = "2.1.3"
ruby = "3.3.0"

Then you run mise install and Mise will install and activate the right version of the tools. Note the "activate" part. Mise ensures the right version is activated when you are in that directory or any sub-directory. That prevents globally-installed versions from taking precedence over the ones specified in the .mise.toml file.

And what about CI? You can also use Mise. If you are using a CI provider like GitHub Actions, the process is very simplified through a custom action, mise-action:

on:
 pull_request:
 branches:
 - main
 push:
 branches:
 - main
jobs:
 lint:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - uses: jdx/mise-action@v2

Mise is by far one of the best tools I've used for configuring and activate my environment for a project. It's one of those tools that you install and forget about it. @jdx, the creator of the tool, and a developer very passionate about creating terminal tools, has done a fantastic craftsmanship job with it. I'd recommend to give it a try. You won't regret it.

• It's not fun to replace Xcode projects and build system with new building (more advanced) building blocks that break with every Xcode release. I look at you Bazel. - It's not fun when your shiny JavaScript-powered project fails to build after you do a minor version dependency update due to a cryptic error message that comes from ten layers of dependencies deep. - It's not fun when you can't debug your JavaScript code because it's gone through a series of transformations and optimizations that make it impossible to understand. And it's even less fun when you have to set up a system for your error-tracking solution to be able to help you with source maps. - It's not fun when you can't debug your issues because of the layers of abstractions and proprietary tech your project is building upon. I look at NextJS, Vercel, proprietary serverless runtimes, and Xcode. - It's not fun when you have to read books and take courses to understand the architecture that software introduced in a code base because they saw everyone in the community talking about it. - It's not fun when the programming language that you use gets unnecessarily complex because it's trying to be everything for everyone. I look at you, Swift. - It's not fun when you have to build your standard library because the language that you use, JavaScript, lacks it. And it's even less fun when the people who built the packages required for that are often jumping from one project to another, leaving you with a broken project. - It's not fun when there are thousands of ways to do the same thing, and you have to spend time learning them to understand the code that you are reading. - It's not fun when the tooling that you use tries to be smart about how you want to use it and ends up being a black box that you can't understand. - It's not fun when your toolchain and code editor don't integrate well and you have to spend time configuring it to make it work.

I believe the ecosystems with the healthiest communities are the ones that can spot the complexities and work together to simplify them. Rails is an excellent example of that. Erlang and Elixir have also done a great job at that. That's the reason why I connect with them and enjoy working with them. Because I can stay focused on the problem that I'm trying to solve and not on the tools that I'm using to solve it. And more importantly, I do it with the relief of knowing that they haven't abstracted a huge pile of complexity like JavaScript is obsessed with doing. Because knowing that makes me uncomfortable. That pile of complexity is going to bite me at some point, and I'm going to have to deal with it. Not for me.

• Shopify fired me in May along with many other colleagues, many of whom happened to live in a country, Germany, where people were organizing to unionize. This was a moment of disappointment for me towards a company that I admired and that I thought was doing things right. I felt lied to and betrayed. After this experience, I looked at other companies with a different lens and a lot of skepticism. Luckily I came across the Hacking Capitalism book, which taught me a lot about what no one teaches you about capitalism and how to navigate it. - My wife was fired too from Shopify. She's a localization program manager, and she's not as lucky as we still are in the software industry. Everyone is questioning the value of localization in the industry due to AI advancements. She loves languages and would like to continue working on that space, but seeing her suffering and feeling lost is hard for me. It's unfair, but once again, capitalism is not fair. - I decided to focus on Tuist full-time and turn it into a business. Some organizations received this transition well, while others didn't. In particular, Bitrise, who was trying to profit from the work we'd done for years without contributing anything back, decided to publish a web page to rant about the project and me as one of the maintainers of the project. Once again, capitalism is in its purest form. If you do things altruistically, you are cool, but if you try to make a living out of it, you are a bad person. I'm not going to lie; it hurt me a lot. I felt like I was being bullied, and I didn't know how to react. I felt powerless. Luckily, I was surrounded by many people, including my wife and Marek, who understood the situation and helped me to get through it. - I won't lie, trying to turn Tuist into a business puts a question in my head every day: will it work? I have enough savings to not worry about money for a while, but still, I can't stop thinking about it. An impostor syndrome is growing inside me, and I don't know how to stop it. I'm trying to be rational and think about the facts, but it's hard. I used to have more confidence in myself, but since all the Shopify stuff, I feel like I'm not good enough. Crazy, isn't it? Even if it doesn't work, I'm sure I'll learn a lot, and I can always go back to a full-time job and help organizations that are struggling with their Xcode projects. - My mother and sisters are going through a rough time mentally caused by a toxic relationship with the family business, which is dominated by patriarchy and slavery practices. I knew it'd happen sooner or later, and tried my best to prevent it, but there are many big elephants in my family's room that no one talks about to avoid conflicts. They prefer conflict avoidance, even if they know that will result in a much larger conflict. My mother was the first one to break down after more than 20 years, of working without any salary adjustment and 7 days a week non-stop. I'd like to build a source of income to retire her and my father and put a hard stop to this situation. The part of the family that benefits from this situation, which includes my uncle and my grandmother, doesn't want to see me around because I bring the whole setup into instability. They don't want me to speak up. This was a rough way for me to end the year.

Will 2024 look better? I don't know. I hope. For now I'm going to talk to a psychologist about it and get some help to cope with these situations.

I'm starting to accept that it's part of the process of growing a project. At some point, you need to trust other people to make decisions. And you need to identify what are your strengths and how you can impact the project the most. In my case, that's helping shape the vision for the project, and fostering a community of contributors that feel empowered to make decisions. Trying to do coding feels like being a manager and trying to write some code. You certainly can do it, but you'll be more effective if you focus on the former. Otherwise, you risk being on the critical path of efforts that could be done by others.

I admire technologists like Tom Preston, who were able to build successful companies like GitHub, create and grow successful open-source projects like RedwoodJS, and balance all of that with his family life. I think it must also take a lot of discipline and prioritization to be able to do that. Which I'm still learning to do.

These reflections have led me to realize that many people in this town are also metaphorically 'sick,' due to an inherent toxicity that pervades every aspect of it. This toxicity makes me extremely uncomfortable during my visits, a sentiment that saddens me as my parents, despite their best efforts, cannot mitigate it.

To understand this toxicity's origin, we must delve into the local culture. While my experience is specific to Cieza, I believe many aspects are reflective of the broader Spanish culture, which is complex and often surprising. It’s important to note that not everyone conforms to this pattern, but it's common enough to be noticeable.

On the surface, everyone appears social and supportive. But upon closer inspection, it's often superficial. There's a lack of genuine empathy and trust. People constantly compare themselves to others and gossip incessantly, almost like a national sport. If you're successful, envy ensues because they attribute your success to luck. If you're struggling, they offer hollow condolences. Non-conformity to societal norms leads to judgment and subtle ostracism. For instance, my sister-in-law, who is vegan and lesbian, faces misunderstanding and indifference from many who are unwilling to challenge their preconceptions. If you don't adhere to societal expectations and seek mental well-being, you must don a façade, a process both exhausting and mentally draining.

Whenever I encounter locals, I feel compelled to conform to their preconceptions about Germany and Spain. Challenging these views often leads to social rejection, and amusingly, they report back to my parents, as if to confirm my 'Germanization.' It's infuriating.

Walking around, you often see people drinking large quantities of beer, possibly using alcohol as an escape. I think of the many who suffer because they can't express their true selves. My mother, for instance, struggles with anxiety and stress, and fears the town's judgment for seeking mental health treatment. Ironically, when I moved to Germany, she felt compelled to frame it as a deliberate choice, rather than a lack of local opportunities.

As my parent-in-law often says, Spain lies at the world's edge, Murcia at Spain's, and our town at Murcia's. Being here feels like time-traveling to a bygone era, where societal expectations dictate major life decisions like marriage and parenthood, often at the expense of personal desires.

I’ve pondered whether this cultural aspect is recent, but Spanish literature, including Lazarillo de Tormes (1554), Miguel de Cervantes Saavedra, Don Quijote de La Mancha (1605), and Federico García Lorca, La Casa de Bernarda Alba (1945), reflects similar themes. A line from the latter beautifully encapsulates my feelings about my town:

"This is how one must speak in this cursed town without a river, a town of wells, where one always drinks water fearing it's poisoned."

It symbolizes the pervasive mistrust and fear of public opinion.

So, being in Cieza means not being myself, which in itself makes me 'sick.' When locals advise us to return to Cieza, boasting of its unparalleled lifestyle, I’m reminded that explaining my connection with Berlin is futile.

And regarding health practices like wearing masks during flu season, there's resistance since it's not mandated. Unlike in Germany, where people understand and respect health guidelines, here it’s about following rules, not rationale.

Will this change? I'm uncertain. It requires a significant investment in education, something I don't see happening. Friends starting their teaching careers are already witnessing discriminatory practices, a disheartening sign that impedes Spain's progress. While there are aspects to celebrate, like our cuisine, they don't overshadow the need for societal evolution.

If I ever return to Spain or Cieza, seeking therapy will be a priority to prepare for confronting a reality I now encounter only a few times a year.

When we decide to invest in type safety, we do so because we trust the compiler more than we trust ourselves. For example, if there's a function named getUser(id: ID), one might be concerned about someone calling the function with an ID that doesn't represent a user ID but a post ID. Sure, we could model our types to have different types for user and post IDs (there must be a mathematical term for this), but isn't the semantics of a function enough to convey its purpose and trust that developers will use it correctly? I think so. Sure, there's a chance that someone will call the function with the wrong type, but there's also a chance that even getting the types right, your software won't do what it's supposed to do.

What this obsession with type safety often leads to is over-engineering–teams spending endless hours discussing what the best typing solution is for a particular problem according to theory X or Y. It also worsens the onboarding experience for new developers, who have to learn a new type system and its quirks before they can start contributing. Imagine being an engineering manager seeing your team not delivering features because they are stuck in a discussion about types. Sure, one could justify that this is a long-term investment that will pay off in the future, but in software, where requirements change all the time, all the time spent to come up with the perfect type system is time wasted because you'll have to change it anyway soon.

Note I'm not saying you should not care about type safety. I'm saying we might sometimes get too obsessed with it without realizing the cost of it. This obsession will lead to a tax on your team's productivity and happiness. I've seen it happen.

This realization made me think about JavaScript and JavaScript web frameworks and their APIs to store state:

// React
const [state, setState] = useState(false);

// Vue
const state = ref(0);

// Svelte
const state = writable();

// Solid
const [state, setState] = createSignal(0);

They all have a common pattern: they are convenient. But the convenience has a cost– it's so convenient that developers naturally hoist that's representable by ARIA attributes to JavaScript. Instead of embracing the platform, they get distracted by the convenience of the layer in which they are working, and end up with a solution that's not as accessible as it could be. It's not the framework's fault. Not all states are representable by ARIA attributes or should be represented by them. However, I think it'd be great to include a reminder in the documentation of these frameworks to consider ARIA attributes before reaching out to the framework's APIs. Like Enduring CSS does:

"While the specification is aimed at helping communicate state and properties to users with disability (via assistive technology) it serves the need of a web application project architecture beautifully. Adopting this approach results in what is (perhaps cringingly) referred to as a 'Win Win' situation. We get to improve the accessibility of our web application, while also gaining a clearly defined, well considered lexicon for communicating the states we need in our application logic." Enduring CSS - Chapter 6

I love how they put it. It's a win-win situation. We should not forget that the web is a powerful platform and that despite how natural it is to get distracted by the convenience of the layer in which we are working, we are ultimately building for users, some of whom might appreciate that we are building directly on top of the platform.

What I find fascinating about Elixir and Erlang, which Elixir is built on top of, is that their modeling of the world makes a whole set of problems disappear. Problems for which ecosystems like JavaScript, Swift, or Ruby have created a whole set of tools to solve them. There's no quote that better summarizes this than the one from Robert Virding, the co-creator of Erlang:

"Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang."

But how does it achieve that? I think the reason is rooted in their concept of processes. Everything is either a process or builds on the concept of processes.

There are many effects of processes in how you model your programs, but one that got my attention was how contracts can be mocked that easily without worsening the design of the code. In Swift, mocking very likely means that you need to introduce a protocol and use dependency injection to inject the mock. This is fine, and the ergonomics improved recently with the introduction of Swift Macros. Still, if you are writing integration tests, which in the case of Tuist deliver more value than unit tests, you'll have to pass the mock down to the deep-most layer of your code. And that makes all the interfaces unnecessarily verbose.

Let's look at a concrete example. We use swift-log for logging in Tuist. Seeing this piece of code makes me skeptical:

LoggingSystem.bootstrap(MyLogHandler.init)

The library is using a global internal state to configure the logging system. This is fine as long as it's thread-safe (which I assume it is) and you don't want to run test assertions against the logs and run the tests in parallel (which we do). There's an alternative to that. You can create an instance and pass it down to the layers that need it. But again, it hurts the ergonomics of the code.

let logger = Logger(label: "me.pepicrft.Logger")
doSomething(logger: logger)

Can't we have the best of both worlds? And that's something that Elixir solves beautifully with processes and that I wish XCTest would eventually adopt.

Every test in Elixir is a process. And processes have a unique ID. That process is known by the test logic and also by the code that's being tested, regardless of how deep it is in the call stack. What that allows is associating a mock with a particular test process. Let's look at an example using the Mimic mocking library:

# test_helpers.exs
Mimic.copy(Calculator)

use ExUnit.Case, async: true
use Mimic

# calculator_test.exs
test "invokes mult once and add twice" do
 Calculator
 |> stub(:add, fn x, y -> :stub end)
 |> expect(:add, fn x, y -> x + y end)
 |> expect(:mult, 2, fn x, y -> x * y end)

 assert Calculator.add(2, 3) == 5
 assert Calculator.mult(2, 3) == 6

 assert Calculator.add(2, 3) == :stub
end

Note how no dependency injection is needed. Calculator.stub and Calculator.expect only affect the logic in that particular test process. And you can safely run all the tests in parallel without worrying about the state of the mocks leaking between them and causing flakiness.

Will this ever happen in XCTest? I don't think so. XCTest would need to assign a unique ID to every test and expose it to the code that's being tested. Perhaps through some compile-time magic that's only available when running tests.

Note that the ergonomics might be improvable through dependency injection solutions, but I'm not a big fan of adding something that improves the ergonomics at the expense of making things obscure and introducing a dependency with a third-party library. The trade-off is not worth it.

Erlang, you are so cool.

To illustrate this, let me share my most recent experience. When I navigate the web, a pattern that I notice is that many websites that are designed with JavaScript frameworks are well designed. Today, in particular, I was amazed by how well-designed the websites made by the folks behind NuxtJS and VueJS are: Elk, NuxtUI, Volta, VitePress. Guess my thinking after seeing those websites? Is there a cause-effect relationship between the technology and the design? Or did developers with good taste happen to meet in those communities? Will technology like NuxtJS have a strong connection with a gorgeous design and a first-class experience in Glossia? Should I reconsider the decision to use Elixir now that it's early in the lifetime of the project?

These are the questions that I mentally navigate when I'm exposed to new technologies. And it's draining. I have to make an effort to look at things with enough perspective to realize that:

• Technology is an implementation detail. You can achieve a great design with any. - Distractions for the technology are a way to procrastinate on the problem. - The problem is the most important thing. The solution is just a means to an end. - Other factors are equally important when choosing a technology, not just the design.

I want to change my mindset to stop doing this because it's fatiguing. When I look around and see people that I admire, I see that they are focused on the problem and not the solution. They pick a technology that clicks with them and they stick with it. One of them is @dhh. He loves Ruby, and he is taking Ruby everywhere. @levelsio does the same with PHP. There are many examples in the Swift community too, like John Sundell.

Note that I don't want to isolate myself from other technologies. I learn a lot from them which I can use to cross-pollinate my thinking. However, I need to do it enough so that I can learn from them and not get distracted by them. This is where the challenge lies.

Have you experienced something similar?

Why explicitness you might wonder? When the graph is explicit and known upfront, you can validate, reason about, and optimize it. When it's not, you can't do those things. Or you rely on a closed-source build system that you don't control to do it for you. And if things go wrong, you need to file a radar and wait for Apple to fix it.

The worst part is that Apple is not reversing this trend. Instead, they are building on it and the Swift Package Manager is inheriting the same problems. For example, they realized that package products defining the static or dynamic nature of the library were a mistake that could lead to duplicated symbols. What did they do to solve it? They solved it with a new linking option, automatic, that's resolved at build-time. Why would you want a build system to make these important decisions for you? Your graph is yours. Tuist gives you agency over the graph while hiding the complexities that are not relevant to you, like the fact that some dynamic frameworks might need to get copied into the app bundle.

One of the issues that is particularly annoying, and that we are coming across often in Tuist's codebase is being able to import dependencies that are not explicitly declared. The issue is more apparent now because we optimize our workflows with binary caching. The reason why it happens is that the directory in which Xcode outputs all the project target products, DerivedData/{project}-{hash}/Build/Products/{config}, is visible to the other targets in the project. In other words, they can import them without having them declared as dependencies.

For example, let's say that you have a simple dependency graph A -> B -> C where A (App) depends on B (Framework), and B depends on C (Framework). If we do import C from A it'll work if we build the project through a scheme with the "Find implicit dependencies" enabled or if C has been previously compiled. For example via another scheme. What's particularly annoying about this is that the issues might arise on CI, or weeks later after weeks of CI workflows accidentally working.

This is an itch I'd like to scratch for Tuist and every Tuist user. I doubt Apple does anything, but I might be wrong. They are in a tricky spot because any step to remove implicitness would very likely break existing projects. It's the same for Tuist, but we can work closely with our users to define a migration path that allows them to transition to an explicit dependency graph. I believe once we do it, things will get more deterministic and stable for everyone. They won't most likely notice it, because teams don't have a metric to measure "how often implicitness caused headaches", but I bet it's more often than we think.

We hope to ship it as part of Tuist 4.0. Stay tuned!

• An app that's native to Apple platforms. Not native in the sense that it compiles to native. But native in the sense that it embraces the platform patterns and capabilities and doesn't try to fit web patterns into the platform. - Auto-linking of notes. We've seen a spread of technologies like embeddings that can be used to calculate semantic similarity between texts. Imagine using that for suggesting links between notes. - Inbox for ideas to process. Sometimes I'm running and I've got an idea that I'd like to jot down and process later into a longer note. I'd like to just press a button, record the idea, and have it transcribed into text. Or share content that I find on the web with the app for later processing. - A standard structure that's documented to allow users to port their notes and foster an ecosystem of apps.

The itch is becoming too itchy so I don't know if I'll be able to resist the temptation of building it myself as a hobby. Once we ship Tuist 4 and Tuist Cloud and have the business running of course.

Because Swift Package targets have now multiple platforms, we included the platforms that the Swift Package Manager indicates that are supported. And that works, until it turns out that a given package doesn't support a platform that they seemingly support (at least according to the defaults). In that case, Xcode fails to compile the target. To overcome the issue and eliminate blocks for users, we started adding code like if 'Firebase'... but that would not scale so we needed to do something about it.

Because Tuist knows the dependency graph, we cascade the platform of the project targets down to the dependencies. For example, if the upstream targets compile for iOS, we can narrow down the list of supported platforms for dependencies to iOS. I believe this is something that Xcode must be doing under the hood. The difference with Xcode is that they do it at build time and we do it at generation time.

This shows that assuming that a package supports all platforms by default was not a good idea. Especially when giving support for multiple platforms was not trivial due to inconsistent APIs across Apple and other platforms like Linux. This will hopefully change soon with the new era of Foundation, but until then, Xcode and tooling like Tuist will have to forever deal with this decision.

Please, if you are a package maintainer, make sure you are very explicit about the platforms that you support and that you validate that through CI. You'll be making a great favor to the community and to the tooling that depends on your package.

The first one of those events was the Shopify layoffs. For someone who has experienced layoffs before, and that has faced the realities of how businesses operate, that shouldn't have been a big deal. But it was for me. I over-committed to the company and the people I worked with, believing I was on a long-term and successful journey there. That's what they told me, and that's what I believed. But then one day, you are faced with reality. In my case, I was part of the German workforce that supported the unionization efforts. Workers understand their rights. What could be wrong with that? Everything. Techno-optimists and builders, as they like to call themselves, don't understand of anything that hinders their path to wealth and power. If there's something that gets in their way, they'll get rid of it, throwing money at it if needed. That reality shock led me to trace back everything that happened during my time there, and could see a different angle to the whole story. From the removal of the 'dropshipping' word from everywhere after having benefited from it for years, through the support of crypto and NFTs, to the green-washing of the company's activities. It was all a big lie. It felt like a toxic relationship that's hard to escape from and whose big picture you can only see once you are out of it. There's professional growth, but at what cost? I was let go with a mental exhaustion that I'm still recovering from. I couldn't look at other companies without wondering, will they be the same? I started to see patterns everywhere, like having a name for the family (e.g. "shopifolks"), or people continuously talking about how the company changed their lives for the better. I had huge respect for Tobi and his ideas, but I'm having a hard time buying into them now.

I felt so relieved when the layoffs happened, but you can't just get rid of the trauma that easily. It's something that comes back to you here and there. You try to look forward and stay positive, but you have this feeling that you can't trust anyone anymore. Has it happened to you? My escape was to focus on my projects, and in particular Tuist. We built a healthy community and project, in which we could continue to invest, and build something that we could be proud of and that people would be inspired to use and contribute to. I threw myself into the project, working full-time every day. I built a new website, put a plan in place for the rest of the year and started working on it, continued to help more companies get onboarded. People loved the project, and that love for the project fueled us to keep going towards a sustainability point where we could work on it full-time. But in that process, we made the project so financially attractive, that a company like Bitrise thought it was a great idea to wrap it into their product without contributing anything back. And here comes the second trauma. We had to make a quick decision to prevent them from hurting what had taken us 6 years to build. The result? A website telling everyone how terrible deciding for Tuist was, explicitly mentioning me as a bad maintainer for the project. If I didn't have enough with Shopify's micro-trauma, there is another one to add to the list. Luckily, I'm surrounded by great humans, among whom are my lovely wife, María José, my partner in Tuist and Tuist Cloud, Marek, and the Tuist community itself. They know me well, they know my values and supported me through this emotionally difficult time. Still, like Shopify, is that one thing that you can't get rid of easily.

I started feeling disillusioned with the often cruel reality of the tech industry. This disillusionment grew a lot of negativity in me, which often resulted in a lot of public criticism as if I could change anything by doing so.

But I'm working on changing that. Criticism does more harm than good to me. If there's something that has always been there, that motivates me to keep going and inspires me to build things, that's having a community of people that I can work with on solving exciting problems. And that's something that open-source provides me with. I'm a very community-oriented person. Building in isolation with the only goal of profit is not something that I enjoy. However, doing it sustainably is something to keep an eye on (thanks Bitrise for the lesson), and that's something that I'm working on. Open-source changed me. I met many wonderful and talented people, some of whom became friends. I see on Mastodon what open-source communities are capable of, and I feel I want to be inspired. When I'm in these communities, I feel I'm in a safe place and very positive. It's when I get closer to the tech industry, in its purest form, which is often on Twitter (X), that I start to feel negative. Perhaps the algorithms are contributing to that.

The micro-traumas of 2023 grew negativity in me, but I'm finding my way out of it thanks to open source and communities. I'll stop criticizing, and start building things that inspire positivity. 2024 is going to be an exciting year.

When it comes to styling, I've been following the Enduring CSS methodology. This provides answers for many challenges that CSS presents and embraces accessibility attributes to hold state leading to more accessible websites. Nevertheless, one challenge that I found, in particular in the context of Elixir and Phoenix, is that it's hard to follow the directory convention that they propose to get styles close to the components. Doing so requires using a tool that's able to resolve glob patterns to locate CSS files and bundle them into an output CSS bundle, and the tool that asset pipeline tool Phoenix projects use by default, powered by ESBuild, doesn't provide that functionality for CSS.

Luckily, there's a solution for that in the community: Lightning CSS. Yet, the integration into Elixir projects requires some tedious plumbing. Because I wanted to overcome that, and also scratch the itch of building an Elixir package. I built and open-sourced lightning_css. The interface is similar to the one that the Elixir's esbuild package proposes. You first configure profiles in your Mix project's configuration file:

config :lightning_css,
 version: "1.22.1",
 default: [
 args: ~w(assets/css/app.css --bundle --output-file=priv/static/styles/bundle.css),
 watch_files: "assets/css/**/*.css",
 cd: Path.expand("..", __DIR__),
 env: %{"NODE_PATH" => Path.expand("../deps", __DIR__)}
 ]

And then you can invoke it right from the terminal using the Mix CLI passing the profile, lightning_css default. In the case of Phoenix projects, you need some additional steps to integrate it into Phoenix tasks and watchers.

I still need to add some tests, which is another itch I want to scratch: getting familiar with Elixir's testing framework. However, I'll leave that for the near future. I'll adjust this website to make use of glob patterns, and start using it in Glossia, in which I plan to continue investing early next year.

Tuist is also draining me a lot. I'm excited about everything that's ahead, but the closer we get to the release, the further I feel from the finish line. And because I continue to work on it full-time without a salary, this is drilling my brain. Not that I don't have savings, but not having a source of income makes me mentally uncomfortable. And the recent Bitrise events didn't help. Someone who has been in business for longer might think this is normal, but I'm not yet emotionally prepared to deal with this type of competition moves. I might go to therapy when I'm back in Berlin to learn how to deal with this.

Besides all of this, I think my relationship with social networks is not helping. I think it's important to continue to be present on X and Mastodon because that's where the users of Tuist are. But at the same time, it's a huge mental stretch to my list of responsibilities in the project: development, support, community engagement... Also, being on X and Mastodon triggers many thinking streams. Is it positive? It is, I get many ideas from it. But if I don't limit the bandwidth that I dedicate to it, it can be overwhelming. I get ideas that I'd like to play with, but I don't have the time for them. I can go from excitement to exhaustion from one day to another. When I'm exhausted, my natural reaction is to disconnect from everything.

I'm also emotionally processing some surprising realities that I learned about the tech industry by accident. One of them is everything that happened at Shopify. It was in May, but it continues to be a recurring thought in my mind. I feel lied and a chip in a game of billionaires. I worked hard towards some professional growth that was all a story to get me to overcommit to the company. I know it won't happen again, but I can't avoid feeling bad about having fallen into that trap. The other one is the exploitable nature of open-source, which I suffered through Tuist. Because open source exists within the tech industry, and the tech industry exists within capitalism, where companies have no obligation to give back to society, they treat open source as a free resource that they can exploit. Companies can go as far as to tell everyone that you are a bad person because you are taking steps to protect yourself from that exploitation. This is tough to process emotionally.

There might be other factors contributing to these emotional swings, but those are the ones I'm the most aware of. I suffer from mental health breakdowns from time to time, and I think it's important to share them. When I feel down, I take a break from everything and use the space to reflect on what's happening. I also make sure exercising is part of my routine. Even though I don't run as often as I used to, but doing casual runs helps me to clear my mind.

Xcode builds on the Xcode build system, which works with Xcode project files. As the environment changed and things became more complex, Xcode project files were stretched beyond their limits and presented developers with a lot of challenges. Some examples of those are frequent Git conflicts, invalid dependency imports implicitly resolved, and frequent clean builds that make developers lose their time. This is the day-to-day of many developers, or at least it was and is mine when I use Xcode with a modular project.

Apple failed to evolve the project files and the build system that builds on it.

They left the community with only one API to overcome challenges: project generation. This is not great and tells a lot about the foundation. CocoaPods pioneered this approach, and then project generations like XcodeGen and Tuist followed. Most recently developers started to use the Swift Package Manager, which Apple integrated tightly with Xcode, to overcome the most pressing challenge, frequent Git conflicts.

But the matter has gotten worse. We have now a fragmentation of dependency management solutions, and many organizations are struggling to move from CocoaPods because it provides a level of extensibility and configurability that the Swift Package Manager doesn't. The same implicitness that Xcode had, and that caused many problems to developers, is now making its way to the Swift Package Manager, like the "automatic" linking mode that Swift Packages now has. Since when is the build system's responsibility to decide the linking of a dependency? Optimizations? Not even think about them. It's Apple's responsibility. If the integration with the Swift Package Manager is suboptimal, you have to wait for Apple to fix it. I'm sorry, but this is too bad.

Apple built a package manager and faced a community using it as a project manager because they were tired of Xcode project issues.

Apple is now in a difficult spot, but one they could move from with support from the community and a clear vision. I think they've reached a point where they need to go back to first principles and evaluate the foundations of the platform. Is it time to evolve everything that's around the Xcode project files? I think so. It's time for the build system to be something closer to what Gradle or Bazel are. A build system that's deterministic, configurable, optimizable, extensible, and overall, easy to reason about. If the convenience that they need for the people getting started is a concern, they can always build a layer of convenience on top of low-level primitives. Android has done that with Gradle. You drop a plugin, and that takes care of everything for you. And if you need to, you can peel layers of complexity.

But there are no signs of that happening. Chatting with developers at the Swiftable conference, I noticed that developers are more confused than ever. They want to use the official tools, but while doing so they realize that they add more complexity and challenges to their problems. It's positive for Tuist, because it's a huge opportunity for us to help them, but I feel really bad for those development environments that are not fun to work in. I was in one of them, and you know what leadership decided to do? Move away from native development to React Native. Simply because leadership doesn't understand that you need to wait an entire year to hopefully have Apple fixing the productivity problems. It's bizarre when looked at from the productivity angle.

I know put a Project.swift next to every package or in every new project that I create. Why? Because the productivity levels that Tuist provides are unmatched. If you haven't tried, I encourage you to do so. You can clone the Tuist repository and play with it. Hopefully, there'll be one day where we won't need project generation anymore, and we can move our optimizations to a more sophisticated build system. But until then, project generation is our answer, and it works damn great.

• Find a template that I like on the Internet. - Learn about the framework the template is powered with (often JavaScript-based). - Adjust content and structure accordignly. - Publish

Did you know that this website has been implemented with technologies like Gatsby, NextJS, Jekyll, Rust, Phoenix?

Sometimes the technology decision was driven by a technology I was getting excited about, like it's the case with the current iteration of this website, which is implemented with Phoenix and Elixir. Other times, it was driven by the template that I'd found–Tuist's template drove the decision to use Astro. Playing with all these different technologies is a lot of fun. Nonetheless, it seems to come at the cost of making projects less future-proof in part, due, in part, to the high stack of layers (abstractions and tools) they build upon. We make the web, a platform that's designed to be backwards-compatible, feel quite the opposite, a platform that breaks more often than not.

I get that abstractions and tooling are necessary. For example, to generate HTML pages at build or runtime from templates and content. However, I can't avoid but wonder if we might sometimes be going too high in the stack. This is a question that I find particularly interesting. It's in fact one of the reasons why I like following the Phoenix and Ruby on Rails ecosystems closely. Their love for the web as a platform makes them question every abstraction that arises. I find somewhat some-provoking the swing of the pendulum from the server to the client with SPAs, and recently back to the server but with the additional legacy that they've accumulated in the swinging. React Server Components is a good example of that. They are back at the server, but with a vast list of NPM packages with components that make assumptions about their rendering. It feels wrong. Another one is Tailwind, which has gone from being a tool to being a layer on which entire design systems and templates are built. All you want is to add a design system to your project, and then you find yourself having to integrate the Tailwind toolchain into your stack. Why?

Some organizations and developers might like that working setup. I completely understand it. But I decided that I'm doing the opposite. I'm diving deep into understanding the web platform to peel layers of abstractions and build projects that are more future-proof and easier to maintain. Recent conversations with Marek, about the approach we'd take for Tuist Cloud, inspired me to embrace this philosophy. Here's a list of principles and ideas that I embraced in this website and that I'll embrace going forward:

• Only build tools that are strictly necessary: For example, no ESBuild and no Tailwind. Recent standards and browser capabilities reduce the list of scenarios for which you needed build tools. - Plain CSS: There isn't really a need to learn a new layer of semantics that fill HTML elements with endless lists of utility classes like the ones that Tailwind proposes. CSS has evolved a lot and provides solutions for the problems that led to the emergence of utility-class frameworks like Tailwind. CSS is the abstraction itself, and I can achieve consistency via CSS variables, some of which I can take from the wonderful Open Props. - Web components: Web components are supported by the evergreen browsers. If you create a web component, you can rest assured that it'll work forever. The same is not true in use-a-bloated-JS-rendering-technology, where you might need to allocate time in a year or two to adopt a framework, because the technology says it's the recommended way to develop with it, or updating your components to adapt to breaking changes. - Embrace HTML semantics: I used to be that developer that 'ed everything making my websites very inaccessible. Now, the first thing that I do is trying to get the semantics right while keeping the design aside. Then, I bring the design into the equation using ARIA attributes to store state, as suggested in the Enduring CSS methodology.

The new iteration of this website no longer depends on ESBuild and Tailwind, and uses web standards. Note that the design is simple by design, not by the simplification of the underlying stack. The only dependency is on Elixir and Phoenix, which are responsible for running the HTTP server that serves the website. Can I make it more future-proof by scripting something myself in JavaScript? Definitively. It can be a built-time-generated static website. However, I might add some server-side things down the road, so I'd rather keep the server piece, ensuring I use technologies like Phoenix that embrace the platform instead of abstracting it away.

It's been an elightening process that has shown me how powerful the web platform is. I'll follow the new ideas that abstractions bring to the table, while I slowly build on the lowest layer available.

bash <(curl -sSL https://url-to-server.com/assert.sh) 1

1 is the number of the section that they just completed. Note how convenient it is to run it because you only need bash in your system, which is a safe assumption to make. I believe the fewer system requirements for the workshop and everything that surrounds it, the better. As a fallback, I provide a Git repository and a commit sha at the end of every section that developers can check out to continue with the workshop.

I'll test the method in a couple of weeks and report back.

This experience has taught us to approach our projects with a renewed perspective, particularly considering the significant impact they have on mental health and motivation. These human aspects are crucial to the wellbeing and innovation of the project. My deep-seated passion for Tuist’s problem domain has driven me towards mastery, a trait I share with other maintainers. However, an exclusive focus on mastery can lead to an imbalance, potentially risking the project's long-term sustainability. It is encouraging to see individuals and organizations prioritize mastery over profit and growth, but the challenge arises when the system fails to support individuals financially. Therefore, designing and implementing a supportive framework within the project is imperative.

This task is inherently challenging. Any evolution from a well-established model is bound to encounter resistance. Looking back at the inception of Tuist, I ponder whether I could have anticipated the system's current needs. At that time, the project's future was uncertain, with no user base for over a year. In hindsight, there was certainly room for improvement, but my intense focus on the craft limited my foresight regarding the system’s evolution. Observing projects like Sourcery and Sourcery Pro, it’s intriguing to see the acceptance of open-core models contrasted with criticism of open-source projects evolving toward that model.

We acknowledge our imperfections and embrace the learning curve ahead. Our conviction in our decisions remains strong, and we are prepared to learn and pivot as needed, as we have over the past five years. Currently, we are focused on a major update for Tuist, signaling a new and significant phase in the project's journey.

Today, I find it necessary to speak about the recent attack directed at our beloved Tuist project. Our journey with Tuist has been one of unwavering dedication. Over the past five years, we have poured our hearts into it, working tirelessly during our free hours. Our commitment led us to develop tools like XcodeProj, integral to many in the ecosystem and crucial for systems like Bazel, which you are now steering users toward. We've not only facilitated the integration of Tuist with your CI services but also recommended speakers for your events.

In our community, we've always extended a helping hand to those facing challenges, focusing on support over financial gain. Our approach seems to differ starkly from yours.

Embarking on the Tuist journey, we underestimated the incoming demands for support and the sheer volume of requests. This is a common scenario for open-source maintainers, often leading to burnout, a situation we have strived to avoid. Your approach, seeking a PR merge without having contributed a single line of code to Tuist, appeared more self-serving than community-focused. It added to our workload, contrary to your public image as an advocate for open-source.

The reality of Tuist's demands became clear – it needed dedicated, full-time attention. Here, we faced a financial dilemma. Donations, which are always welcome and channeled towards bounties, weren't enough. Investment wasn't a viable route either, as it often brings profit-driven motives that could jeopardize the essence of our project. Our independence from such influences allows us to focus solely on our user community's needs and challenges.

Introducing Tuist Cloud was our strategic response to this need for sustainability. We've designed Tuist to minimize vendor lock-in, a detail you may have overlooked given your limited engagement with the project. Users can easily migrate away by committing their Xcode projects and dropping Tuist, a feature common to most tools, Bazel and Bitrise included. However, we choose not to retaliate by suggesting alternatives like GitHub Actions.

Tuist Cloud began as an open-source endeavor until we realized that this path wouldn't lead to sustainability. Comparisons with well-funded projects like Bazel are misplaced; unlike these giants and not so giant, we lack substantial financial backing. Your actions, increasing our burden and publicly undermining us, were a blow to our efforts.

We're now developing Tuist Cloud as a closed-source extension for Tuist, a decision forced by circumstances, not choice. Our aim is not to perpetuate closed-source development but to find a sustainable path forward. The distinction between Tuist and Tuist Cloud lies in the realm of project generation versus optimized project generation. We urge our users not to be swayed by fear-mongering about Tuist's future.

Our commitment remains steadfast to a project and community we deeply care about, facing the challenges ahead, and gearing up for major releases. For those in doubt, we encourage conversations with our users to see the value and dedication we bring to the table.

Warm regards, Pedro

P.S. Bitrise, we've noticed that you've set up redirects on your pages, funneling readers to a blog post casting Tuist in a negative light. This includes the now-missing comparison page, which previously claimed your service's superiority over ours. Removing this page appears to be an attempt to hide the full story.

Given the suboptimal experience offered by Apple's ecosystem, which precludes optimization opportunities, Tuist employs SPM to resolve packages before mapping them onto Xcodeproj elements. While generally effective, this approach has encountered occasional setbacks, which developers can rectify by tweaking the build settings of the generated targets. Yet, it has not supported Swift Macros since their announcement.

Interestingly, developers managing Xcode rules for Bazel quickly devised a method to accommodate Swift Macros using compiler flags. Inspired by this, could Tuist adopt a similar strategy by utilizing targets, dependencies, and build settings? After some investigation, the answer is affirmative. Here's the blueprint:

The macro's representative target must be a macOS command-line target, encompassing the macro's source code. A secondary, dependent target is required, hosting the public macro definition for import by other targets.

Targets wishing to leverage the macro should: - Establish a dependency on the secondary target for prior compilation. - Include the setting OTHER_SWIFT_FLAGS with the value -load-plugin-executable $BUILT_PRODUCTS_DIR/ExecutableName\#ExecutableName.

This setup is contingent upon the secondary target and the dependent targets producing their outputs in the same directory. If that's not the case, SWIFT_INCLUDE_PATHS will be necessary to make the module available to the dependent targets.

With this mechanism uncovered, the next step is to integrate it into Tuist's Swift-based DSL and combine it with our binary caching feature. This integration will enable developers to concentrate on targets dependent on macros without the overhead of compiling the macros themselves.

We also chose to implement the acceptance tests in Ruby. We believed that the BDD approach, as proposed by Cucumber, would be most suitable due to its ability to produce very readable scenarios and prevent the tests from being aware of the Swift implementation details.

In hindsight, it was a mistake, and we are already taking steps to rectify that.

The main issue is that it introduces friction to the experience of contributing to the repository for the first time. In addition to Xcode, which we can safely assume developers have on their systems, they need to install the same version of Ruby that everyone else is using (to avoid inconsistencies), remember to run bundle install to pull dependencies such as Cucumber, and, not least, feel comfortable diving into Ruby code when things don't work as expected. Many developers may not have used Ruby before, and this task can seem very daunting, resulting in them relying on us—the maintainers—to resolve issues.

We also noticed considerable hesitance towards writing the tests. Beyond the fact that some steps' implementations needed to be done in Ruby—a task they could manage by referring to other steps—the Regex-based step definitions were also a bit intimidating. Once again, it was we—the maintainers—who would end up writing most of the tests.

So, what are we doing about it? We're removing Ruby from the codebase and integrating everything tightly into Xcode. We are eliminating the Fourier CLI and replacing it with universal bash scripts that require no additional tooling, some of which can be invoked through make. ChatGPT has been quite helpful here, as I'm not at all comfortable writing business logic in bash. We are also rewriting our acceptance tests in Swift so that they can run in parallel using Xcode and SPM. Developers will be able to execute these tests directly from Xcode and even add breakpoints to debug execution. This change will not only enhance the working experience with these tests but also create a faster feedback loop. This transition has been challenging because PRs took a long time to be ready for merging.

I am eagerly awaiting the implementation of these improvements. It's easy to make incorrect decisions like these, but it's crucial that we periodically reflect on them and adjust our course if necessary—and that's exactly what we are doing.

While I was at SoundCloud, the organization didn't adopt Tuist until after I had left. Later, at Shopify, I attempted to introduce it to address challenges they faced with Xcode. However, there was strong advocacy for using only Apple's official tools, so adoption didn't happen. Interestingly, the company eventually transitioned to React Native. While at Shopify, I hired developers I met through Tuist. This led many to assume that Shopify used Tuist and sponsored me to work on it full-time. In reality, I could only dedicate my spare time to it, and as time progressed, it became increasingly challenging. Eventually, Marek and the core team took over some responsibilities because I needed a break.

Throughout this period, word of mouth was effective. Companies initially approached Tuist for project generation but stayed for the additional features. Today, numerous organizations prefer Tuist over XcodeGen as they recognize that Git conflicts aren't the sole challenge of scaling. Defining Tuist is challenging; while many see it simply as a generator, it's much more. We eventually realized that we had laid the foundation for significant optimizations and an integrated development experience.

The project's popularity surpassed our expectations. With the increase in users came a proportional increase in time and effort. Continuing on our personal time risked burnout, which I wanted to avoid both for myself and other dedicated contributors.

So, what next? I researched open source sustainability models to determine what would fit Tuist best.

One idea was to limit Tuist's scope to easily maintainable features given our team size. But this would disappoint many users by reducing the tool to just project generation. Although this feature is reliable, extendable, and only requires major updates with new Xcode releases, we decided against this route. Users love the unique extensions that enhance their productivity with Tuist.

While we were eager to have full-time contributors, donations didn't suffice. They covered some costs but weren't substantial enough for salaries. We're immensely thankful to our sponsors for their support.

One potential path was to join a large tech firm, similar to Fastlane. However, such partnerships often prioritize corporate interests over solving real problems. In Fastlane's case, data became the focus under Google's ownership. I also contemplated offering consulting services, leveraging our expertise. But the reception was lukewarm as most companies had either already transitioned or found their answers online.

We then considered models from similar tools, like Gradle and Nx. These tools offer server-side paid features for advanced requirements, which seemed fitting for Tuist. Thus, we began working towards this model, even initiating the process of setting up a legal entity in Germany, Tuist GmbH.

Simply put, if you need project generation, Tuist aims to be the best at it. For optimizations, we'll introduce paid features, priced reasonably in comparison to the benefits they offer.

However, challenges emerged. A prominent Mobile DevOps company, Bitrise, launched a service for Tuist users, requiring a Tuist fork. This experience taught us the complexities of business dynamics. We had previously communicated our intentions to them, so we decided to develop certain client features privately. Our goal remains to return to open source, but first, we need to ensure the project's sustainability.

Another issue was that some organizations bypassed payments for Tuist Cloud. While we tried to stress the importance of financial support, some viewed it as optional. Consequently, we're implementing measures to counteract these workarounds.

There are more discussions ahead, but this new phase for Tuist is crucial. We want to ensure that Tuist remains faithful to its core values and principles, delivering consistent value sustainably. Sustainability is central to Tuist's success, and I'm committed to realizing that vision.

Our journey in developing Tuist wasn't an easy one. We juggled multiple roles, from coding to marketing, writing to community support. Each hat we wore was worn out of faith in Tuist and its potential impact on the development community. And let's be clear: this is only the beginning.

The journey took six years, primarily because it was a side project for us. But imagine the strides we could make if we dedicated our full attention to it! Tuist is more than just a tool; it's a foundation that equips developers with essential tools for sustainable growth. I'm often perplexed as to why Apple hasn't addressed certain metrics:

• How frequently do developers need to perform a clean build after encountering a compilation error? - How long do targets take to build or tests take to run? - How frequently do tests fail, and can they be automatically disabled when they do?

Apple seems preoccupied, perhaps grappling with legacy decisions in Xcode, while continually rolling out new language features and APIs. While these features are exciting for small projects, they're less so when projects scale up, revealing Xcode's limitations. At this juncture, organizations often either waste time battling these issues or divert to alternative solutions like React Native. The good news? Other ecosystems have already tackled these challenges, and there's much we can learn.

For us, this represents an opportunity. An opportunity to offer a seamlessly integrated solution. When observing the tools aiming to integrate into developers' workflows, it's evident that many setups are convoluted. The ideal experience for developers is simplicity. They should execute a command and have everything work seamlessly. Sadly, Apple doesn't provide the necessary APIs for a smooth integration into Xcode. Many tools lean on Fastlane, bringing along the complexities of Ruby, Bundler, and more. With Tuist, all you need is Tuist and a project defined through it.

The future for Tuist Cloud looks promising. We've laid a solid foundation and cultivated a community that genuinely believes in our mission. As we move forward, we'll introduce exciting features. From boosting developer productivity to providing actionable insights and even automating tasks for developers, the possibilities are boundless.

In summary, while Tuist Cloud is still evolving, the hardest part is behind us. We have a firm foundation and a dedicated community. Now, it's our turn to supercharge Tuist and empower development teams to foster thriving environments.

While my mental models are instinctively oriented towards objects and classes, envisioning an ideal—or even a proximate—solution in Elixir poses a challenge. A strategy I’ve adopted to navigate this is to think in terms of domains instead of the traditional OOP mental model. Consider the following Elixir functions that interface with a %Plug.Conn{} to manage session information:

Auth.set_authenticated_user(conn, user)
Auth.get_authenticated_user(conn)
Auth.user_authenticated?(conn)
Auth.load_authenticated_user_from_session(conn)

This code, expressive and reflective of real-world modeling, underscores one of Erlang creator Joe Armstrong’s points from his renowned paper: the proximate modeling of problems and solutions in Erlang, analogous to real-world scenarios, enhances the maintainability and reasoning of the software. Adopting this mindset is pivotal and necessitates the relinquishment of numerous concepts ingrained from OOP.

Moreover, abandoning these concepts also means recalibrating practices built upon them, such as testing. Traditional architectural solutions enable isolated testing. For example, testing business logic without the concern of data origin, since we might mock a repository. However, in the functional realm of Elixir, where every entity is a function or a function combination, the narrative is distinctly varied.

Consider a hypothetical scenario: testing a function combination that symbolizes a slice of business logic, which is more user-centric as opposed to stating, "when I call this function with these arguments, I expect this query to be executed to the database". My journey through various codebases has occasionally led me to allow inertia to dictate, perpetuating historical practices. Yet, the pertinent question that perpetually surfaces as I script in Elixir is: Do these tests make sense? Is it logical to test whether storing the authenticated user appears in a specific key inside the connection assigns? Or, would it be more valuable to test, for instance, whether a specific request, requiring user authentication, fails with a designated error if the user is not authenticated?

In conclusion, as I savor my Saturday morning coffee ☕️, Elixir continues to captivate me. The challenge of mentally rewiring to adapt to its distinctive paradigms is not only intriguing but also refreshingly fun.

Navigating through this journey of developing Tuist, whilst seeking a viable path to support my family and me, has been a profound exploration. It's not just about discovering solutions for myriad challenges users encounter with Xcode, but also about weaving a tapestry of sustainable development that resonates with community ethos and altruistic collaborations.

In a world where every digital step is entwined with ethical considerations, especially in our endeavour to sustainably develop Tuist, we tread cautiously. While our project is shielded with a permissive license, the ethical dialogue it intertwines with is both vital and delicate.

At times, miscommunications happen. Perhaps in their zeal to contribute, some may overlook the underlying struggles and aspirations of our team, attempting to harness Tuist’s capabilities for their gain, somewhat overshadowing our journey towards sustainability. It's conceivable - maybe they were unaware of our aspirations to immerse ourselves full-time into Tuist's development? Always leaning into a belief in others’ good intentions, this was a possibility I considered. But understanding evolved through conversations, revealing a knowing that was deeper and more informed.

Despite these revelations, we've witnessed actions that teetered on the edge of ethical bounds. Navigating through instances where our sustainability initiatives, like Tuist Cloud were contrasted unfavorably against services of investor-backed entities, was indeed a challenge. But herein, we also found a spark – an ignition of resolve to protect and nurture the sanctity and future of Tuist.

In a realm where open-source projects, like Fastlane and Rails, have found sanctuary and sustained development within large organizations and dedicated teams, Tuist weaves a slightly different narrative. The likelihood of a dedicated Tuist infrastructure team materializing within an organization may appear slim, yet what pulses brightly within us is an unbridled passion for problem-solving and innovation within this domain.

So, here we stand, at a pivotal crossroads, choosing to develop the client-side functionality that fuels Tuist Cloud in private, at least until we solidify our path to project sustainability. This decision, forged in the crucible of challenges, is imbued with hope - hope that this enclosure is merely a temporary phase, and that we’ll soon fling open the gates to a reservoir of source value once more.

Even as we navigated through the echoes of bold business moves that nudged us unexpectedly, our commitment to positivity and innovation has remained unwavering. Now, we’re not merely players, but steadfast contributors to a different league, an evolved narrative of inspiring sustainable open-source development.

To you, our cherished Tuist users, let your hearts be light and assured. In the embracing and indomitable spirit of us - the people that breathe life into Tuist - you have a trustworthy companion. As we untangle the threads of this challenge and reweave them into a tapestry of innovative solutions and sustainable practices, the horizon looks even more radiant and promising.

There’s an entire universe of solutions we're eager to explore and implement, and with an evolving framework that hopefully allows us more dedicated time for Tuist, this will change, blossoming into a reality where our collective dreams and innovations converge, uplifting and empowering each one in our community.

Together, in unity, innovation, and ethical collaboration, let's continue to co-create, inspire, and elevate Tuist into realms where technology and ethical sustainability dance in harmonious synchrony.

You might think you won't ever have the need of thinking about scale, but let me tell you that you will. Scalability is not only about the size of a project but also about the breadth of it. The moment you decide to support multiple platforms, for example, iOS and watchOS, you'll most likely want to reuse code across targets. This is achievable through shared targets, which introduce you to the world of dependencies that I discussed yesterday.

Configuring a modular Xcode project, including its external dependencies, is a tedious and error-prone task. If Apple's platform were dynamic like NodeJS, we wouldn't even have to think about the problems I'm going to talk about because modules are dynamically resolved and loaded. Unless you make some node_modules-like design decision, and you find yourself in a spot that's difficult to move away from. What that means is that the build process is more involved, and the build system and the mental models it works with are more intricate.

If you have built for the Apple ecosystem for a while, you've most likely faced the issue of "duplicated symbols" or apps crashing at runtime because there's a dynamic module that hasn't been copied into the final product (i.e., "framework not found"). Those are hard to debug, aren't they? I became so weirdly obsessed with understanding them that I decided to build Tuist so that no one would have to do it themselves manually. The problem is that when Apple recognized that it's not trivial, and the number of use cases that we need to handle in Tuist's codebase is a good proof of that, they decided to go down the path of convenience and enabled some implicit settings. What does it mean in practice? There are several places where one can experience that, but the most obvious one is Apple being able to detect target dependencies by looking at who outputs a .framework into a directory that's exposed to our target through the framework search path. Isn't it cool? It is, until it's not. What works for the developer that's getting started, whose dependency graph is small, doesn't work in slightly larger projects where there's a mix of static and dynamic frameworks and libraries. And the matter keeps getting worse because Apple doesn't cease to add new target types. For example, there's now Swift Macros and Build Tools.

So, in order to solve the problem, we had to start by making the implicit explicit. And the core-most element that required that explicitness was the dependency graph. One might think that the dependency graph refers only to external dependencies, but with it, I'm also referring to the targets that are part of your project - some dependencies are local, and others are remote. They are all dependencies. So when you look at Tuist's DSL, you'll notice that it made dependencies front and center. The build settings and phases that are required are an implementation detail. If a dynamic framework needs to be copied, we know and configure things properly. The same is true for when the right binary of an .xcframework needs to be selected for the target that's linking against it. As mentioned earlier, the scenarios are endless, and you really don't want to be doing that yourself.

The problem is that Apple doesn't reconsider the implicitness path, which in my opinion is a terrible design idea. At least if we think of a future where apps are multi-platform and very modular, which I think is realistic to think about. A good example of that is that the integration between Xcode and the Swift Package Manager is also very implicit. Xcode's build system and the Swift Package Manager are both communicating and making decisions at build time to keep things convenient. Just flag Swift Packages to be automatically linked, and Xcode will do it for you. Until it doesn't, or the experience is laggy and slow, and you can't do little about it.

I met with a developer over a month ago, and we chatted a bit about their transition from Tuist to Swift Package Manager, and they found themselves very limited by the optimization opportunities that the Swift Package Manager offers. I'd be surprised if they can change that without going back to first principles because they should even start with questioning whether a compiled language, Swift, is the right tool for the job. When we look at more advanced systems, we see dynamic, fast, and functional DSLs being the common denominator. Xcode's build system should probably be closer to what Gradle is for Android. From all the things compiling Swift could offer, like sharing code across manifest files or coming up with with abstractions, they only use type-related capabilities.

Apple appears to be hindering their own progress. While they've streamlined basic tasks, they've concurrently made more intricate ones seem unattainable. This puts developers in a quandary: how can they discern these limitations when Apple doesn't offer comprehensive insights from its tools? Often, developers only recognize these constraints when faced with them directly. Consequently, many organizations either pivot towards alternatives like React Native or undertake the daunting task of overhauling the entire build system. I encountered this firsthand at Shopify. Despite my persistent efforts to highlight the unsustainability of their unwavering reliance on Xcode, I was met with staunch opposition, culminating in a top-down directive to transition to React Native.

It's not an easy problem to solve, but I believe it's a problem worth solving. They should consider layering their tooling such that there's a very low extensible layer without convenience or implicitness that developers can build upon and extend. And then another layer on top of it that's the one that provides the convenience and says "we are trying to be smart to help you stay focused." Right now, there's a single layer that stretches too broadly and is more of a hindrance than a help. Xcode would know how to contract with those layers, and alternative build systems like Bazel or Gradle would have the possibility to swap pieces as needed.

As someone trying to help solve this problem, I find the whole situation very frustrating. It's frustrating because everyone gets eclipsed by what Apple proposes, and they are unable to objectively decide whether that's a good idea or not. Hence why I'm writing blog posts like this one. Hopefully, one day Apple goes back to the root and rethinks the build system. I personally believe the Swift Package Manager path is not the way.

During a recent bout of unemployment, I found a quiet moment of clarity to understand the roots of my exhaustion. Today, I'm opening my heart to share what I've unearthed and the measures I'm taking to reclaim my mental peace.

When I share my daily tasks with friends, their eyebrows raise in surprise at my seemingly endless activities. But here's my confession: building software isn't just a job for me, it's a sanctuary. Just as an artist finds solace in their brushstrokes, I find joy in coding. It's a family trait, I believe. My parents and sister are ceaseless whirlwinds of energy, and pausing what they love would be like caging a free spirit. I cherish the moments of creativity my craft brings me, ensuring I balance my passion with rest.

However, another culprit silently contributed to my mental turmoil: my dwindling exercise routine. Once, the rhythmic pounding of my feet on the pavement was my daily ritual. Yet, I let life's distractions coax me away from it. But every time I return, like my recent run through the familiar paths of Cieza in Spain, I'm reminded of the mental clarity it grants me. So, I've made a pact with myself - daily exercise, with occasional breaks.

Diving deeper into my daily life, I noticed a pattern. My attention flitted like a restless butterfly: from Slack to coding, coding to email, email to countless other tasks. These ceaseless shifts became second nature, feeding my anxiety. To counteract this, I now set specific times for checking emails, social media, and other apps, training myself to relish moments of stillness without the lure of aimless scrolling.

I've also introduced a faithful companion to my life: Todoist, a TODO app. Before, I tackled tasks as they appeared, like a ship swaying with the tide. Now, I pen down every thought and prioritize tasks each evening, setting clear intentions for the next day. Adopting this methodical approach has been a challenge, given my instinctive chaotic nature, but its promise of a calmer mind drives me forward.

Coming to terms with the fact that life's to-do list is ever-growing has been a revelation. My labor of love, Tuist, always has a fresh challenge. But I've learned the art of setting boundaries, prioritizing mental well-being above all. I've also carved out pockets of time to indulge in tasks that might not be 'productive' but nourish my soul.

These changes, though recent, have begun to mend my mental fabric. I now greet evenings with a clearer mind and a more present heart. My journey is still unfolding, and I remain a student of life, always eager to refine my ways. Sharing my story here is my way of reaching out, hoping my experiences might resonate with someone else. If you've carved your path to mental well-being, I'd love to walk a mile in your shoes and learn from it.

Take, for example, the typical module structure in such a setup:

defmodule MyModule do
 @behaviour __MODULE__.Behaviour

 def hello(name) do
 application_env_module().hello(name)
 end

 def application_env_module() do
 get_in(Application.get_env(:my_app, :modules), [:my_module]) || __MODULE__.Implementation
 end

 defmodule Implementation do
 @behaviour MyModule.Behaviour

 def hello(name) do
 "Hello #{name}"
 end
 end

 defmodule Behaviour do
 @callback hello(name :: String.t()) :: any()
 end
end

In this example, MyModule serves as a facade that selects an appropriate module based on the application environment configuration. If a module atom is specified, it's utilized; otherwise, the code defaults to the built-in implementation. However, this structure has some downsides:

• Boilerplate code that acts as a proxy to the underlying implementation could be automatically generated. - The method application_env_module and related naming conventions can become inconsistent across the codebase.

To tackle these challenges and experiment with Elixir macros, I created a new package for the Elixir ecosystem named modulex. With this package, the previous example can be refactored as follows:

defmodule MyModule do
 use Application.Module

 defimplementation do
 def hello(name) do
 "Hello #{name}"
 end
 end

 defbehaviour do
 @callback hello(name :: String.t()) :: any()
 end
end

Notice how much more concise and ergonomic the code has become. I chose to prioritize convention over configuration, thereby standardizing the naming of child modules and the keys within the application environment.

For those who use Mox or Hammox for mock definitions, you can easily set a mock like so:

# test_helper.exs

Mox.defmock(MyApplication.Module.mock_module(), for: MyApplication.Module.behaviour_module())
MyApplication.Module.put_application_env_module(MyApplication.Module.mock_module())

I'd love to hear any feedback on the implementation or the API design. This is my inaugural venture into Elixir macros, and the journey has been both rewarding and a process of trial and error.

Strangely enough, pursuing money doesn't fulfill me. I recently attended an AI Meetup in Berlin, and left feeling hollow. The majority of conversations revolved around financial pursuits - raising capital, monetizing ideas, or selling startups. Shockingly, there was little to no discussion about the human-centric problems the showcased technology aimed to solve.

Ideally, I'd like a steady stream of income that lets me forget about financial woes altogether. But attaining this requires adopting a business-centric mindset which doesn't resonate with me. Wouldn't it be wonderful if financial stability was the byproduct of quality craftsmanship? This was evident with Tuist. A simple change on the website, showcasing logos of companies using our platform, suddenly piqued the interest of many. Ironically, this value was constructed without a monetary focus. Isn't that paradoxical?

A recent endeavor of mine is Noora, a design system for Glossia, powered by Elixir and inspired by prominent JavaScript design systems. I recognized the superior design systems in JavaScript and felt it unjust for users to integrate additional complexity into their stack merely to access these systems. With Glossia in mind, I opted to embed this into its core and make it universally accessible. This also gave me a chance to delve deeper into Elixir macros. While such endeavors may not directly boost Glossia's profitability, they refine the craftsmanship, enhance the product, and nurture a community - potentially drawing Elixir enthusiasts towards Glossia. A parallel can be drawn with Shopify and its significant contributions to the Ruby community, now a haven for Ruby developers.

Reflecting on this, I believe such an approach is what sets Tuist apart. It's a project that oozes humanity and is primarily fueled by passion. Introducing a financial element is a necessity, a means to an end. My earnest hope is that once I reach that financial comfort zone, I can continue to revel in the sheer joy of craftsmanship. I wonder if others resonate with these sentiments? I'd be keen to hear your perspectives.

For newcomers, here's a quick sketch: Tuist began as a beacon for developers crafting apps for Apple's platforms using Xcode. It sprung from a desire to simplify and enhance Xcode project scalability. Today, it's not just a tool; it's a foundation. While I had dabbled in open source before, Tuist eclipsed them all in popularity. So, what made Tuist stand out?

At its heart, Tuist was conceived out of profound passion. The challenges we wrestled with at Soundcloud often led to solutions that felt complex and cumbersome. I was determined to simplify this. My time at SoundCloud gifted me insights into scalability, which I infused into Tuist. It's a legacy I wear proudly, one where contributors can engage meaningfully without drowning in the vast sea of code.

However, Tuist's true magic unfolded unhurriedly. Balancing it with my full-time job meant limited but quality hours poured into it. This allowed for rich contemplation and design, even if I was just "coding in my head." My style might lean towards the classic in Swift, but its architecture is solid and purposeful.

Then came the beautiful moment when like-minded souls began rallying around Tuist. Kas's comprehensive issue, considering its use at Bloomberg, was a pivotal turning point. Soon, Marek, Danielle, and many others joined our ranks. The ebb and flow of contributors, like the heartbeat of any thriving organization, propelled Tuist forward.

Our strength lay in our foundations, direction, and vibrant community. With our energy levels skyrocketing 🚀, more organizations began embracing Tuist. While Apple endeavored to shift everyone towards the Swift Package Manager, we held our ground, earning our user's trust and appreciation.

Today, Tuist stands at a crossroads. To forge ahead and ensure its longevity, we're introducing Tuist Cloud - a premium, integrated suite for organizations. This initiative goes beyond mere donations, transforming Tuist into a sustainable enterprise. Yes, it's a path strewn with challenges - from liaising with legal teams to mastering the art of sales. Yet, it's these very challenges that ignite my passion. They're opportunities in disguise, ones that promise to elevate Tuist to greater heights.

I may not have a crystal ball to glimpse into Tuist's distant future, but our commitment is unwavering. We'll continue innovating, always pushing the boundaries, and granting Tuist the superpowers it rightly deserves.

Here's to the boundless possibilities that await.

After a thorough read-through of the related documentation and a deep dive into community discussions, I stumbled upon an enlightening issue. The root of the problem was a mismatch in the library's default path assumptions. While the Ueberauth library naturally presumes /auth as the default path, my project setup didn't adhere to this.

Hence, the necessary step was to clearly specify the correct authentication path to the library during its configuration, like so:

config :ueberauth, Ueberauth,
 base_path: "/other/path",
 providers: [
 #...
 ]

The journey to uncover this solution took a fair bit of time, and a handful of head-scratching moments. But, in the spirit of shared learning and community growth, I'm documenting this experience here. To those who may run into the same issue in the future, consider this a digital breadcrumb trail.

And to the mighty Google indexing bots, I hope you pick this up and help those in need find this solution with ease.

The syntax of the language is reminiscent of Ruby, yet entirely functional. It didn't take long for me to get acquainted with the syntax and primitives. Everything is organized into modules placed in various directories in the system, each exposing pure functions that can be piped using the |> operator. Things started getting truly fascinating when I began working with processes. This was somewhat of a novel concept for me in a programming language, yet I quickly drew parallels with an OS and its processes. They are lightweight encapsulations of tasks that don't share CPU or memory resources. Numerous processes can be created instantaneously, communicating with each other through message exchanges. These processes can also be structured into a tree, enabling the codification of supervisory rules such as automatically restarting any child process that crashes.

This introduces a profound mental shift in how you perceive your programs. When this shift resonated within me, I instantly fell in love with Elixir's approach to programming. The 'click' occurred when I started reading Joe Armstrong's thesis on Erlang, which fuels the BEAM virtual machine that Elixir operates on, as well as the programming language itself. The thesis opens with an exploration of the system requirements that Armstrong was designing for Ericsson, the need for a programming language, and his vision for solving global issues with software. He then introduces the concept of concurrency-oriented programming. Let me share some fragments from the thesis:

The word concurrency refers to sets of events which happen simulta- neously. The real world is concurrent, and consists of a large number of events many of which happen simultaneously. At an atomic level our bodies are made up of atoms, and molecules, in simultaneous motion. At a macroscopic level the universe is populated with galaxies of stars in simultaneous motion.

When we perform a simple action, like driving a car along a freeway, we are aware of the fact that there may be several hundreds of cars within our immediate environment, yet we are able to perform the complex task of driving a car, and avoiding all these potential hazards without even thinking about it. > In the real world sequential activities are a rarity. As we walk down the street we would be very surprised to find only one thing happening, we expect to encounter many simultaneous events.

If we did not have the ability to analyze and predict the outcome of many simultaneous events we would live in great danger, and tasks like driving a car would be impossible. The fact that we can do things which require processing massive amounts of parallel information suggests that we are equipped with perceptual mechanisms which allow us to intuitively understand concurrency without consciously thinking about it.

When it comes to computer programming things suddenly become inverted. Programming a sequential chain of activities is viewed the norm , and in some sense is thought of as being easy, whereas programming collections of concurrent activities is avoided as much as possible, and is generally perceived as being diecult.

I believe that this is due to the poor support which is provided for con- currency in virtually all conventional programming languages. The vast majority of programming languages are essentially sequential; any concur- rency in the language is provided by the underlying operating system, and not by the programming language.

This perspective is eye-opening, isn't it? The world is concurrent, but programming languages are forcing us to model the world differently, using primitives that don't map 1-to-1 to the real world, like controllers, repositories, factories, and builders. Armstrong goes further in explaining how we should observe the world to shape our software. He advocates for a 1:1 mapping of real-world concurrent activities to concurrent processes in our programming language, asserting that this is critical to minimize the conceptual gap between the problem and its solution, therefore enhancing maintainability:

Now we write the program. The structure of the program should exactly follow the structure of the problem. Each real world concurrent activity should be mapped onto exactly one concurrent process in our programming language. If there is a 1:1 mapping of the problem onto the program we say that the program is isomorphic to the problem.

It is extremely important that the mapping is exactly 1:1. The reason for this is that it minimizes the conceptual gap between the problem and the solution. If this mapping is not 1:1 the program will quickly degenerate, and become diecult to understand. This degeneration is oden observed when non-CO languages are used to solve concurrent problems. Oden the only way to get the program to work is to force several independent activities to be controlled by the same language thread or process. This leads to a inevitable loss of clarity, and makes the programs subject to complex and irreproducible interference errors.

This is one of the most potent concepts I've encountered recently, and it's the primary reason I'm smitten with the Erlang VM and Elixir as a modern language on top of it. Just yesterday, someone questioned why I didn't opt for Swift, which is also embracing a similar model. While I appreciate Swift's syntax, the problem lies in its inherited technical debt from supporting the transition from Objective-C. Furthermore, the incorporation of concurrency-oriented programming adds another layer of technical debt. Many libraries and standard library APIs are unprepared for it, which could potentially expose you to data race conditions.

Erlang's processes are the foundation for several other brilliant ideas that I'll explore in future posts. On a side note, did you know that Glossia is powered by Elixir?

So, buckle up and let's dive into the wacky world of Ruby installation! The first step on this zany journey is to install a few packages via Homebrew. Here's the list of packages you'll need:

brew install zlib readline libyaml libffi

Once you've got them installed, it's time to do some secret-agent-style stuff with your environment variables. These variables are like the secret codes that the Ruby compiler uses to link itself to the libraries you just installed through Homebrew. Sneaky, right?

Open up your ~/.zshrc file (or your shell profile of choice) and add the following lines:

# ~/.zshrc
export RUBY_YJIT_ENABLE=1
export RUBY_CONFIGURE_OPTS="--with-zlib-dir=$(brew --prefix zlib) --with-openssl-dir=$(brew --prefix openssl@1.1) --with-readline-dir=$(brew --prefix readline) --with-libyaml-dir=$(brew --prefix libyaml) --with-gdbm-dir=$(brew --prefix gdbm)"
export CFLAGS="-Wno-error=implicit-function-declaration"
export LDFLAGS="-L$(brew --prefix libyaml)/lib"

Now, here's the kicker: to make sure these environment variables actually kick in, you need to either open a fresh terminal session or give your profile a good old source. It's like summoning the magical powers of Ruby by performing a secret ritual. Trust me, it's worth it!

Alright, folks, that's all there is to it! You're now armed with the knowledge to conquer the Ruby installation beast and emerge victorious. May your future terminal sessions be error-free, and may your code flow like a river of laughter.

Firstly, I revel in the ability to bring my ideas to life without the need for consensus from multiple stakeholders or trying to convince senior leadership about its merits. It feels like a breath of fresh air to not have to deal with those challenges anymore, though it doesn't come without its own set of trade-offs. The challenge is not to solely chase joy and fulfillment but also to create a profitable, sustainable business.

The primary engine for this is Tuist and Tuist Cloud. Tuist Cloud, a feature set necessitating an HTTP server, forms the ideal foundation to create a sustainable business model. This is vital to ensure the longevity of Tuist, currently buckling under the weight of an influx of support and feature requests. As for whether it will be open source, the jury's still out. Initially, I aim to establish the most suitable form for the business, after which it will be prudent to navigate the legalities associated with making it open source. In terms of the programming language and frameworks, I have chosen Elixir and Phoenix for their ability to streamline my processes and accelerate iterations. While Swift on the Server shows promise, it's currently more time-efficient to leverage existing solutions than to build missing components.

Alongside this, I have conceived a tool designed for React Native developers, using Tuist as a foundation. However, that idea is on hold until the feasibility of Tuist Cloud is confirmed. If Tuist Cloud doesn't meet expectations, this alternate path awaits exploration.

A secondary focus of mine is Glossia, an AI-based localization tool I'm co-creating with my wife, a former member of the localization team at Shopify. We recognized several issues in the localization process that need addressing:

• Localization often ends up as an after-thought despite its potential to make products more accessible. * Large localization entities struggle with scaling their efforts and sometimes resort to using Google Translate-based products. * The inherent complexity and obfuscation within localization can be daunting.

The solution to these issues appeared elusive until we delved deeper into the possibilities of AI. Our subsequent experiments hint at a potential breakthrough. Our combined expertise allows us to envision a solution that's easy to use and integrate into existing workflows. We're vigorously working towards an MVP before summer ends. Provided things go smoothly, we'll cultivate a community of translators and developers and strive for integration with the most popular frameworks, including Shopify Apps. We firmly believe in the necessity of translating these apps to ensure accessibility.

In conclusion, I am thoroughly enjoying this journey despite the financial uncertainty that looms. I remain hopeful that we will soon see clarity on that front. If by year-end the financial landscape remains murky, we might seek external support, equipped with a solid foundation of work. I look forward to the challenges and opportunities that lie ahead, and I am eager to share more about our journey in future posts.

When I returned to working with Swift, I noticed that the Swift ecosystem lacked an easy way to integrate Tailwind into Swift on the Server projects, such as those based on Vapor or Publish. To address this, I took it upon myself to create a new Swift package called SwiftyTailwind. It allows for the lazy downloading and execution of the Tailwind CLI using system processes. Below, you'll find an example of how to use SwiftyTailwind:

let tailwind = SwiftyTailwind()
try await tailwind.run(input: .init(validating: "/app/app.css"), output: .init(validating: "/app/build/app.css"))

Integrating it with Publish

Integrating SwiftyTailwind is a breeze with the use of plugins. Simply instantiate and pass a plugin, and Publish will execute the code within the closure, generating the CSS file at ./Output/output.css. Remember to include the necessary code in the tag of your website to load these styles.

try Site().publish(withTheme: .tailwind, plugins: [
 .init(name: "Tailwind", installer: { context in
 let rootDirectory = try! AbsolutePath(validating: try context.folder(at: "/").path)
 try await tailwind.run(input: rootDirectory.appending(components: ["Style", "input.css"]),
 output: rootDirectory.appending(components: ["Output", "output.css"]))
 })
])

Integrating it with Vapor

Integrating SwiftyTailwind with a Vapor project is a seamless experience. To begin, you need to configure the app to serve static assets located in the default Public directory by Vapor. Here's an example of the code:

app.middleware.use(FileMiddleware(publicDirectory: app.directory.publicDirectory))

Next, create an instance of SwiftyTailwind and invoke it by providing the file Resources/Styles/app.css as input. Additionally, set the options watch and content to point to Resources/Views/**/*.leaf. Take a look at the code example below:

// Tailwind
let publicDirectory = try AbsolutePath(validating: app.directory.publicDirectory)
let inputCSSPath = try AbsolutePath(validating: app.directory.resourcesDirectory).appending(.init("Styles/app.css"))
let outputCSSPath = publicDirectory.appending(component: "app.css")
async let runTailwind: () = try tailwind.run(input: inputCSSPath, output: outputCSSPath, options: .watch, .content("Resources/Views/**/*"))
async let runApp: () = try await app.runFromAsyncMainEntrypoint()

_ = await [try runTailwind, try runApp]

Finally, update the section of your views to load the generated app.css file from the Public directory. Here's an example:

And that's it! SwiftyTailwind will monitor file changes in your Resources/Views directory and automatically regenerate the CSS output.

You can check out the Examples directory in the project repository.

Contributing to Swift on the Server

When compared to programming languages that have a more established presence in web development, Swift's ecosystem is still in its early stages. However, I am determined to contribute to changing that by building and sharing utilities with the community. Tailwind was my initial contribution, but I also have plans to introduce ESBuild and Orogene to Swift. These additions will enable a more advanced build pipeline in Vapor and facilitate fetching Node dependencies without relying on the NodeJS runtime. Exciting developments are on the horizon, so stay tuned for more updates!

"terminal.integrated.profiles.osx": {
 "Nix-managed ZSH": {
 "path": "/Users/pepicrft/.nix-profile/bin/zsh"
 }
},
"terminal.integrated.defaultProfile.windows": "Nix-managed ZSH"

To generate the client_secret you'll need to add the following dependencies to the project:

{:joken, "~> 2.6.0"},
{:jose, "~> 1.11"}

Once you have them, the implementation is very concise. The certificate variable in the example below is the content of the .p8 file generated by Apple. You can read its content using Elixir's File.read! API. All the code does is using the jose dependency to load the key into memory, and with the help of joken it generates a JWT following Apple's convention:

def client_secret(%{ team_id: team_id, client_id: client_id, certificate: certificate}) do
 {_, key_map} =
 certificate
 |> JOSE.JWK.from_pem()
 |> JOSE.JWK.to_map()

 signer = Joken.Signer.create("ES256", key_map)

 claims = %{
 "aud" => "https://appleid.apple.com",
 "iss" => team_id,
 "sub" => client_id,
 "iat" => :os.system_time(:second),
 "exp" => :os.system_time(:second) + 86400 # 1 day
 }

 {:ok, secret} = Joken.Signer.sign(claims, signer)
 secret
end

@builtin typescript

The @builtin is essential because the search filters out internal extensions by default. Once you enable it, it'll start working again. What caused it? I don't know, and I think it'll remain a mystery forever.

However, my ability to retain and connect things will degrade over time. Hence, I think it's essential to build a system to dump knowledge off my head, making connections with existing knowledge. I'm building that system on the Logseq app. I decided on it for a few reasons:

• It's open-source - It uses standard formats (e.g., Markdown) - It doesn't create vendor lock-in (I own my knowledge) - It's extensible via plugins - It has a great community around it

Dumping knowledge in an app is unnatural, especially when knowledge happens anywhere and anytime. But I'm starting to make it feel natural. Whenever I have an idea or learn something, I open Logseq and dump it there, ensuring I tag it properly. I'm also refraining from using integrations with platforms like Readwise to prevent dumping stuff without manual processing. Another thing that I'm doing is reading about the Zettelkasten method, which Logseq takes inspiration from. Once I'm interiorized the knowledge capturing, I'll move on to working on that knowledge and making connections using the tools that Logseq provides — for example, throwing myself into a part of the graph and navigating it from there, filling knowledge gaps and learning new things along the process.

If knowledge systems are a topic that interests you, I'd love to hear about your system and processes. Drop me a DM

import { groupBy } from "lodash-es"

Those imports form a module graph that needs to be loaded before any code gets executed. And because loading a graph entails doing IO and in-memory parsing operations, some of which can be parallelized, there's a strong correlation between the size of the graph and the time it takes to load. It's indeed one of the reasons, among others, why developers choose Rust or Go as programming languages to implement their CLIs. Compilers statically link all the code and the startup time is insignificant.

Note that the problem goes away when working on a client-side rendered app because bundling tools smash all the modules into a single or handful of modules. Vite embraces ESM in development but does some bundling-based optimizations with third-party dependencies. In the case of web servers (e.g., Express-based HTTP server) or SPAs, the startup time also gets impacted, but additional seconds during deployment don't impact the developer experience significantly. Orchestrators like Kubernetes wait until the server runs to send traffic to it.

What can we do about this? You can remain with CommonJS, although I'd advise not to. ESM is the standard, and more NPM packages are making it their default. CommonJS works synchronously and doesn't have to wait for the whole graph to load to start executing code. First, I recommend minimizing the number of dependencies of your project. It is also suitable for security and graph determinism at installation time. If you need to add a dependency, check how they export modules. If they have a single export from where you import everything, then use dynamic imports:

// Static import
import { bar } from "bar"

async function foo() {
 // Dynamic import
 const bar = await import("bar")
}

The best scenario is the dependencies using subpath exports, meaning that you only import what you need. However, few dependencies in the ecosystem are designed this way, so it's rare to come across one. As a last resource, you can introduce a compiler that can tree-shake external dependencies and delete unused code. However, code transformation might output Javascript code that blows up at runtime, so you'll have to invest in integration tests.

{
 "scripts": {
 "clean": "rimraf dist/",
 "build": "pnpm clean && tsc"
 }
}

The above setup is standard across Javascript tasks. A task for cleaning the output directory, clean, and another to output Javascript from the Typescript source code, build, which depends on clean. Because package.json's scripts section doesn't have the notion of dependencies, developers have to resort to workarounds like using &&: Do clean, and if it succeeds, build.

Defining dependencies that way works if the project is small. However, if a project gets larger and automation more complex, the dependency graph will inevitably be hard to reason about, hindering contribution to the project.

Luckily when I started working on GestaltJS I came across the Nx build system, which solves the above problem beautifully. Their approach was not new to me since the problem they are solving and how they are solving it is something that I had to do for Xcode projects in Tuist. You have a bunch of interdependent modules that a developer can interact with (e.g., test, build, lint), and you want the information to be codified in a graph that can be leveraged to introduce optimizations.

Some minds behind Nx are ex-Googlers that had the chance to work on Google's build system, Bazel. Unlike Bazel, which has a steep learning curve, and you have to learn a Python-like syntax, Nx is extremely easy to get started and add to an existing project. The developer experience (DX) is top-notch.

Once the tasks and the dependencies are declared, you have access to a whole set of tools that can save you a lot of time. One of them is incremental builds and being able to run tasks only for the affected packages. How cool is that? They can also cache task outputs across local and remote builds. It reminds me so much of the work we had to do to bring caching to Tuist. You also get a graph command to visualize the automation dependency graph. So no more navigating across package.json files to understand how tasks are interconnected.

I'd recommend giving the tool a shot if you have a workspace. Shopify's CLI has also had Nx set up since the project was created, and it's been a wonderful experience so far. We haven't had any issues with the tool, and it keeps improving with every release.

Nx is one of my references when devising iterations for the Shopify CLI

// Static ESM imports
import { loadRoutes } from "gestaltjs/routes"

// Dynamic ESM imports
function doSomething() {
 const { loadRoutes } = await import("gestaltjs/routes")
}

Settling into the new role is taking me some time. One reason is that I'm going through a process of accepting the change. My new role is less about being hands-on with coding solutions and more about the business. It's about reading, writing, talking, and socializing change in the organization. It's familiar, but I'm not as fluent and comfortable as I wish. Being in front of people and presenting an idea still feels terrifying.

Excellent communication skills are essential for this role, and mines have a lot of room for improvement. Therefore, I started working on them. I'm writing more regularly now and reading more slowly. While I do, I pay attention to how ideas are structured and connected. As someone with ADHD, focusing on a lengthy text piece feels painful. I also scheduled regular chats with people from other teams and leaders. The aim of these conversations is to have a more holistic view of the organization and its direction. This is useful to spot opportunities to support the organization best.

There are so many unknowns ahead of me, but it's part of playing the infinite game of the software craft. This as an excellent opportunity to grow professionally and personally. And I'm fortunate to do it surrounded by many talented people I can learn from.

The second issue is that APIs with paths as arguments or output values are not explicit enough about the type of paths. This is somewhat solvable with documentation, but wouldn’t it be better if the compiler, Typescript, is the one guiding you to use the APIs correctly. For example, making the compilation fail if you pass a relative path when the API expects an absolute one.

And last but not least, maintaining a piece of business logic that has paths as strings put the developer in the position of having to make assumptions, and that’s always a terrible idea. Is this path here absolute? Or maybe it’s relative? If it’s relative, is it relative to the working directory? Or maybe the project’s directory? You don’t want project contributors to be asking themselves those questions. Instead, you want paths to be made early in your system and pass them around, making it clear that they are operating with an absolute path and not a string prone to misusage.

To solve the above issues, I open-sourced a tiny NPM package, typed-file-system-path, which provides primitives for modeling absolute and relative paths and operating with them. The API is simple. You have utilities to initialize a relative or an absolute path. They’ll through if you are initializing them with an invalid path. The primitives provide convenient functions to prevent having to import utilities from the node:path module:

import { relativePath, absolutePath } from "typed-file-system-path"

// Initialize an absolute path
// @throws InvalidAbsolutePathError if the path is not absolute.
const dirAbsolutePath = absolutePath("/path/to/dir")

// Initialize a relative path
// @throws InvalidRelativePathError if the path is not relative.
const fileRelativePath = relativePath("./tsconfig.json")

The inspiration for this project comes from Path.swift, a primitive that Apple built as part of their swift-tools-support-core and that I used extensively in Tuist. Up next is adding more convenient functions, and update Gestalt to use the AbsolutePath and RelativePath types.

I came across a talk about the Erlang virtual machine, BEAM, and it blew my mind. I then read about Elixir, and its similarity with Ruby instantly clicked with me. The more I read about it, the more I liked it. At the same time, I also started to feel that I'd better not spend more time with Javascript than what's strictly necessary. The constant need to re-invent every layer of the stack, the VCs' urge to make their way into those layers, and how uncommon it is to embrace good software practices made me highly uncomfortable and stressed. I've discussed this in past blog posts, so I won't repeat myself.

One thing that fascinated me about Erlang is that it defers introducing complexity to your Elixir projects. Needs for which you'd introduce elements like Redis, Kubernetes, load balancers, and background jobs solutions into your system are well addressed by the VM when you get started. Its pattern matching is different, and I find their approach to functional programming easy to reason about and work with. I believe in building pure functions and dealing with immutable states, but the syntax of strongly functional programming languages like Clojure hasn't clicked on me yet. Talking about sharing mutable states… this is something that bugs me when working with Ruby or Javascript. It's common to see states being stored and mutated at the module level. Everything works until it doesn't, or tests become flaky because of it.

I'm considering moving this blog to Elixir using Phoenix to consolidate my learnings. I came across the nimble_publisher package that allows embedding static content, for example, blog posts in a Git repo, into the BEAM binaries that end up being deployed. I know this might sound too much for a blog, but what's better than your blog for a bit of over-engineering? Turning my blog into a long-running process will allow me to add some interactive bits to it.

After it, I'm also considering building a tool to scratch an itch that I've had for quite some time. Collecting and processing personal financial information from bank accounts and investment platforms to make better and more informed decisions. As always, it'll be open source, and if it turns out to be helpful, I might host an instance and allow other people to use it too. But first, let's see if I can build it for myself.

Are you also learning Elixir or are familiar with it? What do you like about it?

Moreover, I think I've developed a good sense for building great experiences through projects like Tuist, Gestalt, and a lot of inspiration from Ruby and Rails. Devising developer experiences is more of a product role, but I'm not a product designer. Should I dive into what it entails to be a product designer and apply it to the developer tooling domain?

It feels odd that product and development is a binary distinction in companies. It causes me a lot of impostor syndrome and a lack of identity. It'd be great if the gap between product and development was a spectrum, and you could grow within it too. Imagine one day wearing a technical hat because there's a problem you want to go really deep into solving because you think it'll positively impact DX. But the next day, you build prototypes around new workflows that you think users will love.

The reason why I love open source so much is that it's not who I am but about what experiences I want to create. I feel highly empowered when I free any labels and can navigate domains.

The solution we adopted on the new Shopify CLI and Gestalt is using the paths option in the tsconfig.json file. The API is intended to be used for re-mapping imports within a particular module, but it also works to define aliases cross packages. Here is an example of how we use them in the Shopify CLI. Thanks to it, Typescript can resolve cross-package typed contracts instantly. Note that when transpiling or bundling the code of each package, you'll need to tell the build tool to treat those imports as external dependencies and leave them as they are. Here is an example of how we do it for Rollup.

One caveat of the above approach is that since the Typescript configuration is static, you won't be able to extract the aliasing configuration and share it across Typescript and build tools. This means you'll end up with various sources of truth for the same information. I hope that Typescript allows the configuration to be more dynamic through a Javascript-based interface.

If you run into a similar use case, I hope you find the setup described in this blog post helpful. Also, if you know another strategy that works better than this one, I'd love to know about it.

Happy Typescripting!

I tried to organize myself using todo apps. I always used any random piece of paper that I found near me. I also tried to file, categorize, and prioritize issues on a GitHub repository. Still, I ended up resorting to a .gitignored TODO.md document. My note-taking apps are a mess. Thinking about how to label and organize my notes is an unnecessary mental burden for me. When something pops in my head, I want to jot it down and move on.

A caveat to my chaos is that it is not very compatible when collaborating with other people, for example, at work or doing open source. Some level structure is necessary for coordination to happen. Because of that, I sometimes pause, reflect, and give my chaos some structure to work with others toward a common goal. It’s not natural to me, but I don’t know about a better way. For example, I write up project roadmaps and visions, capture ideas or bugs on GitHub issues, or do brain dumps in the shape of blog posts. I did a lot of those when I maintained Tuist, and it had a positive on the community we were able to build around the tool.

I embraced chaos as one of my traits to mitigate the bits of anxiety that structuring the chaos brought me. Moreover, I adopted a tool like Logseq that allows me to capture the chaos in a raw state and defer giving some shape later. I usually do the latter if it’s essential to be able to get back to in the future or if it’s something that I plan to share with others.

After immersed me in the Javascript ecosystem as part of my work at Shopify and on Gestalt, I understood better what leads to this scenario. It's the combination of an ecosystem favoring many small packages over fewer but larger ones and the reliance on humans to follow semantic versioning from their packages. When one out of thousand packages introduces breaking changes that are not reflected by the version of the package, that causes the contract with other nodes in the graph to break, and the broken contract often surfaces as a broken workflow for the user.

A solution to this problem would come down to having smaller dependency graphs and having more acceptance tests in packages that can manifest breaking changes on CI, but that's unfortunately not an overnight change considering the size of the ecosystem. Because of that, in Gestalt, we decided to defend ourselves against sources of non-determinism like that one. We did so by leveraging the bundling process through Rollup. I know this sounds weird if you are used to using bundlers to optimize the artifact that's served to the user, but believe me, it plays a crucial role in improving the experience for Gestalt users.

Our packages have their external dependencies as devDependencies. The versions are pinned through Gestalt's lock file. They are tree-shaked and bundled as part of the bundle of the package, and that's the bundle that we use for running our e2e tests, including in the NPM package that users install. If the bundle passes our e2e tests, it'll work as expected on the user side. We make exceptions for mature dependencies and have solid test suites because we have a higher trust in their usage of semantic versioning.

We've been using Rollup for bundling, and we couldn't be happier with it. It also helps transform CJS dependencies that we can't interoperate with because they don't follow the Node conventions. Here's an example of the configuration used for bundling the @gestaltjs/core package.

Every tiny detail can have a significant impact on the developers' experience. Therefore we can't embrace "delete node_modules" as it is what it is when there are strategies we can adopt to minimize it.

If we want to build great developer tools, we need to start by acknowledging that the developer community is diverse in terms of backgrounds, skills, and levels. Our lazy side would prefer a single persona because we can design the tools using us as a reference, and without researching much. But fortunately, the world is heterogeneous.

Acknowledging diversity is necessary but not sufficient. We need to have the empathy to connect with the various personas that will use the tools. Here are some examples:

• A developer that doesn't want to make many decisions. - A developer that has strong opinions and wants to customize their setup. - A developer is new to programming and is getting familiar with some concepts.

Once connected with those profiles we are building for, we can design a tool that either infers the experience based on the identified persona or provides an interface to indicate it. Alternatively, you can guide everyone through the same initial experience and give them opportunities to diverge and design their own journey. We can also embrace DHH's conceptual compression idea to make the experience feel like you are peeling layers of concepts as needed.

If you are building developer tools, remember. Not everyone is like you. Embrace diversity and build for it.

A manifestation of the above is seeing ideas that are not ported over to CLIs. For example, design systems are popularized across UI-oriented products. They play a crucial role in ensuring a consistent experience across features and products. The need for design systems grew organically when large organizations realized that it was becoming impossible to collaborate without a common foundation of blocks and principles. That manifested as inconsistently-styled experiences, which tightly connect with the user experience (UX). Design systems can play a similar role in CLIs, but few organizations spend some time devising and laying out a foundation to build upon. The ideas are the same, but they map to a different set of building blocks in the domain of terminal interfaces.

Adopting a product mindset requires looking at CLI commands as UI. Limited compared to browser-based products, but UI nonetheless that developers can experience. A command is a dialog between a person and a different domain through a terminal. Unless we put the attention to detail it deserves, we might end up designing conversations that feel like the person on the other side of the screen is a robot. They might serve their purpose, but they won't be as enjoyable as if it felt like talking to another human.

Pay attention to how you name commands, arguments, and flags. A terminal is limiting, but remember, constraints foster creativity. An intent well captured with the command's name and flags that become indirect complements of a sentence can yield a very expressive interface.

When you send output through the standard streams it resembles receiving a response in a conversation. Be clear and direct, and when doing something that takes time, make sure the person knows about it. If you couldn't do what the user asked the CLI to do, tell them why, and provide the next steps that they can take to overcome the issue. Errors are also disregarded in CLIs primarily due to, in my experience, developers' laziness. It's quicker to just throw than go to the roots of the error to fix it or provide a better error experience.

If you build a CLI, remember, the how is as important as the what. The what makes a command satisfy the developers' intent. The how is what can make the experience more enjoyable to use. Some smartphones had been designed before Apple introduced the iPhone. They all served a similar purpose, but one put attention to the how and created an experience that made the product a successful piece of technology. Resist the urge of being lazy and not consider scenarios other than the happy path. You'll move slower, but remember, this is a long-term investment that pays off and you'r users will be thankful for it.

It hints that there might be a future where additional tooling and the indirection that comes with it its not necessary, but if you dig into that idea a bit, you realize it'll never be possible. At least in the years to come. Tooling will remain necessary to polyfill the code to adapt it to various runtimes (e.g Deno). It'll also be needed for UI frameworks that have built their template solutions upon Javascript (e.g JSX), remove type annotations from Typescript code, and accommodate NPM packages that don't comply with CommonJS conventions to ensure interoperability with ESM. g This is not unique to the Javascript ecosystem. Compilers also transform and optimize code into binary to be able to run it in the target platform. When building for Apple platforms, there's an artifact akin to sourcemaps, dSYMs, to be able to link stacktraces with the source code. The difference is that other ecosystems make it a core element of the programming language and that allows a more integrated experience. Achieving a similar level of cohesiveness in the Javascript world feels like juggling. You can integrate various tools under a framework to achieve a well-integrated experience, but you end up with a brittle setup that falls apart easily. This explains the well-known "delete nodemodules"_ and install dependencies again in the hope that the package manager will restore the state.

Despite how much I'd love to see a broader adoption of ES modules in the NPM ecosystem, and more conventions and standards pushed down to the Javascript foundation, I'll doubt that'll happen in the near future, and this influences how we build Gestalt. We'll do what's in our hands to minimize tooling indirection manifesting as bugs or breaking project setups. Rails is better positioned there thanks to the Ruby, but we can leverage some Javascript capabilities to approximate the Rails experience. For example, we can provide a foundational set of utilities that are automatically polyfilled by the framework depending on the deployment targets. This is something can't be done easily if frameworks encourage projects to import Node APIs directly.

Instead of dreaming with a future where tools are not necessary, we are embracing tooling and leveraging it to provide Gestalt users with a reliable and integrated developer experience. I think Gestalt will blow your mind like not many frameworks have been able to do.

Distributing software as a portable binary is an excellent idea for CLIs because you don't want to require users to install additional dependencies in their environment. But in the context of web apps, users don't give a shit about your web app being a binary. They care about the app's usability, reliability, and performance more than anything else. How an app runs in a server is an implementation detail. In pre-Kubernetes and Docker times, there'd have been a strong argument in favor of binaries to ease deployments. But times have changed, and that's not a problem anymore. Platforms like Heroku or Fly can infer your app's project deployment.

I'm writing this down and sharing it to remind myself and others that might come across the same argument that we build ultimately for users. If you get excited about a technological cycle or innovation, ask yourself whether you are playing with a new technology or building for users. And in the case of the latter, wonder if users care about the technological decision you are pondering. Shopify was criticized back when they chose React Native for the mobile apps, but it was a decision that has had a positive impact on users' experience, which really matters.

When the motivations of the people contributing to a project are extrinsic, then the chances are that when money is gone, so are the motivations to contribute to the project. When the project is more community-driven, intrinsic motivations take preference, which helps the project sustain long-term. Note that community involvement and governance are not the same, even though they are often used interchangeably.

There’s a high correlation between projects that use money as an extrinsic motivator and the amount of marketing effort they’ve poured into them. They usually have marketing copies along the lines of “we are making the web faster” that reassemble the missions from Silicon Valley companies. I refrain from building anything upon those tools and frameworks no matter how good their marketing is. When I build software, I want it to sustain in time, and to achieve that, it’s important that the blocks I build it upon can sustain too.

Note that there’ll always be economic interests when developing open-source projects. Companies contribute to open-source projects because they benefit their business. However, money here is a secondary player. The community has a substantial role in steering the project than the companies that support the project through contributions. An excellent example of this is Rails. A company like Shopify has teams dedicated to contributing to Ruby and Rails. Shopify has interests, but it can't drive the framework in a direction that only benefits Shopify.

I think this is beautiful about the Ruby community, and recently in Javascript through projects like Vue, Vite, Rollup, and Svelte. You can sense a community behind it that connects all the different pieces in harmony and builds a strong community around it. This is the type of OSS that aligns with my principles and upon which I build the software that I craft.

Shopify is a platform. They acknowledged the definition of e-commerce changes across countries. They can't build as many e-commerce versions as countries that exist in the world. But they can build the LEGO pieces and the core business logic and provide APIs for developers to build upon. The more I contribute to this platform from the inside, the more I realize how brilliant the idea is. It seems a simple idea, but I'm sure Tobi has put a lot of thought into this.

I have the opportunity to work on the CLI that first and third-party developers use to build and deploy to the platform. As part of this work, one of the challenges we came across is breaking or abstracting away the dependency that projects have with the platform. If you've used CLIs to build for other platforms, you might have noticed that most of them don't require the platform in the development phase. If you create an iOS app, you only need the platform when you upload the app. Until then, you can use Xcode and the simulators to develop and test the app locally. If you create a web app with a framework like NextJS, you can run the app locally and only interact with Vercel when you need to deploy the app. There's only a moment in time when the user has to navigate from the CLI and the local environment to the server-side platform.

But that's not the case at Shopify. Theme development depends on the production storefront renderer to preview the themes during development. The same is true for Extensions. An extension only makes sense when it's loaded within the context of the Shopify platform. For example, if the extension represents a checkout extension, you want to see it loaded in an actual checkout flow.

During development, the dependency on the platform makes it extremely challenging to provide a great DX. It's not impossible, but something I've been thinking about ever since I came to that realization. I don’t have solutions yet, only ideas for improving the DX. For example, imagine Shopify providing a server-side Storybook-like functionality that acts as a disposable sandbox environment. The dependency with the platform remains, but there's a platform-side dedicated tool to ensure the preview experience is the best. Storybook's stories concept would map so nicely. For example, we could provide different checkout scenarios that you can easily switch between without going through the checkout process.

Another approach could be taking platform functionality down to the client to simulate locally. However, that requires first designing those pieces to be modular enough so that the preview piece can be pulled locally. Second, write them in a compiled language such that you hide implementation details of the business domain. If you are familiar with iOS development, it'd be the same as providing a simulator for the Shopify platform.

Improving the current state would shorten the development cycles, and developers would have more focus and motivation when building for the platform. I remember my days of iOS development when I could not preview my changes because of signing issues. It felt so frustrating that I don't want Shopify developers to feel the same way.

However, that doesn't seem to align with what some people expect: polarized and somewhat religious opinions. They expect you either be a React Native lover or hater, a Web2 believer or a Web3 geek, or a monolith vs a micro-services advocate. Liking Web3 but disliking parts of it is inconceivable for them. You either like it or hate it.

Because I don't want to be biased by my own static opinions, I avoid engaging in these discussions and keep and open mindset. Moreover, since I value openness and I enjoy sharing my learnings and opinions, that sometimes means seeing seemingly contradictory opinions at different points in time. And that's completely fine.

My opinions about Javascript development have been a roller coaster. There are things that I like about it, for example the beautiful abstractions developers are building with it, and things that I hate about it, like the convoluted setup and dependency graph that you find in some projects. Similarly, I gave up a while ago on being religious about Swift. That gave me a unique perspective on where the programming language shines, what are the limitations, and how Apple's interests drive the direction of the project.

I'm currently forming opinions around the nature of the technologies and tools they use. Do I want to continue using and supporting open-source technologies with business interests baked into it? Is my relationship with open-source sustainable long-term? Do I see myself doing the same thing for the next 10 years? 20 years?

My days are filled with questions, and the answers to those lead to opinions and more questions. Expect my opinions to change. Expect me to share those opinions, and also expect my opinions to move along a spectrum. "The only constant in life is change" they said.

I ported over the same boring design I had in the previous Jekyll-based website. I love it because it reminds us the origins of the web as a tool to share documents. The focus is in the content and not that much on the continent.

Expect some follow-up blog posts from me talking about the things that I like and don't like about Svelte and SvelteKit, and how it compares to other frameworks like Vue and React.

What if frameworks have adaptation as a built-in primitive? That's what SvelteKit provides through Adapters. It's an API for third-party developers to define how to adapt a SvelteKit app to different hosting providers. For example, the netlify-adapter adapts the output to Netlify and does things like turning endpoints and SSR pages into functions that run on-demand. Because the framework allows SSR, CSR, and static rendering, a SvelteKit project can contain the web app, documentation website, and marketing and landing pages. Cool? Isn't it. Adapters decouple the deployment platform from the framework to prevent vendor-locking.

I’m still new to the framework, but I think its concepts are powerful, and adapters are an excellent example of that.

As a software engineer, a fortunately well-paid job, it's easy to fall into the treadmill trap. You earn above the average (prompter), immersed in a planned obsolescence culture (temptation). You want to have the latest iPhone, a new Macbook, a large TV, an Apple watch... We become friends of Amazon and spend without thinking about our financial future.

The first thing that I learned is that it's important to have insights into your cash flow for two reasons. First, you can see whether you are spending too much money on things that bring no value. Second, you can see your family's net worth and know how much money you can invest.

This leads to the following question: what's my investment strategy? We first invested in a property in Berlin. That's what people do in Spain, so we had a strong bias towards this move. Is it the most brilliant move to start with? I don't think so. Was it a good idea in hindsight? I think it was by looking at the market and considering the interest rate of the mortgage. Then I read further and learned that it's wiser to defer that type of investment and use the liquid money to increase the net worth through other investments.

The next move (and serious mistake) was seeking financial advice. We came across DVAG, a Deutsch corporation whose goal is to sell insurance. We naively fell into their trap of thinking that we needed all the insurances they offered us. The person who sold us those products was a Spaniard living in Berlin, so her selling strategy was to "teach" ex-pats how Germans do it. We got the following for my wife and me:

• Riester and Rürup pension plans - An income protection insurances, - A lawyers insurance, - A bausparvertrag for our mortgage - An investment product (that invests in funds) - Private health insurance for me.

In hindsight, we were too naive. Planning to move to Spain allowed us to see everything from a different angle:

• It is a company that follows a pyramid scheme earns commissions per sold product and from the products sold by the people under them. - We were sold products (the pensions) that were not designed for our profiles. They asked how much we earned and filled the costs as much as they could, ensuring there was a tiny bit of space for breathing. - They never shared the costs with us, and as you can imagine, they were pretty high (over 2% annually).

We canceled everything except Rürup that cannot be canceled but paused. We lost some money, but it was nothing compared to what we'd have not earned if we stayed with them. This was something positive about considering moving back to Spain. When I told her I was canceling everything, her answer was: Don't expect the same service from me anymore. Of course, I later discovered that Generali would make them return all the commission they got for bringing me as a customer. Funny thing, she insisted a few times on getting my Germany deregistration confirmation (i.e. Abmeldung) to prove that I did it because I was leaving the country. If you ever come across this company, DVAG, watch out.

I learned a few lessons out of that experience, but the most important lesson is that no one will manage your finances better than you. Or in other words, investing money comes with the responsibility of learning how to invest it.

After that, I continued reading further. I started investing in ETFs (a mix of accumulative and distributing funds to take advantage of some tax benefits in Germany), individual stocks from companies that share dividends, and alternative investments such as microloans, whisky, and cryptocurrencies. As part of this effort, I created an additional spreadsheet to keep track of them. In particular, In particular, I'm interested in the diversification scheme and how investments are performing over time. If you are interested, the following two resources have been handy for me: Index Fund (European) Investor, El Club de Inversión (Spanish), and Banker on Wheels.

Alright, Pedro, you save money, which you decide to invest, but what's your goal? My goal is to be rich. But not the definition of rich we are all used to. The definition by Robert Kiyosaki:

If you stopped working, how long could you survive?

I want to work less or even better, stop working, and not have to worry about money anymore. Right now, I have two dependencies. My employer, who is my primary source of income, and the future public pension from the Government, which we all know it's getting harder to sustain. Unless I do something, the default is to continue working as much as I do until I retire. But there's a better alternative to that, which I learned in the book "The cashflow quadrant": I can be a mix of a business owner and an investor and leverage people and money to make money. Achieving that independence is also possible by being employed, but it often leads to working harder which is not healthy. It's not a matter of working harder, but being financially more intelligent.

I've always been in the employed quadrant and worked hard, which has allowed me to grow a lot professionally. But I feel I'm approaching an inflection point, and I'll have to take a leap. I might start using my spare time more wisely and gear it towards being the owner of my own business in the future. I think I have some necessary traits to get there, but there are some other areas I still need to work on.

I've you've followed me for a while, you might notice a shift in my relationship with open-source work and the content in this blog. If this intrigues you and you would like to chat about it further, don't be a stranger and send me an email. These topics are always taboo, but I'm open to talking about them.

There are great things about the React stack. You can more easily unit-test the business logic of your frontend, share and use components that atomically encapsulate structure (HTML), behavior (JS), and style (CSS). Moreover, you have access to beautiful abstractions to do theme-based styling and even leverage the Typescript compiler to validate your styling object. React turns building a web app into a LEGO game where many blocks are already provided by the community.

However, with React, projects pull in a chain of drawbacks that wouldn’t exist if we didn’t add React in the first place. The first of them is having an API. Sure, if you plan to have more clients in the future, an API is a must. But what if that’s not the future plan, or it’s far ahead? You end up optimizing for a future that might never come.

In many cases, we end up going down the path of GraphQL because libraries make it so convenient that we think we need it, but we don’t realize again that GraphQL was designed for a problem we are far from having. And as you probably know, but with an API, we introduce a new set of problems because we have two sources of truth for the data. Many Javascript libraries are trying to abstract that away through caching strategies. Some projects decide to go down the path of trying to model their state with yet another dependency, Redux, that ends up spreading like a virus and bringing more complexity to the frontend domain.

At this point, one might argue that it’s possible to solve that by doing server-side rendering (SSR). True, but the moment you hydrate the app on the client, you want the routing experience to be on the client, leading to components having to fetch data through the API. We can’t move away from it. React and, more generally SPAs, force you to have two sources of truth for your data. And I forgot to mention that SSR requires your React libraries to be compatible with it, limiting the options from the exciting pool of component libraries one has access to.

Furthermore, React means JSX, and JSX means you need additional tooling and process changes. Babel or any other transpiler needs plugins to transform the JSX into a valid Javascript syntax, and some CSS-in-JS libraries might couple themselves to the underlying tooling through macros. Because the Javascript that you write is not the one that gets executed, and it’s just a declaration that is then loaded in a virtual DOM and persisted to the document, debugging requires additional browser extensions. Don’t get me wrong. Having to install tools is not a bad thing; having to mess around with these things when starting a project takes the focus from the important thing, generating value through technology.

We should not forget that we can make our styling themeable by simply leveraging CSS building blocks, generate HTML server-side without a framework like React and the chain of tools that come with it, and that small touches of Javascript are sufficient to add some interactivity where it makes sense.

When does it make sense to follows the React approach then? I think it makes sense that the app will be very interactive, for example, if you are building a tool like Figma. It also makes sense if the value the abstraction brings outweighs the cost of maintaining and evolving a most likely convoluted set of Javascript libraries and NodeJS tools. You can also take the path of letting a framework do that for you, which is what RedwoodJS and NextJS are betting on. It also makes sense if supporting multiple clients is core to the product, and where developing an API and reusing mental models align closely with the product direction.

It does not make sense if your sole focus is to generate value through a web app. Throw a project with a Rails or similar framework and focus on the product and not the tools and the technology around it.

My sentiment with React and Javascript development is that it’s a bit like capitalism; it creates more problems that can be solved with more Javascript. Solutions are in rare cases evolving an existing foundation, but creating better versions of existing tools or creating new tools from scratch like Rome because everything that was built before is fundamentally wrong.

Should I tweet about this? What if I write a blog post about that? This is boring; let me check what people are talking about on Twitter. Look at that beautiful scene; I’ll take and share a photo on Instagram. This is hilarious; I’ll tweet what happened to me. I built this open-source project, I’ll share it broadly to gauge people’s reactions.

I was once gifted the Internet awesomeness, and now I gift my time and energy back to the Internet for free. In the meantime, life goes by, and I miss the opportunities to do fulfilling offline and social activities. Is this sustainable long-term? I don't think it is.

The more I run on the dopamine treadmill, the faster it goes, and the more I need to have a sense of fulfillment. I've got online friends that I feel I need to feed with photos and stories, some followers on Twitter I feel I need to share updates with, a handful of open-source projects I feel I need to maintain. There are also newsletters I feel I have to keep up with, Reddit discussions I feel might be relevant to me, and podcasts I feel it'd be great to listen to. I become blinker, and consequently, I miss out on the beauty of slowness, the present, and the beauty of the offline world. It's all me, my ego, the dopamine, and what I feel I need to do. It's all feelings.

What's worse is that it has a cascading effect. People see the facade, and if they feel inspired by a professional trajectory, they think they need to imitate what you do. The world then becomes a dopamine festival. Rockstars take the main stage, while the audience dream of becoming one in the future. I don't need to learn how to play an instrument, nor find a band or a manager; I need time and some tools that people are already addicted to (e.g. Twitch, Twitter, TikTok). If I build my audience, I can play in the main stages too.

The Internet has paved the way to achieve a dopamine-dependent life whose meaning come from other people worshipping you and your work.

Seeking that life has some similarities with dreaming with becoming a millionaire. We pour a lot of energy, time, and sometimes health to finally realize you made your life more meaningless. We are on the treadmill, so we need recognition or money to sense a meaningful life.

The truth that many of us fail to realize is that we are social animals; thus long-lasting happiness and fulfillment often comes from social interactions in the offline world. If there's something positive out of the COVID19 pandemic, it's that it proved that we can't replace offline relationships with Zoom calls or Clubhouse discussions.

Alright, Pedro, I get you, but how are you going to remove your dependency? First, I'll limit the content consumption time to Friday mornings. If I find something interesting, I'll use a read-later and save it to read it on Fridays. Regarding my usage of social networks, I'll limit their usage to once per day. The list of social networks includes Twitter, Instagram, and Facebook. I like capturing my ideas and reflections in the open, and therefore, I'll continue sharing them. However, I'll use my personal website as a medium and not Twitter. The reason is that I don't want to contribute to the stream of tweets that might contribute to increasing people's anxiety. I'll increase the amount of social and offline activities. For example, learning how to design and assemble furniture, gardening, or learning German has been on my list for quite a long time, and I continue postponing to leave space for my online endeavors. And last, I'll remove any sense of obligation with anyone on the Internet. I'll do things that bring me joy.

Let's see how it goes.

Why React? What’s the role of GraphQL? Why was Rust created? Where does it make sense to use it? How does it compare to Go? What are the drawbacks of building a CLI with interpreted languages? How does SvelteJS and SolidJS compare to VueJS and ReactJS? What is React Server Components trying to solve? Why does ES modules remove the need for intricate Javascript tooling? Why is "deleting node_modules" a thing in the Javascript ecosystem? Why is the trend in the Javascript community to build tooling in compiled languages?

Problems that are constantly arising push current solutions beyond their limits, and in less-opinionated environments like Javascript’s, new creative solutions emerge like flowers in a field. The result of that is a rich pool of solutions to choose from. The caveat is that solutions get so much attention that the problems they originally set out to solve remain background or get disregarded in the decision-making process. On top of that they present even more problems that get solved with more layers. In practice, this means simple projects with convoluted tech stacks that aim to solve problems they don’t really have.

Take React. It solved Facebook’s problems that are now becoming other companies’ problems too. GraphQL is a similar story and it’s now becoming the standard for the request-response model in web applications, even if there’s a single client consuming the API. Just today I came across a product that combines GraphQL with CDN to provide caching to GraphQL APIs. What will follow? Another product that solves synchronization issues between the source API and the caching layer.

We, developers, are usually solutions-oriented, and that makes the matter worse. We get tasked with solving something, and put too much focus on the solution. As a consequence, we end up proposing technologies and languages we are familiar with or that most people are talking about these days. This is very challenging for me. I need to make an effort to understand a problem well and consider multiple solutions before deciding for one. I have to tell my biases to shut up.

As the name of the post says, we often end up with great solutions for the wrong problems.

What should we do then? I think we have to embrace innovation and diversity of solutions. It’s something positive for the industry. However, I think we should mentor software developers to be more problem-oriented. They should be able to gain understanding of the problem that they have at hand, evaluate several solutions and understand the trade-offs of each of them, make the best unbiased decision, and document the rational behind the decision for future context and re-evaluation.

Moreover, I think it’d be great if open-source projects include in their READMEs the problem/s they are optimizing for, and some examples of projects for which the solution would and wouldn’t be suitable.

Mastering this is, in my opinion, what sets the difference between a junior and a senior developer. Towards the staff role, developers should be able to find problems to solve in domains with some uncertainty.

It’s not easy. As I mentioned earlier, I have to make an effort every time. However, once the decision is made and the solution executed, it feels extremely rewarding and puts you in the mood of hunting new problems.

If we think about it further, we'll realize that the approach is incompatible with the diverse world we live in. Diverse problems require diverse solutions. But what we get instead are solutions designed for a western-centric simplified version of the world, and we expect everyone to embrace them.

Having a simplified version of the world is convenient for the business. Still, it might lead to severe problems like the Myanmar genocide incited on Facebook or the e-scooter chaos in Berlin.

As someone who works in tech, this annoys me greatly, especially when the company prides itself upon its diversity efforts and building a product that rejects world diversity. How crazy is that?

I understand building as many product versions as nuances exist in the world would be cumbersome. Still, companies could focus on the domain's core and provide a platform for developers to codify the diversity of the world. This is what Shopify does with its apps ecosystem. Shopify focuses on the business logic and primitives of e-commerce and provides developers with extension points on the platform to translate e-commerce to the meaning in their countries. I believe this is key to Shopify's success, and it's one of the reasons I like it working here.

Imagine Facebook doing something similar. They already have a platform with primitives, logic, and a complex graph of social interactions. Developers could build upon that to create social networks in their countries following their countries' social norms and cultural nuances. I believe Jack aimed to do that with Twitter, but I can't find the link to it.

So the takeaway I'd like to leave you with is that shaping products as platforms and providing APIs for developers is an exciting model to embrace the world's diversity.

It took weeks of many questions and answers to finally admit it was not the right time for us to be back.

What follows is a brain dump of what led us to make that decision. Note that this is based on my experience, and therefore it's subjective.

First, it's very comfortable living here. It's too comfortable that it makes us feel uncomfortable. We like the challenges and the learnings that come from them. We feel moving back would rush us into a more appropriate life for an older version of ourselves. Being abroad means being exposed to other cultures, and we love that a lot. When we left the country, we became more aware of what we didn't know and learned how nuanced and complex the world is.

Many people here say that "in Spain, we have a good life", but I realized that statement is subjective. What's good? If you reduce that to weather and food, sure, you'll have a good life here. But in other areas such as innovation and education, Spain is far distant from other countries in Europe, which also means good life to us.

What are we doing then? For now, we'll go back to Berlin. We need to rest in what's our home. As weird as it sounds, we miss Berlin's weather. It's been too humid and hot these days in Barcelona (we might have become Germans). The plans for later this year or early next are to visit Amsterdam, to assess it as our potential next home.

Not found. Authentication passthru

And every time I have to spend a fair amount of time understanding what's causing the error.

Luckiy it won't have anymore after writing this note for my future self.

Besides the standard steps to set up Omniauth and Omniauth GitHub, we need to add omniauth-rails_csrf_protection to bring CSRF Protection to the requests that are sent from the authentication pages. After adding the dependency to the Gemfile, we need to add a new initializer, omniauth.rb, to allow sending POST requests from the Omniauth links:

OmniAuth.config.allowed_request_methods = [:get, :post]

In that same initializer, we need to set the host to ensure Omniauth passes the right redirection URL when initiating the authentication flow. Otherwise the Omniauth provider might fail due to mismatching URLs:

OmniAuth.config.full_host = "https://myapp.com"

If we generated the Devise views under our project's app/views directory, we can notice that the Omniauth links are already configure to be POST in the _links.html.erb file:

 <%= link_to("Sign in with #{OmniAuth::Utils.camelize(provider)}",
 omniauth_authorize_path(resource_name, provider),
 { method: :post }) %>

And last but not least, we need to instruct Omniauth on what to do once the authentication flow has finished. We do that by configuring a controller in the routes.rb:

Rails.application.routes.draw do
 # Devise
 devise_for :users, controllers: { omniauth_callbacks: "users/omniauth_callbacks" }
end

In the controller each provider is represented by a method with the same name of the provider. Note that the request's env attribute provides all the user metadata that we need to find or create the user in our database and authenticate them using Devise's sign_in_and_redirect method:

class Users::OmniauthCallbacksController < Devise::OmniauthCallbacksController
 def github
 @user = ... # Create the user

 if @user.persisted?
 sign_in_and_redirect(@user, event: :authentication)
 else
 data = auth_data.except("extra")
 session["devise.oauth.data"] = data
 redirect_to(new_user_registration_url)
 end
 end

 def failure
 redirect_to(root_path)
 end

 def auth_data
 request.env["omniauth.auth"]
 end
end

And that should be it. I hope this is also useful for other users running into similar issues with the Gem.

This is something I'm changing in my projects with an executable called dev. All my projects have it going forward. That's the only thing I have to remember.

Since I have Ruby in most of my projects, I leverage Foreman and a Procfile to run concurrent processes. This is an example of the Procfile.dev of one of my Rails projects:

rails: bin/rails server
vite: bin/vite dev

Then all I need in the dev executable is:

#!/usr/bin/env bash

bundle exec foreman start -f Procfile.dev

It'd be great if I could have an up command too to configure the environment. However, and as you might know, configuring environments deterministically and reliably is hard. Many companies let that be a developer's responsibility. Others like Shopify have needed years to have a tool that does an incredibly good job at that. And companies like GitHub, prefer to take the development to the cloud.

If you run into this same issue in the future, you can either run the steps on that repository or download the compiled version that I built myself. Here is the sha256 checksum to validate you downloaded the correct binary.

shasum -a 256 seabolt-1.7.4-dev-Darwin.tar.gz

Once you verify the binary is correct, you can untar the content, and copy the dynamic library into the directory where the driver expects it:

cd build/dist/lib
cp libseabolt17.dylib /usr/local/lib/libseabolt17.dylib

And that would be it. The Neo4j Ruby driver should be able to initialize successfully.

A note on Chimera

It's the first time I mention Chimera, so you might be wondering what's that tool. You are probably familiar with tools for capturing networked notes like Roam Research and Obsidian. They are great because they remove the friction of giving your ideas, knowledge, and thoughts a structure other than the one they have in your brain. However, they are designed and optimized for the web. If you try to use them from your phone, the user experience is terrible. And because ideas can arise at any time, and you usually have your phone with you, I think having an app optimized for native will take the experience of capturing them to a whole new level. So that's what I set out to build; a tool for networked thoughts, ideas, and knowledge. I'll focus on Apple platforms first, following their human interface guidelines. I'm very excited to use Tuist myself and learn about SwiftUI to make this happen.

Because I did not end up using it, I forgot most of the things that I learned. Therefore, I decided to get back to it, getting my hands dirty and applying the things I read about. This blog post is a braindump of some thoughts that I've got so far. Expect more of these to come in the future.

I like its module system. It reminds me of Ruby's but is more opinionated about the file structure. It encourages organizing the code in a modular fashion and ensures the file structure represents that structure. In Swift, for instance, namespaces can be created leveraging language's constructions, but the build system doesn't have any opinion on the file structure. As a result, it's common to see file structures not matching the code's.

The one thing that I haven't had the chance to work with yet is the ownership-based approach to memory management. I think I've got the idea, but it'll take some coding for the idea to click in my head and think in terms of who owns what and for what. It's exciting to read that it's one of the features that makes Rust so unique because it leverages the build system to catch what otherwise would be runtime issues.

The standard library looks pretty complete. Besides the basic types someone expects from a standard library, there are also handy utilities like Path that are handy when building apps that interact a lot with the file system. For instance, in Tuist we had to resort to a Swift Package to have such a model because Foundation does not provide it.

The collection of community Crates is enormous. It's not at the level of NPM or RubyGems, but I've found Crates for everything I needed so far. I find this crucial when choosing a programming language. You don't want to end up building something that someone else might have built before.

And that's it for this this post. I'll continue playing with it and dumping my thoughts on this blog as I continue forming more mental models around the programming language and its tooling.

What to do then? I don't know.

On Tuist, when I think about what to work on, many things come to my mind: there's a new website design to implement, some caching issues that we need to tackle, documentation improvements that I'd like to add, functionality that I'd like to start building onto TuistLab... It's too much. I'd like to do everything, and I end up doing nothing. The mental overhead causes paralysis. Working on one thing leaves you wondering if you should be working on something else instead. You feel bad because you are building something new instead of supporting existing users with the issues that they face. It's tricky, isn't it?

It's something I'm trying to get better at, but it's not easy. There are a few things that are clear to me though. There needs to be work on adding new features and improvements. I have a product mindset and I enjoy talking to users and turning that into solutions for them. The time that I invest into supporting users, I'll try to time-box it. For example, I can tackle an issue per week and no more than that. I'd make exceptions if there's a critical bug or regression in a new release. I have to say that in the area of support, we are lucky to have users, contributors, and maintainers helping there. Without their hands things would have gotten unsustainable.

So here's the thing I'm thinking about going forward. I'll focus on a project at a time and limit the support work per-week with exceptions. I'll decide the project based on my motivations and needs and what's important for users too. For example, I know caching of binaries is becoming and important feature for users. I'll use GitHub projects to organize the work on projects and have a sense of progress. It'll be helpful to involve others in a project I'm working on. And last and not least, I'll continue engaging with users on Slack, GitHub, and Twitter. We need to continue building trust with Xcode developers because every new person that joins brings new ideas and challenges for us to solve.

In rare scenarios, developers go further and contribute with code themselves. It's a huge effort because they need to get familiar with a new codebase (architecture, guidelines, patterns, business logic, testing strategies...). This is where many contributors drop in the contribution funnel. They had an idea for something to contribute, but they felt overwhelmed by the project. Have you ever been in that situation? It's even worse when the project doesn't have documentation for contributors. The only thing they can do is to clone the repo and figure things out themselves. Unfortunately, this works when the project is small, but as you can imagine, it becomes indigestible in large projects.

Because external contributions bring diversity of ideas and new energies to the project, providng the best contribution experience is an important aspect in Tuist. There's still room for improvement, but I'm glad of what we've achieved so far. First of all, we have documentation for contributors. They can learn how to get started, test their changes, and report bugs. Moreover, the project's modular architecture minimizes the surface of the things they need to learn before being able to contribute. For instance, if you want to optimize the generation of Xcode projects, you can focus on the TuistGenerator target and ignore the others. When everything is under MyProjectKit and the different components are strongly coupled, contributors have a hard time reasoning about the project's logic and forming mental models. Tuist's architecture is documented too.

Furthermore, we include a Ruby CLI tool, Fourier, to automate all common tasks. It also ensures that everyone's interaction with the project is consistent. That makes it easy to debug reproducibility issues when they arise.

Contributors also have access to a Slack group and community forum where they can seek advice and talk with other contributors and maintainers. We are luckyto have a very supportive group of contributors that are always open to give anyone a hand.

One of the things I'd like to improve next is the configuration of the environment to ensure everyone's environment is consistent. For example, ensure everyone is using the same Ruby, NodeJS, and Swift versions. We'll balance building for contributors and users. Both make Tuist the best tool of its class, and therefore both need the same level of attention and support.

This post is a list in no particular order of the things that I learned and experienced:

• People are unpredictable. - Management work is hard to measure. You can't count it and it's hard to reflect on it. - Achieving a balanced team state is an impossible task because of external factors that you don't control: reorganizations, people leaving, priority shifts. - A team larger than 5 people is not a good idea. Your management starts to suffer and your team notices it. - Exiting someone from the company is tough. - Being recognized for your work is unusual, but when it happens and it comes from your reports, it's very rewarding. - Sometimes you don't have answers for all the questions, and that's fine. You need to be comfortable being in that situation. - Seeing people leaving is sad. It's hard to to wonder if you could have done things better. - It's great seeing people progressing in their career and growing the impact of their contributions. - A road map you come up with today won't be valid in a few weeks from today. The world is dynamic, so is the company and its priorities. - Reorganizations are sometimes hard to digest. When they happen people move around, other people leave, and you have new objectives you have to accommodate to. - Context switching is an important skill to have. You mustn't let it make you a zombie at the end of the day. - The role of business partner is crucial to find answers to your questions and provide guidance when necessary. - Getting feedback from other managers when doing impact reviews is very useful.

And at this point you might wonder what led me to go back to individual contributor. I enjoy building. I enjoy opening my laptop, putting my headphones on, and creating things with code. I do that with Tuist and I used to that before taking the manager role. I also like mentoring people through working together in problems. That's how I met Marek, who recently joined the organization.

Shopify is a great place to grow as a manager. You have great tools and excellent managers you can learn from. There's even a framework to ensure management is consistent across the organization. However, and as I mentioned earlier, my path is on the technical track, and I'd like to continue solving problems with code.

When it comes to planning work, many organizations built their processes upon existing tools. As a result, they end up accommodating their organization to the tool and not the other way around. For example, they introduce a tool like Jira and all of a sudden everything is ticket-oriented. Teams have backlogs full of tickets. Some people get obsessed with cleaning backlogs and prioritizing tickets. Ticket gurus emerge and training are organized to use Jira the right way. That always annoyed me and I was glad to see that Shopify invested in doing the opposite: design a framework, GSD (Get Shit Done), to plan work and build tools around it.

The tool that you use to manage the project is an implementation detail of the developer or the team. You wanna use GitHub issues? Go ahead. Do you prefer Trello instead? That's fine too. The focus is shifted from the tool to the actual project and what's trying to solve. I think this is the trap many organizations fall into: they get too distracted with the tools.

A project is first proposed. Stakeholders ensure the problem or need is well defined, and that it's worth solving right now. This ensures people are working on the right things. If you can't relate your work to the organization's needs, then you need to take a step back and try to understand the thing you are tackling. Proposals can include a video, and go upwards in the hierarchy for approval.

Once approved, the project is prototyped to explore different potential solutions. Once stakeholders agreed on a solution, the project moves to build and the actual execution happens. Simple, yet powerful.

Along the process, Vault can be used to keep track of the project. The project champion is responsible for sharing updates with the stakeholders. A project has a feed where you can see a timeline of the project's evolution. It also has deadlines and checks that you can run with the project contributors assess the health of the project: is it moving steadily? is the direction clear? are there any unexpected roadblocks?

And because the organization is large and there are many projects are being executed, you can follow the projects interest you. You can filter the signal from the noise and only get the updates from the projects that you are interested in.

One thing that I think it's also cool is that there's a champion role. A person ensures the project moves forward and that decisions are made. And yes, if it's a development project, that's the developer. Developers also feel empowered when driving projects.

As I've said a few times in the past, Shopify has done amazing work at having the best tools for their needs and this is yet another example of that. Product is important, but also the tools the people in the org use to build the product. There's so much inspiration to gain from Shopify that I can apply to the way the Tuist organization is managed.

If Shopify sounds an exciting place you'd like to work, let me know and we can talk about opportunities over here.

On the other side, Ruby and its ecosystem is more harmonious and peaceful. If something works, it's very unlikely that it breaks. If there's already a Ruby gem that does something, people are more inclined to contribute to it instead of reinventing the wheel. No hype fatigue. The language that you ship is the language that you write. You don't need layers of transformations to accommodate your code to the environment in which it'll run.

Because of all of the above, I've migrated this blog back to Jekyll from GatsbyJS and I've taken the opportunity to overhaul the design with something more boring and developerish. I want the focus to be on the content and not the aesthetics.

I've so decided to stay away from unnecessary abstractions upon standards like HTML and CSS. I got hyped into the CSS-in-JS and TailwindCSS without realizing the value they provide is not really necessary in my projects. Moreover, the closer to the standards and the fewer abstractions the better for the long-term sustainability of the projects. If I write HTML and CSS today, I can open it in years from now, and it'll very likely work. If I to do the same with a React-based website that is processed by Gatsby through Babel, the chances are that it won't work in a few years.

It's been great to learn about those technologies and seeing companies pushing the web forward through them, but HTML and CSS and a bit of Javascript are enough to create value and share my ideas with everyone.

Stay safe!

I learned that people are unpredictable and that sometimes there are behaviors you can't explain. I changed my mindset from creating impact myself to create impact through people. This required figuring out who to put together on which problems to create the most creative solutions. I teamed senior and junior people up to level up people through mentoring. I defined a vision for the team and learned that in large corporations priorities change so much that you can't stop iterating on them. I set up secondments for people in my team to have a first-hand experience with the products we build tools for, and keep our trust battery with them high. I put up promotion cases for people in my team and had to exit a person from my team because he was not meeting the expectations of the role. It's not a pleasant experience, but I stretched your emotional intelligence by going through it. I leveraged my community and open-source connections to bring talent to Shopify that I'd like to work with. I've done tiny code contributions trying not to step in the way of the people in the team but most of the time I did. I evangelized my passion for building great developer experiences that are easy to use. I fought complexity and indirection introduced by configurability. I recognized my team's work internally and externally and shared with the community how awesome it's that Shopify invests in their own tooling. I had weekly 1&1s with the people in my team, provided feedback, and valued their impact through company-wide calibration sessions. I set up an on-call policy to provide support to the rest of the organization. And in all this journey I was extremely supported by the organization and its tools and resources.

I learned a lot by being a manager but I miss coding so much. I miss getting my hands dirty by building new tools and improving the existing ones. I tried to squeeze coding time into my manager's responsibilities but ended up frustrated because doing deep coding was impossible due to the frequent context-switching my responsibilities required. For that reason, I'll soon swing the pendulum of my career back to be an individual contributor again. In hindsight, I think it was a great idea to go through the management experience because I've learned so many useful things that will make me a better engineer.

The change will happen in a few months when the new manager is up to speed and ready to take the team. I'll remain in the React Native Foundations team and work with the folks on the team to shape the experience of building React Native apps at the company. Exciting times ahead!

Focus takes your project's dependency graph, and prunes the elements that are not necessary for you to work on target X. That includes references from schemes. Since there are times when you might want to focus on more than one target at once, you can pass the list of targets as arguments: tuist focus MyApp Search. But that's not all. We integrated this concept with the caching of target binaries. In a nutshell, the direct and transitive dependencies of your focused targets are replaced with their binary representation. The binary can come from a local cache, and soon, from a server-side counterpart, TuistLab. Amazing, isn't it? This is what I've been hoping to see landing in Xcode, but instead, we've been told that the only solution is to replace Xcode's build system with Bazel. I don't have anything against Bazel. I think it's damn amazing. But it's not compatible with Apple's way of building tools, and because the integration leads to a bad developer experience, or good but with a huge ongoing investment, I avoid it.

Surprisingly, and as the stats show, tuist focus is not as used as tuist generate. It's hard to know the why, but my guess is that this is a workflow that developers are not that used to, and it requires some ongoing education and evangelization from our side. Or maybe there's something not working as expected and we don't know? If that's the case we'll soon find out because we are dog-fooding Tuist by building TuistLab.

As I mentioned in past blog posts, the opportunity to explore ideas with Tuist is what makes the project so exciting, and tuist focus is a good example of that. If you are using Tuist, I recommend you to give the command a shot. You won't get disappointed.

There are several reasons why that happens to me. The first, and well-known these days, are social networks. You've probably seen me talking about them in the past, so here I go again. I tend to spend my free time doing endless scrolling to keep up. I think that's one of the main contributors to feeling exhausted, yet I can't stop doing it. Moreover, at work there's a lot going on. Because of the size of the company, and all the context I've got over the past years, I spend my days helping here and there: sharing context with other people, unblocking the users of our tools, digesting information that is floating in the organization. Again, I think I've got better at this, but I miss having focus.

On top of all the above, I'm so curious that I can't stop exploring new ideas and problems to solve. As a result, my mental energy scatters across many different places, and I end up nor learning nor doing anything. I think the English saying for what happens to me is "Biting off more than you can chew" (thanks Google).

So here's what I'm going to try. First, I'll accept my time and energy boundaries and be mindful about them. I'll continue learning how to prioritize and say no to things. Both, at work and in open-source duties. Moreover, I'll center my open-source efforts around only two projects, Tuist and Buildify. As much as I can, I'll try to spend less time on social networks (attempt number 125125).

Hope you are having a great week and stay safe!

After releasing tasks and overhauling our website to reflect the new brand, we'll start working towards 3.0. What does that mean for the project? Besides improving project generation, for example by making it faster and handling more project scenarios, I think we should focus on the following elements:

• Thinning Tuist: We built many commands into Tuist that should be opt-in and extracted from Tuist. For example, the tuist doc command doesn't necessarily have to be implemented by Tuist. Our work on plugins and tasks will allow that. Those commands will be distributed as plugins and live in different repositories. - Dependencies.swift: We should continue investing in this project and have great support for Pods, Packages, and Carthage frameworks. How to integrate third-party dependencies into Tuist project is a recurrent theme and therefore we should provide first-class support for it. - Cross-repository dependencies: At the moment, a Project.swift can't define a dependency with a Project.swift that lives in another repository. Because of that, teams end up creating a Package.swift alongside the Project.swift to be able to consume that dependency as a package. Although this works, it prevents developers from leveraging graph optimizations such as tuist focus. I think we could build a decentralized dependency resolution logic into Tuist inspired by the SPM and step into SPM's domain. Just a tiny bit 😁. - Lab: If graph is a cornerstone component in Tuist, a server would take Tuist to a whole new level. Lab would be that server. Developers would have the option to self-host it, or use our paid hosted instance, and therefore financially support the project. Lab would allow things like: - Reporting build insights on PRs - Define tripwires and alert teams on Slack or PRs when they hit them. - Cache your project's binaries remotely and share them across the teams. - Have an internal registry of frameworks and libraries that you can reference from your projects.

I'm sure more ideas will pop up down the road, but the ones that I shared above will most likely be our focus as we enter this new chapter. We'll continue to listen developers, their challenges, needs, and collaborate to figure out how Tuist can help them the best way possible.

Thanks for reading.

As I keep thinking about the problem, some ideas are starting to emerge. For example, providers like Google Cloud and AWS, offer a serverless solution for containarized apps. In other words, you can provide them with your Rails application in a Docker image and they'll take care of scaling the resources are needed. This simplifies things a lot on our side because we are mostly responsible for building deployable artifact that can then be handed over to the cloud provider. For long-running services those deployable artifacts will be Docker images. In the case of lambda functions and static websites it'll be a tar file containing the HTML, JS, and CSS following a conventional structure. And for mobile apps, it'll be the Android App Bundle or app archive without signing. The signing will be done server-side.

I'm also planning to abstract away the provider through an interface. That way contributors can add support for more cloud providers. Looking at Google Cloud and AWS, they both have similar offering, but with different names. The initial version will have the implementation for AWS. Since AWS offers Mac minis, we can use those to run certain tasks that can only run in macOS environments, like signing an iOS app.

A tool, buildify-runner, will take care of running deployment tasks. I'll write it in Rust so that it can be run in any hosts without requiring anything else to be installed in the system. It'll pull the build DAG, and execute it trying to parallelize as much as possible. For example, when deploying a RedwoodJS, the runner will install the NPM dependencies, and build the static files and the functions separately. For reproducibility reasons and stability, the runner will use Nix. Thanks to that, we get caching of dependencies out-of-the-box. I believe using a tool like Nix for setting up the environment will be crucial for providing a great developer experience.

The concept of previews that got popularized by platforms like Netlify and Vercel, will be present in Buildify too but with some enhancements. It'll work with databases and mobile apps too. In a nutshell, we'll create disposable databases whose lifecycle is tied to the lifecycle of a repository branch. When the branch gets merged or becomes stale, the database will be dropped automatically.

The process of onboarding new apps must be as seamless as possible. People that have never deployed a project before should have a running app without having to familiarize themselves with infrastructure and deployment concepts. To achieve that, the runner will have a command for cloning a repo, parsing its content, and reporting to the backend all the projects found in the repository. For example, if it's a Rails app, Buildify will detect it and create the database and a Redis instance for being able to run background jobs.

And last but not least, because my background is mainly mobile development and tooling, I think this platform should work for mobile apps too. The release process will be a bit different though because continuous deployment cannot be extrapolated to mobile apps. In this case we'll use release branches where each commit will represent a releasable candidate that can be uploaded to the App Store and Google Play Store.

I'm very excited to kick off this project. I've been reading a lot lately about projects like Ghost and Plausible, whose revenue is re-invested in the project to make it better and continue to help their users. I feel we need to take back from VCs the problem of easing deploys, and build a community-driven and open-source project that goes hand in hand with those great open-source web frameworks that we've seen over the years.

As you can imagine, I'll be less active on Tuist, although I'll continue to provide advice and direction on the project.

I have to say the process of setting it up was pretty straightforward thanks to vite_ruby, a Ruby Gem that eases the process of integrating the tool into Rails's asset pipeline. Moreover, it provides helpers to add the necessary helpers to load the generated Javascript and CSS files. The resulting configuration is leaner than its Webpacker counterpart and easier to reason about. Vite is not as mature as Webpack, but it's already got a good community of plugins around it. For example, the legacy plugin takes the role of @babel/preset-env to polyfill our Javascript to support old browsers. The React plugin can reload your component changes instantly to make your development experience smooth.

I really like the amount of utilities one gets when building for the web. You can choose the one that works best for your project, and accommodate it thanks to the numerous APIs that they expose.

It's just the beginning of my learning process but I have to say I like the openness of its community and tooling, and the interesting concepts such as ownership that come with it. Swift feels authoritarian and constrained by Apple after getting immersed in Rust. I also like about it that you can easily do cross-platform compilation and use the editor of your choice. Let's see how it goes, but I think it'll become my go-to compiled programming language over Swift. Using it is so liberating and you can feel it's purely community driven.

Tuist's documentation website was built as part of Tuist's website, which is developed using Gatsby, and it grew a lot since then. Because we haven't had a person dedicated to overview the evolution of the documentation, we ended up with a lack of cohesion and hard-to-navigate documentation. Developers have a hard time finding what they need, and getting started on the project.

For that reason, I set out to improve the documentation website. As a firm believer of choosing the right tool for the job, I took the opportunity to move the documentation to Docusaurus, a React-based utility implemented by Facebook to create static documentation websites. It provides all the features that we need: MDX, code snippets, search. For the past weeks, I've been working on moving the documentation over to the new website, which is available at https://docs.tuist.io. As part of the process I set up redirects from https://tuist.io/... URLs to the new ones, and fixed a handful of broken links. It's looking great so far. I'm waiting for Algolia DocSearch's response to enable search on the website. Once everything is moved over, I'll work on adding a tutorial along the lines of what RedwoodJS does. It'll be useful for developers that come across the project and decide to give it a shot. The tutorial will guide them through most important Tuist features that they should be aware of.

It's amazing everything React enables. Trying to achieve this with other static site generators would have taken way more work and the result wouldn't have been the same. If you have a project that needs documentation, you should definitively consider Docusaurus, even if you have no prior experience on React.

Theme-UI solves the steep learning curve issue well. It introduces the notion of theming and responsive values without having to abandon the CSS language. Moreover, it’s built upon a theming specification defined by the same author. The downside though is that you need a JS-based UI and you can’t copy and paste styled HTML elements as you’d do with Tailwid.

My preferred option these days? My preference has been swinging, between the two, but these days I’m more inclined towards Theme-UI. The reason being is that I’d like to familiarize myself further with the CSS semantics and learn how to build great web UI experiences using as raw building blocks as possible. Copying and pasting styled components feel pretty much like solving code problems by pasting snippets from StackOverflow. You can create and solve things, without understanding the fundamentals of the solution.

On one side there's Apple, a large business whose final goal is to sell hardware. They announced Swift and everyone got excited not only because it was a new and more modern programming language, but because it was open source. Since then, we've seen more open source work coming from Apple: swift-log, swift-metrics, swift-nio, and swit-collections. It's great to see work being done in the open, the community gets excited about it, but the one who steers the boat is Apple, and the ultimate decision on what goes into Swift is made by Apple and not the community. There's nothing wrong with it. It's just another approach to open source where there's a business that needs a strong ownership to ensure the open source work supports the business. The caveat though is that the community around it doesn't flourish as much as it'd do in community-driven projects like Rust. Everyone is hoping for that next thing that will solve their problems and help them with their needs. Reactive programming is not new in Swift, yet they made everyone think Combine is the way. Nowadays, no one thinks about exploring new reactive programming approaches. Similarly, no one thinks about exploring new solutions to package management. In fact, we are neglecting community work done in the past. This inevitably leads to a slightly authoritarian open source environment where diversity can't find its space.

On the other side, Rust is entirely community-driven. Even though it was born within Mozilla, it became a community project. Because of that, there are plenty of utilities, packages, and resources to build great software upon it. One might see such large list of options as something negative, but I'm getting to appreciate after having done years of Swift and iOS development. It's easy to find a community utility that suits your needs best, or explore new alternatives because the project welcomes those.

I think both are valid approaches with understandable motivations behind them. Personally, I'm enjoying a lot the freedom more community-driven projects like Rust, Javascript, and Ruby provide.

You can't build a tool that satifies every team's needs. You can't design Xcode to work for the tiny startup that is building a simple app, as well as for a company like Facebook that has a complex project with many inter-dependent targets. Apple optimizes for one type of app, the one that is the most common across all the projects: a mono-target app that might have extensions and support for multiple platforms. In that setup, Xcode works fine. You create your project using Xcode's menus, add a new target when needed to extend your app, and add third-party dependencies through the Swift Package Manager integration. Xcode, the project format, its build system, Swift, and all the surrounding tools are designed for that. There's nothing wrong with that, except that those developers that need more are left out of the equation. Their projects take a long time to compile, tiny changes cause the build to break, and Xcode is not as responsive as it used to be. Companies like Uber have suffered a lot from this. Others have adopted Bazel as a build system to escape the problem, and need dedicated resources to keep it working with every Xcode/Swift update.

There must be a better way to scale. Finding an answer to this question is what fuels me to build Tuist. I think the answer to this comes down to flexibility. The flexibility to extend, optimize and even replace the build process without having to leave Xcode. The flexibility to declare my project's graph, optimize it and validate it early to prevent errors down the road that cause developers' frustration. That flexibility could be achieved with Xcode opening more APIs instead of building inside itself and treating it as a black box. However, that's not the direction Apple is taking, and we are seeing that with Swift Package Manager's integration into Xcode. One of the reasons why other programming languages are used over Swift when building software at scale is the flexibility of their tooling. In Ruby, you can customize your test-running logic andd add types to the language. In Javascript, you can implement plugins that extend your build process and that add new linting rules that integrate seamlessly with the editor. Having a Language Server Protocol (LSP) is a good step forward, but it's not enough.

Because Apple doesn't open those APIs, Tuist is taking the role of opening them for developers. We are doing that by leveraging Xcode project generation. We abstract the project.pbxproj format with a more declarative format that can be extended easily. Developers love that, and the fact that Apple doesn't change their mindset is positive for Tuist because they create a room for the project to thrive.

I started building Tuist motivated by some challenges that I wanted to overcome, and over time, we turned it into a group of aligned people collaborating towards the same goal; extremely talented software crafters from different locations building upon a foundation that I helped build. How did it happen?

First, Tuist is the reflection of the education that I received from my family. They taught me that happiness means spending time with people. That unlike capitalism tries to prove us, happiness is not about climbing ladders, getting a higher salary, or working for your dream company. For that reason, I made people a cornerstone in Tuist.

Since the moment people show up in Tuist, we spend time connecting with them and empathizing with the motivations that led them to adopt the tool. They feel heard by other humans beings, and that’s a great feeling in an industry that is trending towards dehumanizing technology with solutions like bots. Moreover, we invite them to contribute to the codebase. We give them the necessary pointers and even pair with them on nailing the first contribution. They go from I don’t know how to take the first steps in this project to nailing their first contribution and getting inspired to ship more.

We trust the people that join and let them prove us wrong. This is something that I learned at Shopify. Assume good intentions from the people around you, and work on having a charged trust battery with them. That has a tremendous effect on people. They feel inspired to contribute further, build their own tools, and do the same with other people joining the community. It cascades rapidly, and because doing great things for people can get very far, it has the side effect of bringing more diversity of ideas to the table from people that otherwise wouldn’t have contributed.

When I tell people that I do that without getting money in return they think I’m crazy. They think I’m wasting my time that I could otherwise spend becoming richer. What they don’t realize is how happy I am helping other developers overcome challenges that I had to go through, and seeing community members spreading goodness across other developers. It’s not about money, it’s about people.

When I was young, I used to work over the weekends in my family's cafe. What I remember from those days, and I can still see it in my parents, is how happy they are earning an average salary but having the opportunity to interact with people all the time. Open source is my modern cafe where "cafe con leches" became code.

I have to say though that I’m privileged of having a paid job that allows me to spend spare time on Tuist. Money is a component that we can’t remove because we need it for living, but it can be a secondary one.

As expected, there were some negative reactions to this:

• Oh! I’m glad that I can opt out. - And yet another tool that succumbs to the data-driven method...

If I put myself on their shoes and after seen what large corporations have done with the data I’d react the same way.

However, there’s a subtle difference. We are an open-source project, and such, the time can we can devote to the project is limited. It’s people working outside of their usual working hours to make the tool better. If we don't know how the tool is being used, we don't know if the limited time that we have is well-invested. It's not about us using the data to sell them something, it's about us using the data to make the tool better.

Interestingly, there are more tools out there that they might be using without realizing that they are also collecting data for the same purposes: Homebrew and CocoaPods. Every pod install they've run, has sent data to CocoaPods to better understand how frequently Pods are used. Every brew install X has sent data to Google Analytics to know what formulas are used the most. And yes, Fastlane does it too.

Because we know this is concerning, we have taken the approach of not only having all the code for collecting and sending events public, but we've built our own Rails app with its own database on Heroku to store the data. Tuist's data is our data, not Google's. It stays within our domain. And because we own it, we'll apply the same values to it that we've already applied to the code that users are already using.

First, I think Tuist's focus should be on the project graph, the generation of projects, and the build and test commands. We've invested four years into building a solid graph that we can optimize and turn into Xcode projects. Developers love that! They no longer have to think about linking or embedding build phases. Tuist makes them an implementation detail and knows what changes can be applied to the resulting Xcode project to be fast to index and compile.

What APIs can we expose? The two that I think would be very valuable are Setup.swift and Tasks.swift. The first already exists. Developers can define how to configure an environment before interacting with the project. However, I'd change the approach to be imperative instead of declarative. Basically, instead of Tuist parsing the file and then translating the steps into system commands, we'd run the Setup.swift file directly as if it was a command line tool. Tasks.swift is not yet implemented but it'd allow developers describe their workflows in the same way they currently do with Fastlane. The difference is that Tuist'd provide them with information about their projects, like the dependency graph. How cool is that? Let me dump some pseudo-code below:

import TuistAutomation

let tasks = [
 .task(name: "swifltint") { tuist in
 let graph = tuist.graph()
 let sources = graph.sources()
 tuist.system("swiftlint", ....)
 }
]

And this would align with the work that we are doing with plugins. Developers would be able to extract their tasks and up commands and wrap them in a plugin that they share across projects and with the community. Same as if they were sharing Fastlane lanes ❤️.

It's exciting seeing everything that project generation enables. As I've said a few times, project generation is a means in Tuist to help developers with the challenges at scale. Using project generation for only getting rid of git conflicts will not help you with a plenty of problems that you'll see down the road.

The difference between the Javascript bundlers and us is that we don't allow developers to define their custom transformations. Fortunately, that's going to change soon thanks to plugins. Developers will be able to encapsulate their transformations into a plugin that they'll be able to distribute to Tuist users. How cool is that? We took a very closed and monolith project format, .pbxproj files. And we are turning it into a more open format that developers can extend and optimize.

This is the beauty of Tuist.

Sure, by doing that, Apple has stronger control over the ecosystem, and therefore, over the developers' apps. However, there are situations when the proposed method doesn't work for your scale. Then you need to come up with creative ways to accommodate Apple's processes to your needs. An excellent example of that is replacing Xcode's build system with Bazel and figuring out how to get Xcode to compile with Bazel instead of using its build system. The result of that setup looks more than a hack. It's brittle. One day it works; the day after, it doesn't. And because Apple is so distant from many real challenges developers face, they continue building around their utopian vision of app development. That one where apps are small, a few targets, and dependencies are seamlessly distributed via Swift Package Manager.

The reality is far from that. The day-to-day is way more convoluted than what Apple thinks. And because Apple doesn't embrace that and provides more flexibility to customize processes, teams have no choice other than to wait for the next WWDC to see if Apple decides to tackle the issues they are facing.

In Javascript, you can choose your build tool. You feel like using Webpack? Go for it. Is it too slow? You can use alternatives like esbuild. You need to lint some code? There's eslint. Don't you have the rule that you need? You can implement your custom rules. You need to generate code at build time? You can use Babel and implement your own macros. Would you love to extend VSCode's interface to show useful debugging information? You can use the Extension API.

And because of all of that, Ruby and Javascript are excellent as general-purpose programming languages, while Swift remains that language for building apps for Apple's ecosystem that dreams of becoming something more than that.

While working on Tuist, it’s common to see users creating issues saying they need something without giving context on why they need it. And it’s also common to see other contributors and maintainers moving the discussion along without figuring out the reason that prompted them to create the issue in the first place. We can’t design great solutions if we don’t understand the needs very well.

My role as lead at Shopify and core maintainer at Tuist often comes down to reminding people about the importance of understanding the need or problem. In the case of Tuist, this is done through discussions on GitHub issues, and at Shopify we often do it through user interviews. It sometimes requires a few whys until the developer surfaces their motivation. In some odd cases, it leads to the realization that they don't know the need or that there's already a solution for it.

Once identified, I nudge people to find the simplest solution that solves the problem. Still during this phase developers think far ahead and imagine how developers would use the feature and why that usage justifies the level of configuration they want to introduce into the feature. But do they need it? Most of the times the answer is not now.

In the space of Xcode project generators, this mindset is a key and highly-appreciated differenciator compared to other alternatives. Although they turn the .pbxproj into a more readable and shorter version of it in a YAML file, it's still the same complex concepts and configuration that makes the process of evolving Xcode projects a difficult task. With Tuist, every request to port an Xcode feature into Tuist's APIs is looked from the angle of what are you trying to achieve with it. I like how DHH calls it on his keynote talk from RailsConf 2018, conceptual compression. If we, crafters of tools, own complexity to provide simplicity, the resulting tools will noticeably spark more joy when using them.

And last but not least, I the process of turning a problem into a solution requires a thorough thinking. We should let the idea sit in our mind for days, explore different solutions, and very importantly, understand how they fit into the project and aligns with its direction. That sometimes means saying no to the idea. I think taking this process as a marathon and not a sprint can make a huge difference in developer experience. If you treat your GitHub issues as an inbox where you goal is to get down to zero and implement everything you've been asked for, there'll be plenty of interesting ideas, but that they don't know how to talk to each other.

The Swift Package Manager is dependencies-oriented while Tuist is projects-oriented. SPM does a good job resolving and pulling dependencies, and providing a standard CLI to build and test your packages. The developer experience integrating it with Xcode is questionable good, but it works in most cases. I say it's questionably good because when used at scale, like it's the case in Tuist's codebase, it's a bit frustrating seeing Xcode very often invalidating the dependency graph, or failing to resolve it and having a project that can't compile. Because SPM is dependencies-oriented, the workflows are designed around that. This might change depending on the direction that Apple takes with the tool, but if that doesn't change, I doubt we'll improvements that projects need at scale.

On the other side, Tuist is designed as a tool to make the experience of maintaining, interacting and scaling up your projects the best. Because the people behind Tuist maintains large-scale projects, we are building features that can make a huge difference in developers productivity: project description helpers, focused projects, caching, and standard interface for third-party dependencies (not only packages). If Apple is that giant corporation that come up with utopian visions of developer experience towards which many teams are biased (i.e. authoritative bias), we are the tiny startup that stays close to the developers and their pains and solves the problems that they bring up. And because we don't have to align our ideas with any business's direction, it's easier to explore and execute ideas.

That being said, it's possible that Apple changes the direction of the Swift Package Manager and turns it into a project manager. However, and as we've seen in the past, I think they'll continue distant from the real problems that developers face. The future of developer tooling around managing your Xcode projects is exciting.

This time the work was replacing models that are very core to Tuist's domain: the graph and all the models associated to it. When I built the first graph structure, I didn't put too much thought into how it should be. I was led by intuition. I added a reference here, a subclass there, and everything seemed to work. It worked so well that we have built the majority of the features on top of it.

We could have continued building upon that graph, but the further we moved, the clearer it was that we needed more flexibility, safety, and an easier to reason about graph. Unlike the old graph that used in-memory references to represent dependencies, we implemented the new one as a struct.

The edges of the graph are represented by dictionary key-value relantionships, and the nodes by enums. Everything is defined in a model so at a glance you can see its format. Moreover, we built a traverser that wraps it and provides efficient methods to traverse it. Those are useful when generating the projects because the logic needs to traverse the graph a few times to obtain information like what linking build phases should be added.

The new graph is already used by many components, but there are still some left. Doing this work made me realize how core this model is and why it makes Tuist's project generation so unique. It's certainly not as interesting work as building new features, but I'm motivated by the fact that this refactor will enable so many future improvements and new features.

If you see me not talking too much about new Tuist features is because I'm spending most of my time making this possible.

As a developers we have to make many decisions along the day, and the result of those decisions is most of the times code. However, if the code doesn't speak for itself, it's extremely useful to add a companion narrative that adds the context necessary to understand the story of the code. It takes practice to build this habit, but I think it's an important one to build as you become a more senior engineer. Piling up undocumented decisions in a project is the perfect recipe for misunderstandings and frustration.

I'm working on building that habit and making decision records a core piece of every repository that I'm responsible for maintaining.

To regain the focus that I used to have then the project was small and only a few people I started taking action. First I'm time-boxing the time I use checking notifications, Slack messages, and pings on PRs. I think spending between 15' and 30' minutes per day is enough. If something comes up after that daily time it has to wait until the next day. Moreover, I'm trying to document and automate as much as I can. I introudced a new tool into the project, fourier, that will become the place for all utilities necessary to work on the project. Most of the answers on how to do things will be in either the tool or the documentation so people shouldn't need me to answer "how do I do X"? Also, I'm encouraging people to use asynchronous discussion channels like GitHub PRs and issues. Unlike Slack where people feel the freedom to catch your attention, it's you who decides when is the time to read the discussion on GitHub. You are the one controlling your attention.

Let's see how that goes. One of the reasons why some maintainers give up on open-source projects is because they can't cope with the maintenance burden. I don't want the same to happen in Tuist and I'll work towards that.

Unfortunately, such beauty hasn't existed for years in the Swift community. Fastlane gives you the tools to define the lanuage; you get words, but you are the one coming up with the language. The reality has proved that defining a coherent language while building an app it's not easy. Teams end up with complex and hard to optimize logic that is a nightmare to maintain. It's not Fastlane, their building blocks are great, but their approach naturally leads to this.

When people ask me why Tuist provides now commands like build and test, my answer is simply that there's the need in the Swift community for a different approach to interact with projects. An approach where we write the language, we make it simple and enjoyable to use, and you focus on building great apps.

You describe us the projects, and we do the rest.

• Great mission: The company has a clear and realistic mission that they go after, and most importantly, leadership believes in it. I'm noticing more and more companies emerging with CEOs with a utopian view of the world and throw many investors' money into the problem with the dream that the world will be shaped as they want it to be. - Leadership understands technology: And, therefore, can make informed decisions. When we decided to adopt React Native, it was a meditated decision that the CEO could see aligning with the company's direction. - They trust you: All that friction you see in other companies where you have to escalate the "can you give me access to" ladder doesn't exist at Shopify. They trust people, and people trust each other. We have a concept called "trust battery", and it's essential to have it fully charged with the people around us. - Technology is a means and not an end: Shopify is often criticized for being old-school with their Rails monolith, and very recently, for adopting React Native as the default technology for building mobile apps. However, I learned to appreciate that any technology in the right hands can get you to achieve great things. I've seen companies writing native Swift apps or complex micro-services backends whose business and user experience is broken. What's the point of being on the latest if you can't provide excellent value to your users? - You have a path for growth: Since I expressed my interest in leading a team, my manager trusted me to give it a shot and start taking steps towards it. Since then, they've provided me with resources, guidance, and support to help me grow every day. Similarly, I've seen other folks changing teams and paths to explore new areas. - Not afraid of black boxes: Unlike many companies that are afraid of change when they find their comfort zone, Shopify likes and embraces change because they accept the world is continually changing, and we need to evolve with it. A couple of examples of that are the adoption of React Native and becoming digital by default. As soon as the pandemic started, the CEO accepted that the new normal wouldn't be the same and that we should be the first to figure out what it'll be like and not the last. The whole company is learning how to be remote, and it's fantastic to see everything they are doing to support this transition. - Extremely talented people: Shopify is full of crafters that are passionate about what they do and from which you can learn a lot. I've had the opportunity to learn a lot about people management, design developer experiences, and manage projects. - A great developer experience can make a difference: The opportunity to work on tooling full time is one of those things that got me into Shopify. It's a company that doesn't see tooling as an after-thought. A great tool can save you time and bring you the focus you need to build the product. We have teams dedicated to tooling for different development areas: local environments, cloud environments, test infrastructure, mobile, web...

Overall, I feel valued. I get the space that I need to be creative. I'm surrounded by a fast and inspiring environment that motivates me to challenge my static visions of the things around me continually.

I'm not sure if the community will be willing to embrace that direction, but I'm convinced the developer experience can improve significantly. It reminds me to the moment I had the realization that Tuist was necessary and I set out to build it.

React for building web frontends

I like React's approach to building declarative UIs. The React's movement led to an explosion of community components that make building UIs feel like LEGO, and great tools and processes like CSS-in-JS that save you a lot of time and improve the developer experience. I haven't tried Vue myself; therefore, I can't say much about it. I'm not a huge fan of Facebook steering the framework, but I'm optimistic it'll become (if it hasn't been done already) a community-driven project.

Gatsby for building static websites

After embracing React, using Jekyll and its partials felt old-school. The introduction of dynamic behaviors resulted in writing imperative Javascript that calls DOM APIs. I wanted to use React's declarative approach, and GatsbyJS allowed that. When I came across GatsbyJS, were a bunch of concepts that I had to learn. For example, its method to decouple the UI from the data sources using a GraphQL API. The learning curve was a bit steep, but after passing it over, using Gatsby is a pleasure. And because it's built upon React, I can reuse components and utilities built for React. When I see frameworks like Publish in Swift, a programming language that I'm emotionally attached to, I always think there's no way I give up on React's awesomeness and convenience.

Netlify for deploying static websites

Netlify is an excellent example of an abstraction that improves the experience of putting a static website on production. They provide an environment where my Gatsby websites can be built, and placing the resulting HTML artifacts in a CDN network that I can point my domains to. One of its breakthrough features is deploy previews. They deploy PRs to temporary environments so that people reviewing your PRs can check out the changes live. They provide many other features, but I haven't used them yet.

Rails for building web services

I might be biased here because I work at Shopify, but I enjoy building web services with Ruby on Rails. I can confirm both the programming language and the framework spark joy when using it. I'm not an expert in any of both, but I reached a point where I feel fluent, and I can't have something up and running quickly. What I also like about Rails and Ruby is that there's less fatigue compared to Javascript. Suppose you need a database ORM; ActiveRecord is there to help. If you need to expose a GraphQL API, you can use GraphQL Ruby.

These are the Gems that I usually add to projects: Devise for authentication, Pundit for authorization, Sidekiq for running background jobs, GraphQL Ruby for defining a GraphQL API, Webpacker for using React as a frontend that interacts with a GraphQL API, and Rubocop for code linting.

Heroku for deploying web services

I'm not an infrastructure person, so I appreciate services that put my code into production. Netlify is that service for statically-generated websites, and Heroku is its counterpart for long-running services like Rails applications. I can create a new project, link it to a repository that contains a Rails app, and in a matter of minutes, I have a Rails app up and running on production. I can add a PostgreSQL database and a Redis instance that I can point Sidekiq to through add-ons.

As a side note, I have to say I like the run feature, which allows me to open a Rails console with the production instance and debug issues in production:

heroku run rails console

GitHub Actions for continuous integration

Since GitHub introduced it, GitHub actions became the go-to continuous integration service. I like it because it's integrated into GitHub's UI. The user interface is fluid compared to other services that I've used in the past, and it's straightforward to reuse CI logic across projects by defining actions. It took a long for GitHub to step into the business, but I have to say they beat the market with an extremely high-quality product.

TailwindCSS for styling web interfaces

TailwindCSS is probably the discovery of the year. The framework introduced me to the concept of utility classes in CSS; after learning a set of semantic HTML classes that match to CSS styles, you can easily style your HTML without having to jump back and forth between HTML and CSS files. Moreover, classes delimit properties such as color and margin to a pre-defined set of values. As a result, UIs look more consistent and harmonious.

After coming across the framework, I followed the authors of it, x and y, and I've been a massive fan of the work that they've been doing. Another masterpiece from them is the RefactoringUI book, which teaches you ideas to build beautiful and clean UIs. I also paid for a license for TailwindUI, their set of pre-defined layouts implemented with TailwindCSS.

Ruby for command line tools

Even though I'm building Tuist in Swift to make it easier for users to contribute, Ruby is my programming language for building CLI tools. It comes with the system, I'm incredibly familiar with it, and there are many useful Gems from the community that I can reuse. Moreover, its dynamism makes it very suitable for experimenting with ideas and workflows. Doing something like that in Swift would require going through Xcode and its compilation cycles, which takes the focus away from prototyping and hacking.

VSCode for editing code

I love VSCode. It's a masterpiece from Microsoft. I can use it with multiple programming languages like Ruby and Typescript, extend it through community-built extensions, and configure it through workspace settings. Even though it's built with Electron, which inevitably means using more computer resources than other editors built natively, I haven't tried any other editor that is as close to as significant as VSCode is. Between developer experience and efficient computer resource usage, I lean more towards the former in this domain.

React Native for building apps

I like Swift and Apple's direction with SwiftUI, but I can't reuse the work that I do for Apple platforms in other platforms like Android and Windows. Shopify's adoption of React Native has taught me that you can build great products in React Native; you need to make the technology an implementation detail and focus on the product. In recent years I've shifted from treating technology as a goal to using it as a means to build tools that solve users' problems. To achieve this, I think React Native is the most suitable option, and I can apply all the concepts and learnings from building web UIs with React.

...and this is my preferred stack. What about yours? If you write a blog post about it and share it on Twitter, don't forget to tag me (@pepibumur); I'm curious to see what other folks in the industry are using.

In the Swift community, we've seen a proliferation of tools to help developers with different needs (e.g. generation of Swift interfaces from resources, code linting, dependency management) that inevitably led to a non-cohesive and complex developer experience where Fastlane acted as the glue. On top of that, the authority bias is nudging teams to have more than one dependency manager in their projects to stick to Apple's recommendations.

Below there's a common Xcode project setup with all the elements that are part of it and how they depend on each other. Note the estensive list of elements that you need to work on the project. There are a lot of caveats in such setup:

• Reproducibility is harder that might result in developers spending their time debugging inconsistent results across environments. This can happen for instance if Homebrew decides to install a new version of a tool on CI that introduces breaking changes. - The setup is difficult to reason about for a new person joining the project. Only the people that have been part of the design can have such an overview. It results in a terrible bus factor, which in large companies translates to the infra team or the go-to person that knows everything about the project setup. - Optimizations are not easy. Different pieces are so coupled to each other that introducing optimizations that have a significantly affect on developers' workflows is a challenging task. - Because there are many potential points of failure, when errors arise, they are harder to debug. Is this failing because of my CocoaPods version? Is it because of this pod lane that I'm using? Might it be related to the version of Ruby I'm using?

That's a setup prone to errors and stress for developers with which I'd never want to work. We've spent most of our time building great tools but not that much thinking about providing a cohesive experience when bringing them together.

For this reason, we continue investing in Tuist. We believe there's an opportunity for providing a Rails-like experience for developers building apps with Xcode. An experience that combines primitives from Apple like xcodebuild and tools from the community.

Anyone can and should be a project architect. To make this possible, developers need simple setups and APIs to describe their projects. Having an infrastructure team is useful to steward the project's growth, but there shouldn't be any strong dependency between feature teams and them. The trap many companies fall into is building this strong dependency where every time you need to do something that touches the architecture, you have to do it through the infra team. The setup must be simple. Embracing complexity is the formula for creating an environment in which developers don't want to work. Tuist owns complexity and the optimization of workflows to provide a simple and efficient workflows through the CLI. A more straightforward setup will make the environments more reproducible, and thus developers will have to spend less time debugging issues when they arise. To work with Tuist, teams only need to install Tuist, and that's it. No dependency on Ruby, Homebrew, nor Fastlane. It's you, Xcode, your project, and Tuist.

Developers might see this setup as rigid like many companies saw and continue to see Rails. But look at companies like GitHub and Shopify that were able to build excellent products in part thanks to the fact that developers could focus on building the product and not fighting the underlying tooling and frameworks. As apps become larger, the need for a Rails-like foundation becomes more important, and that's the place I think Tuist can take in the community.

What's tree-shaking an Xcode project Have you tried to open a large project in Xcode? Indexing is not immediate, the list of schemes is probably large and hard to navigate through, Xcode's features like searching are slower than usual. This is something we are, in fact, experiencing in Tuist's codebase, and it's very annoying. What if the generated project had a focus on a given target and removed everything that is not necessary to work on that target? In a modular codebase, that's a common thing to do. You work on the Search team, and most of your work is done in Search.framework. There'll be scenarios when you need to work on core frameworks, but most of the time, it's not the case. Well... that's what Tuist does when you run the following command:

tuist focus Search

We traverse your project's dependency graph and remove the elements you don't need to work on Search. Let's look at the example below:

We have a simple modular app with a layer of feature frameworks and another layer of utility frameworks. When we focus on Search we get that target and its dependant targets (e.g. SearchExample, SearchTests, SearchUITests) as sources, and its dependencies as binaries (if they exist in the cache). This means Xcode doesn't have to index anything related to App, Settings, and Home, and clean builds of the framework will only have to compile Search. For the user, that also means that they can safely clean their environment (i.e. deleting DerivedData) without feeling concerned about leading to a slow build.

As part of the tree-shaking process, we also delete from the workspace the projects that have no targets after deleting the unnecessary targets, and update the schemes to remove the references to no-longer-existing targets.

What if I wanted to modify something in Core? We thought about that too, tuist focus supports a list of targets you'd like to focus on. You can run the following command, and you'll get the sources of Core too:

tuist focus Search Core Neat! Isn't it? I think tree-shaking is a powerful idea that will boost developers' productivity working with large Xcode projects. I can't stress enough how much value this brings to Tuist's project generation functionality compared to other solutions out there whose main focus is having a new language for .pbxproj files that is not prone to Git conflicts. Tuist goes beyond that and puts itself in the shoes of teams that need a tool to optimize these optimizations to make their developers productive and focus on building features.

Large companies usually resort to build systems like Buck or Bazel to introduce remote caching into their projects. Those are great build-systems. Apple is bringing talent that has previously worked with them to improve the Xcode and Swift Package Manager's build-system. However, the build system is not accessible for small and medium-sized companies because they can't afford to have a tooling or infrastructure team to migrate from Xcode's build system. Moreover, using another build system has proven to have significant costs for the infra team and inconveniences for the users. Since Xcode doesn't support replacing its build system, companies have to resort to project-generation in combination with some hacks to get Xcode to compile using Bazel or Buck. Moreover, with every new Xcode update, they have to do some work to ensure their setup doesn't break and that developers can always be in the latest Xcode version. Not ideal, is it?

With Tuist, we have taken a simpler approach to caching that is inspired by solutions that we have already seen in the community. Here's how our implementation relates to tools that you might already be familiar with:

• Carthage: Carthage takes a different approach to dependencies. Rather than integrating the source code through a project and a workspace, it uses dynamic frameworks that can be easily dragged and dropped into a target and Xcode will automatically set the linking build phases. The clear advantage here over CocoaPods is that your clean builds don't compile the source code of those dependencies. However, it requires developers to understand their project's dependency graph, to ensure that the frameworks are copied into the right products. A badly configured project might lead to apps crashing at launch time, or Apple rejecting your bundles because you have copied a framework into another framework. From Carthage, Tuist gets the idea of turning your project targets into binaries. - Rome: Takes Carthage frameworks and store them in a remote storage. Thanks to this, Carthage frameworks are only built once and shared across all the developers in the team. Nothing changes regarding how those frameworks are integrated into the project. From Rome, Tuist gets the idea of reusing binaries by storing them on a remote storage. - Swift Package Manager: SPM's approach to dependencies is similar to CocoaPods. The main difference is that since it's developed and maintained by Apple, the integration in Xcode projects is more seamlessly. Xcode has built-in workflows for resolving Swift Packages at launch time, and the build system knows how to build and link those dependencies into your app. From the Swift Package Manager Tuist gets the idea of defining your projects using manifest files that are written in Swift.

So how does Tuist combine all the above elements to provide caching?

It generates Xcode projects (like CocoaPods), where the targets that you don't plan to work on are replaced by binaries (like Carthage), that are stored in a remote storage *(like Rome) *that gets populated from CI. All of that happens at project generation time when developers run the following command:

tuist focus MyFramework

It reads as: I'd like to work on MyFramework, please, replace direct and transitive dependencies with binaries, and tree-shake my project to remove elements that are not necessary to work on that target (e.g. other targets, their schemes).

Because what you get in the end is a standard Xcode project, you don't have to worry about future Xcode versions breaking your setup, or using hacks on the Xcode side to make the developers' experience seamlessly.

The image below represents the layers of indirection that are introduced when using alternative build systems. Note that build files have to be translated into another representation that is then passed to a project generator to get an Xcode project. Moreover, the final Xcode projects need to need to trick Xcode into using Bazel or Buck as a build system.

The diagram represents the common setup when using alternative build systems.

In the case of Tuist, there are no layers of indirection. It takes your project definition and generates an Xcode  project ready to be used with Xcode's build system. Because of its simplicity, the setup is easier to reason about, optimize, and debug. Moreover, it makes caching accessible to more users:

The diagram represents how the caching works in Tuist.

Some final words

We'll never be able to build a solution like Bazel and Buck because we are not experts in build systems, nor we think it makes sense to take people away from Xcode's build system. We believe though, that some of the ideas from Bazel and Buck can inspire future improvements in Xcode.

Apple seems to be betting on evolving its build system to be something closer to what Google offers with Bazel. However, it'll be challenging to enable it in existing projects that might have deviated a lot from a standard Xcode project. One of my guesses on how Apple is going to proceed is that they'll first evolve the monolith .pbxproj format for projects into a new format that abstracts some of the intricacies that we have been traditionally exposed to *(e.g. linking build phases, build settings) *and is less prone to git conflicts. With a more limited format, it'll be easier for them to reliably enable build caching because they'll have a well-defined set of project flavors that they'd need to optimize for.

I'm very excited to bring this feature to Tuist and democratize caching for medium and small companies. There's a lot we need to improve, and project scenarios to handle gracefully, but it's looking promising, and can't wait to see more projects using it and making their developers productive through Tuist.

When I embarked on that journey, it was clear that the community would play an important role. That's one of the things that makes Rails so unique too. It's made by people that have a lasting commitment to the project. This is rarely seen in the Swift land, where it's more common to see people come and go often. Many clickbait-type projects reach a spike of hype and stars on GitHub, and then they are abandoned or barely maintained. Tuist would be different. It'd have a mission, it'd place UX in the first place, and people would be encouraged to show a lasting commitment to the project. It'd help developers with the challenges they face when scaling up projects. Users would be invited to share their challenges to help shape the direction of Tuist.

In this blog post, I'll share what had worked well in building the community and the things that still have room for improvement.

What has worked

Documentation for contributors

Joining a community as a contributor might feel intimidating. *Where do I start? *Projects usually place a CONTRIBUTING.md file in the repository with some basic guidelines, but that's not enough - people need a walkthrough that explains how the project is architected and how they can clone it and be able to run it locally. We did that on Tuist's documentation. We realized new contributors appreciate that a lot because they have an exact starting point.

When we see new contributors joining the community, we take the opportunity to engage with them and get some feedback from them to improve the documentation. We don't treat it as a static piece of the project but rather as a dynamic one that needs to evolve alongside the project and the growth of the community.

We'd like to invest more in it and add a tutorial that guides the user through all the features they have access to with Tuist.

Pairing with newcomers

I learned that introducing people into the project by pairing with them is the most effective way to bring a diversity of ideas to the project and empower them to contribute further to the project. It's hard to explain how energizing it is seeing people contributing for the first time to a project and shipping their first feature after one or a few pairing sessions.

Build a modularized architecture

If you build the project as a monolith, familiarising yourself with the project means familiarizing yourself with the entire monolith. However, if you split that up into smaller feature domains, it's easy for new contributors to familiarise themselves with a particular area of the project and contribute to it. In the case of Tuist, we invested a lot in that from the very beginning, and it's paying off. Most of our features are modeled following a functional paradigm. Projects are loaded and then passed through a series of mappers representing different features to eventually reach the components that turn them into the Xcode project. Thanks to that, we've been able to introduce mappers that bring support for caching, generate type-safe APIs for accessing resources, or turn your project into a visual graph.

In the case of Tuist, we followed the uFeatures architecture that is detailed here, and it has worked very well.

Monorepo

One of the areas of projects that is often disregarded is documentation. Getting the documentation out of sync with the project can have a very negative impact on the experience users have with the project. To prevent that from happening in Tuist, documentation (developed as part of a Gatsby website) lives alongside the source code of Tuist in the same repository. Developers are required to update it as part of their work on improvements and new features. Moreover, their changes are automatically built by Netlify, which offers a preview automatically.

If we were not using a monorepo, building a new feature would consist of more than one PR with references between them. That leads to *"I'll open a follow-up PR with the documentation update" *which, in the end, it doesn't happen. Thanks to GitHub Actions API, it's straightforward to define which workflows should be triggered based on the file changes.

Every improvement new feature on Tuist must have code changes, unit tests, acceptance tests (if needed), CHANGELOG update, and documentation. If any of those elements is missing, the PR is not merged until it has it.

Having a Slack group

Even though I'm trying to avoid synchronous communication lately because it makes people believe that the answers should be synchronous too, I have to say Slack played an important role in the growth of Tuist's community. Once in a while, people are joining and engaging with other users and contributors. I always take the opportunity to engage with them and ask them what brought them to Tuist. It's fantastic to hear first-hand what features from Tuist motivated them to decide to use it. Interestingly, many users like the idea that they can use Tuist to define workspaces and have excellent documentation that they can follow through.

Engage through Twitter

Since the inception of the project, we've had a Twitter account that we use to share updates with users and people interested in the project. We share all kinds of Tuist, from new releases to tips. Having the account also allows contributors to tag Tuist whenever they proudly share their contributions to the project. Most of the community of developers that work with Xcode are on Twitter, so it's the place to be if we want them to know about Tuist and give it a try.

Believe in our ideas

The Xcode community is settled on solidified ideas that have either been established by Apple or the community. This is great because you don't have the fatigue you'd have in Javascript trying to find the solution among many that work best for you, but has the downside that constrains new ideas. We've experienced that from the very beginning when people started comparing Tuist with XcodeGen and Fastlane. Yes, we leverage project generation and provide commands that developers would usually define in Fastfile. Still, we take a different approach with different goals. It's easy to get distracted by the community opinions, but it hasn't been the case here.\ Tuist's community is not afraid of throwing new ideas and exploring them further. Thanks to that, we have features like project description helpers, module caching, and auto-generation of documentation that wouldn't otherwise be in Tuist.

Trust people

Shopify has taught me this. One of the best values that you can have in your project/company is trust. It's a value ingrained in Shopify's culture, and wanted it to be part of Tuist's too. Since the beginning, we trusted people to do all sorts of things in the project: propose and own the implementation of new features, publish new releases, provide support yo the community... When you do something like that, they feel part of the project and are empowered to contribute further.

This has the downside of trusting people that might end up proving that they are not trustworthy. However, we are lucky that hasn't been the case in Tuist yet. If we happen to have this scenario, we'll handle it.

Recognize people's work

We take the time to recognize the work that people do, both privately on Slack and through mentions on Twitter. I've noticed some communities have automated through bots on Slack, but honestly, it saddens me that we have reached a point where we need to say thanks through a bot. In some cases, I've gone as far as to send the person a little gift (e.g., stickers with a hand-written card and a book about open source).

What hasn't work so well

Delegating

Although there are a few maintainers and contributors, there's still a lot of that falls over me, and that sometimes results in a bottleneck when there's a lot of work in the backlog, and I don't have enough attention after work that I can devote to it.

I'm currently seeking domain owners, but it's hard because Tuist is a side project. They sporadically contribute to the project but can't commit to a role in the project. This is the classic issue with open source projects that we don't know how to approach either. And it concerns me because it can lead some of us to burnout and give up.

I recently started building a companion web app that integrates with GitHub, Discourse, and Slack and provides utilities to make this easier. For instance, one of the ideas that I have in mind is having tweet requests (TR), a way for contributors to propose tweets shared from Tuist's main account. I called this app Backbone. It's in a very early phase, but you can check out the project on this repository.

Vision

I haven't done a good job sharing what's the vision of the project. I've been hinting it through Slack messages and posts in the community forum. Still, it's hard for someone new to the community to imagine the future of Tuist and how the current projects align with it. I guess it's normal when the project is young. There are many things yet to be defined, but as things start to mature, having a vision makes it easier for teams to align with the upcoming features.

Final thoughts

Tuist is my baby 👶 - I like working on it a lot. We've built a community of users, contributors, and maintainers that make the project so unique. We have gone from merely being a project generator to a platform that provides streamlined workflows to focus on the most critical tasks. Since I started building Tuist, I was disappointed that only the big companies in the industry could access those features that most projects need to scale up (e.g., easy modularization, caching). I tasked ourselves with democratizing that and making it accessible to anyone.

It's been three years, and the project keeps moving forward, fueled with great minds and creative people. I don't know what'll come next, but I'll indeed say that it'll help projects of any size with the challenges they face or are about to face.

For the backend, I chose Rails. It’s easily deployable to Heroku by simply doing a git push. Moreover, I can use a programming language that I love a lot, Ruby, and save a lot of time by adding dependencies that bring functionality that otherwise I’d have to implement myself - we use Devise for authentication, Rolify for defining roles, and CanCanCan to codify permissions when accessing models.

The API is GraphQL. We use the Ruby GraphQL gem that makes it so easy to define a schema and translate it to internal business logic. Unlike standard Ruby applications that tend to put the logic in models or controllers, we are using the service pattern heavily. Every unit of business logic is defined in a service that takes the necessary input, performs the operation, and either returns a value or raises an error. That makes those units easy to reuse from other components like controllers. As a result, our models are very lean; they only contain validations and a few callbacks to automatically populate some fields.

I like this setup because I’m learning a lot about GraphQL. I have to say I can’t imagine myself doing REST APIs anymore. There’s one thing that I’d like to read more about, and that’s how to solve the N+1 issue when running queries because, with the GraphQL approach, it’s more likely to happen. However, it’s not an issue right now if we consider that the amount of data we are sending is minimal and the queries relatively easy.

We only use Rails server-side rendering solution, ERB, for the authentication workflow because it’s provided by Devise out of the box. For everything else, we moved the rendering to the client-side by using React for describing the views and Apollo to interact with the GraphQL API and cache the responses. It provides a lovely hooks-based interface that makes interacting with the API a pleasure. Moreover, with use a code generation tool that turns our GraphQL queries and mutations into Typescript code, so we don’t have to write network code at all. Thanks to that, our focus on the frontend is on what data to fetch and how to represent it.

Last but not least, we are styling the UI using TailwindCSS. Ever since I came across it for the first time, I’ve been using it in every project that involves styling HTML. Styles are applied through classes with semantic meaning, limiting each attribute to a limited set to value. Thanks to it, it’s easier to achieve visual consistency that otherwise wouldn’t be possible if we had to pick values for every new HTML element. And that goes without mentioning the relief of not having to think about naming classes. I got a license for TailwindUI, which provides a set of beautiful components built upon TailwindCSS.

I'm enjoying and learning a lot during the process of building this web app, and I'm taking the opportunity to learn about designing for the web: patterns, semantic hierarchies, how to create components that look clean and modern.

Do you have experience building web apps? If you don't mind sharing your stack, I'd love to hear about it on Twitter.

schema: schema.graphql
generates:
 app/javascript/graphql/types.ts:
 documents: 'app/javascript/**/*.graphql'
 plugins:
 - typescript
 - typescript-operations
 - typescript-react-apollo
 config:
 reactApolloVersion: 3

And then running yarn graphql-codegen. The tools outputs a .ts that contains all the necessary code for interacting with the API. For example, the snippet below shows how to fetch the current user by using the generated code:

import { useMeQuery } from 'graphql/types';

const MyComponent = () => {
	const { data, loading, error } = useMeQuery();
	return

{data}

;
};

In the past are those days with Objective-C and Swift when I had to write the client-side models manually using the API documentation. Who wants to do that again after seeing such a powerful workflow? By the way, Shopify has a similar tool that generates models in Swift & Kotlin - it's called Syrup and it's open source.

Ruby is lean. There’s an interpreter in your system that you pass your code to. Bundler ensures that the directories of your dependencies are loadable and that’s it. No Babel, Webpack, Typescript.... It simply works. That’s what you want at the end of the day, not spending time figuring out issues or how to configure underlying tools.

The only reason why I’d use Javascript is to be able to describe a website using React’s approach to represent states and encapsulate dynamic behaviors through hooks. That’s why I use Gatsby for creating statically generated sites over alternatives like Jekyll, or the so-talked-about in the Swift community, Publish, that would lock myself to Xcode.

Going back to Ruby and Rails, what do I like about it?:

• I only need the interpreter and the dependency manager to run a project. - I can write tests in plain Ruby classes and using the language’s standard library. - Bundler’s approach to structure dependencies is more sensible and prevents the “delete node_modules” issues. - There’s less library fatigue. There are fewer options that are better tested, and that makes deciding for a dependency easier. - Being able to open a Rails console in a remote server with ActiveRecord models loaded is damn amazing. - Thanks to its dynamism, you can build plugin systems that otherwise wouldn’t be possible with statically compiled languages like Swift. - Companies like Shopify are using it at scale, and IT WORKS. Some internal tooling to support the scale leverages the dynamism of the language. - The language and its ecosystem feels more harmonious. Working with Javascript is sometimes stressful because sometimes you need to go deep into an endless rabbit hole of patches over patches.

This is my preferred stack when building software these days:

• Static websites: GatsbyJS with Typescript - CLI tools: Swift if it's for macOS environments, and Ruby otherwise. - Apps for Apple platforms: Swift (I'm planning to learn SwiftUI at some point). - Web APIs: Ruby on Rails.

And you? What language/technology do you like the most and why? Let me know on Twitter Twitter.

Typically open source Swift CLIs are organized in two targets, one that represents the executable (i.e. main.swift), and another one, typically named with Kit, that contains all the business logic of the tool. The main motivation for doing is being able to implement tests for the business logic. However, since everything lives within the same boundaries, there’s a huge risk of the business logic growing into large group of components strongly coupled, and an architecture that is hard to reason about, maintain, and evolve. It’s a good starting point, but not a good idea long-term because it’ll compromise developers’ efficiency contributing to the codebase, and complicate onboarding new contributors to the project.

As I mentioned earlier, Tuist follows the uFeatures architecture. There are Tuist-agnostic targets like TuistSupport (inspired by Rails’ ActiveSupport) and TuistTesting that contain utilities that transversal to all features and core utilities: abstractions built upon foundational APIs and extensions. There’s a TuistCore target that contain models and business logic that is core to Tuist; for example the dependency graph and the models that represent the projects. This target also acts as a dependency inversion layer so that feature targets don’t have dependencies among them. Thanks to this, we can build a feature without having to build the others. This makes iterations cycles faster when working on individual features. Then features are organized horizontally. Most of them represent the different command namespaces that are exposes by the CLI. In some cases like automation commands, they are grouped under TuistAutomation. Cloud-related utilities live in TuistCloud. This is great for new contributors because if they want to fix or improve something in the tuist build command, they only need to onboard on the TuistAutomation target. Isn’t it great?

Last but not least, we have the TuistKit that glues all the features together into a command line interface that is hooked from the entry main.swift file. Commands are classes responsible for parsing the CLI arguments and throwing errors when they are incorrectly used, and delegate the business logic to Service. For example, there’s a GenerateCommand and a GenerateService.

One might think that this is over-engineering a project, but I’d certainly disagree. Defining clear boundaries in a codebase by leveraging Swift’s access levels will lead to a better architecture, which in turn, eases contributions and the addition of new features. Starting the modularization way after creating the project will be a hard challenge to undertake because the code will most likely be strongly coupled. We tried to do that at SoundCloud and, from what I know, there’s still a lot of code that lives in the main app that is hard to extract.

I can’t imagine Tuist being a monolith codebase these days.

One side of me thinks that the solution to this is removing those distractions. For example, applying some ideas from the minimalism movement: be only in the strictly necessary Slack channels, don't spend so much time in social networks, tidy up the desktop and phone setup and remove any apps clutter. That has helped, but it's not enough, I still feel distracted and often stressed.

What else can I do? I think I have to learn to accept that distractions will always be there and that I have to become better at saying yes and no to things. I struggle with saying yes, this is important and therefore requires my attention, and no this is not relevant right now and therefore I should let it go.

I'm also trying to get comfortable with not reading Twitter often. I got used to being a passive consumer of everything that it's going on in the world, and that's not sustainable. My brain is exhausted with keeping up with everything that is happening. Instead, I'm teaching myself to be more offline than online, and more active than passive. For example, I'm trying to read more paper books and newspapers, or write more often in my blog or in random pieces of paper. It's very tough because my brain somehow got used to being distracted all the time, but when I get it into the mood of being offline I quite like it.

It'll be a long and tough re-education process but this is what I'm up to these days: trying to be less stressed to have more focus and be able to do deep work again.

I’ve had two of them and I love it. Getting new people to contribute to Tuist brings new and more diverse ideas to the table. Moreover, they bring more energy which is the fuel for the project to move forward.

To make the first-time experience great, I pick a feature that I know is implementable end-to-end in one session. For example, in the session we worked on a tuist lint code command to lint projects’ code using SwiftLint, and in the second one we implemented a tuis doc to auto-generate documentation from targets.

Doing these sessions made me realize how great idea it was following the uFeatures architecture in Tuist. It’s very easy to add a new feature alongside the others, and build its business logic by composing existing pieces of business logic. Moreover, it’s easy to compare the existing architecture, with what they know from building iOS apps. For example, I tell them that the CLI is the App Delegate, that commands are like views, and since views should not have logic, we extract the business logic into services.

If you maintain an open-source project I’d strongly recommend doing something like this.

If you are reading this and would like to pair on the project too you can let me know and I’ll be happy to schedule a session and do a bit of hacking together.

Very often Tuist's users ask for features that they have seen in Xcode and that they'd like to see in Tuist too: is there support for script build phases? or can I run a command right after generating the project? It's temptin to say that we don't support it, but that we can add support for it. However we'd end up with the same concepts and complexities that motivated them to use Tuist.

The approach that I take instead is aking them whys: why do you need a script build phase or why do you need to add this build setting? Thanks to this, we have been able to simplify some of Xcode's complexities like defining dependencies. If we understand what are users' motivations, we can provide them with simpler and more optimized solutions. And this is something that excites me a lot about the way we are building Tuist. It's all about helping teams with the challenges that the face. The how is up to us to figure out.

For example, I know that one of the challenges that teams face is slow builds. Some teams went straight into adopting build systems like Bazel or Buck because they saw that's something that worked for other companies. However, they might have not realized that the fact that it worked for them doesn't mean that it'll work for them too. This often leads to teams going too deep into rabbit holes, or what's worse, introducing layers of complexities that make projects hard to maintain and work with. If you have seen projects using CocoaPods, Carthage, and the Swift Package Manager for managing dependencies, you probably know what I'm talking about.

As one of the maintainers of Tuist, one of the roles that I set for myself is evangelizing this idea on how to build tools. I'd love them to think of Tuist as a product; a product that solves concrete problems that we understand well. If we want to build something that developers love to use, we need to understand why we are building it in the first place.

• We built updates into Tuist because the existing solution for managing the installation of system dependencies (e.g. Homebrew) might yield non-deterministic results that cause frustrations to developers. - We built project generation because Xcode difficults defining a modular project consistently, which is crucial for sharing code and keeping build times low with architectures like uFeatures. - We are adding cache because developers use ⌘+K often and end up wasting a lot of time doing clean builds with Xcode. - We are adding automation because Fastlane's approach in practice result in large and complex Fastfiles that are hard to maintain. - We are synthesizing interfaces for resources to prevent runtime errors when accessing non-existing resources.

If you are also working on tools for developers, I'd recommend adopting this mindset. Listen to your users, understand their needs, and build the best solution for them. Resist the temptation of building just what they ask for.

I feel very uncomfortable with this attitude and the more time I spend in Germany, the more I realize that this is a cultural thing from Spain. It’s not the first time I’ve noticed this pattern: people playing the game of being your friend, but in reality treating you as a tool. It’s ok if you play the same game, but not so cool if you are out of the game.

After that chat, I couldn’t avoid reflecting on myself, and whether I behave the same way. I think in my case I’m more driven by the beauty of building connections with people. I think that’s the reason I’m so engaged devoting my free time to Tuist. Some people would perceive it as a waste of time, but I see it as a fulfilling thing because I get to know and talk with people that otherwise I wouldn’t have been able to. In fact, the other day I met Marek, also core contributor of Tuist, and had breakfast together in Berlin. For me, that has more value than money, success, likes, follows, stars, and any other kind of interest that people might have these days.

This is something that I learned from my parents and that I’ll never forget. Happiness is not about success and money, is about being healthy, and being friend of your friends.

What I’m learning to do though is how to distance myself from those people that either treat me or other people as means. I’ve been there. I’ve suffered a lot from it, and it’s consumed a lot of my energy. It’s easy to fall into the trap of only seeking success and feed your narcissistic desires.

And my random thought about people ends here while I’m somewhere in the countryside of a small town in the south of Spain called Murcia.

I used to be excited by playing with technology itself. SwiftUI? Oh! I want to test that out and see how it feels. A new reactive framework? I want to add it to my app and see how it compares to RxSwift. However, that's no longer the case. I see technology as a mean provide something to the users and tackle problems/needs they might have. And the side effect of this shift is that I don't worry anymore about having to keep up with the latest with the latest. Instead, my focus is on users, what do they need?

I enjoy seeing how developers work at Shopify and wondering what kind of tools we could build to help them. I also enjoy seeing developers joining Tuist's Slack group and bring new interesting challenges I didn't think about before.

These are questions that I often ask myself:

• How can I make convenient inconvenient steps of developing apps with Xcode? - How should Tuist's website design be to convey the ideas behind the project? - What can I do to build a healthy and engaging community of users? - What can I do to reach those developers that still struggle to scale up their Xcode projects? - How can I solve challenging problems like reliable team signing of apps or faster builds? - How can I make sure we don't disregard little details that make the user experience using Tuist great?

In a recent interview at Shopify, someone asked me what I like from my job. I did not expect that question, but I could answer it without thinking twice: I like to make complex things simple.

That's what I've enjoyed doing at Shopify and with Tuist, and that I'll continue exploring further in the next few years.

By the way, I just got a book on Web Typography because I want to understand how different typographies influence the way a design is perceived.

• A -> B -> C (3.2.1) - A -> C (1.2.3)

Javascript dependency managers will structure the dependencies following the structure below:

node_modules/
 a/
 b/
 node_modules/
 c/ #3.2.1
 c/ # 1.2.3

With this scenario package managers like Bundler or Swift Package Manager would error, but NPM and Yarn do not. Javascript bundlers like Webpack and Metro might be able to resolve those and generate a valid Javascript code that runs successfully (perhaps with a larger size than expected).

The problem comes when the C dependency is a React Native dependency that includes native code. The React Native CLI uses CocoaPods and Gradle to link the native code that is distributed as part of the NPM package. In the above scenario, we can't link both versions of the C dependency so the CLI decides to link only the direct dependencies.

That means that adding B as a dependency of my React Native app also means that I have to add C. Otherwise, the app will crash when it tries to access the non-existing native code from C.

I find it very weird that the app needs to know about transitive dependencies as well, but I can't think of a better way for the CLI to solve it. I guess one thing that it could do is to extend its logic to lookup transitive dependencies as well, detect conflicts, and fail if it finds any.

This is just me and another misterious quirk of React Native development.

Yesterday, while thinking about all of this, I came up with the idea of grouping phases along the process of developing apps in 4 categories:

• Start: Starting a project happens when a team has an idea and they want to make it tangigle. Traditionally they used the React Native CLI, but unfortunately, that's not enough. Creating a new project also involves setting up continuous integration and signing. What we are doing here, and we'll share more about it on the company's engineering blog, is moving the creating of projects to a web-app. Developers give their app a name, select what functionality they'd like to opt-into, and the service takes care of the rest. Cool, isn't it? - Develop: Once the project is created, developers need to interact with it from the terminal and their editor; they need to build, test, run, and lint their code. This is something that the React Native CLI provides, but that we are wrapping inside an internal CLI tool that minimizes the amount of configuration required by providing a more opinionated development experience. The plan is also to integrate the tool with our internal infrastructure to provide useful workflows. - Share: Once the app is in a usable state, developers usually want to share it with other people. In concrete terms, it would be something like uploading the app to Google Play Store and Testflight. However, at Shopify we have Shipit Mobile and a tophat which makes the sharing process very convenient without having to depend on a third-party provider. - Release: Last but not least, once teams feel the app is ready to be rolled out to the final users, they need to sing and upload it to Google Play Store and Apple Store Connect. This is something for which they can use our internal Shipit Mobile platform.

It's exciting being able to translate the above user intents into workflows that developers can follow. In the past few years we have been building individual tools that we are slowly bringing together to provide a more cohesive experience that developers enjoy.

In the past few months, I've worked on turning things around in the way I consume tech. Rather than letting my excitement decide where to spend my time, I consume the content as I need it for my day-to-day tasks. For example, reading about people talking about SwiftUI, especially now around WWDC, made me feel that I should read and talk about it too. However, a more thorough thinking stopped me from doing it. I used that time to learn things that I might need for improving Tuist, which is what I enjoy working on these days.

It's a uncomfortable stance at first, but I believe in its long-term benefits in my mental health. Being ok with not knowing about what was presented during WWDC allows me to use my time more wisely and have a mental space that otherwise I wouldn't have.

• Sorbet has a great adoption process. It can load your codebase, analyze it, and add sigil annotations to the files. - After adopting it, I was able to run srb tc successfully. Sorbet flags some of the files as ignored, and lets you gradually change the granularity of the type checks. That means you can adopt types at your own pace. - The typecheck (srb tc) command runs incredibly fast and that makes it a good candidate to be part of your local development workflows. - I don't like the syntax for adding type annotations, but I don't dislike it either. It feels a bit detached from the implementation code. For example, for annotating a method, I'd expect something along the lines of:

def my_method(x: String): String
end

• It can use runtime reflection to generate Ruby Interface files for third-party gems.

Overall, the impression has been quite possitive. I don't many Ruby projects, but if I had to, I'd definitively set them up with Sorbet. If you are a Ruby developer and you haven't checked it out yet, I'd recommend you to give it a try in one of your projects.

I'm not sure. Most of the times I lean towards the former because I'm devoting my free time to the project and I want to work on exciting things. However, I do it thinking that developers are getting a bad impression of Tuist due to tiny flaws that shouldn't be there. I like building great user experiences, and flaws defeat any great worked we might have put into building Tuist.

I don't have a perfect framework on how to do this yet, so I'll continue exploring and finding a more sustainable relationship with open-source.

I had to add one of those to the settings view of Angle, and then I realized that it's not a pre-defined component that you can drag & drop and use. Does that mean we have to implement a custom view for it? You are right! And that's what I ended up doing.

It took me several iterations until I got it right. Since I'm sure I'm not the first one coming across this need, I'll leave the code snippet here:

import Foundation
import AppKit

class AddRemoveFooter: NSBox {

 // MARK: - Attributes

 fileprivate var addButton: NSButton!
 fileprivate var removeButton: NSButton!

 // MARK: - Init

 override init(frame frameRect: NSRect) {
 super.init(frame: frameRect)
 setup()
 }

 required init?(coder: NSCoder) {
 super.init(coder: coder)
 setup()
 }

 // MARK: - Internal

 func setAddAction(_ action: Selector?, target: AnyObject?) {
 addButton.action = action
 addButton.target = target
 }

 func setRemoveAction(_ action: Selector?, target: AnyObject?) {
 removeButton.action = action
 removeButton.target = target
 }

 // MARK: - Fileprivate

 fileprivate func setup() {
 setupStyle()
 setupButtons()
 }

 fileprivate func setupButtons() {
 contentView = NSView()
 contentView!.translatesAutoresizingMaskIntoConstraints = false
 NSLayoutConstraint.activate([
 contentView!.leadingAnchor.constraint(equalTo: self.leadingAnchor),
 contentView!.topAnchor.constraint(equalTo: self.topAnchor),
 contentView!.bottomAnchor.constraint(equalTo: self.bottomAnchor),
 contentView!.trailingAnchor.constraint(equalTo: self.trailingAnchor),
 ])

 addButton = NSButton(title: "+", target: nil, action: nil)
 addButton.bezelStyle = .shadowlessSquare
 addButton.translatesAutoresizingMaskIntoConstraints = false

 removeButton = NSButton(title: "﹣", target: nil, action: nil)
 removeButton.bezelStyle = .shadowlessSquare
 removeButton.translatesAutoresizingMaskIntoConstraints = false

 contentView!.addSubview(addButton)
 contentView!.addSubview(removeButton)

 NSLayoutConstraint.activate([
 addButton.leadingAnchor.constraint(equalTo: contentView!.leadingAnchor, constant: 0),
 addButton.topAnchor.constraint(equalTo: contentView!.topAnchor, constant: 0),
 addButton.bottomAnchor.constraint(equalTo: contentView!.bottomAnchor, constant: 0),
 addButton.widthAnchor.constraint(equalToConstant: 30)
 ])

 NSLayoutConstraint.activate([
 removeButton.leadingAnchor.constraint(equalTo: addButton.trailingAnchor, constant: -1),
 removeButton.topAnchor.constraint(equalTo: contentView!.topAnchor, constant: 0),
 removeButton.bottomAnchor.constraint(equalTo: contentView!.bottomAnchor, constant: 0),
 removeButton.widthAnchor.constraint(equalToConstant: 30)
 ])
 }

 fileprivate func setupStyle() {
 self.boxType = .custom
 self.alphaValue = 1
 self.borderColor = NSColor.gridColor
 self.borderType = .lineBorder
 self.borderWidth = 1
 }

}

Another negative thought that I've had lately is: what if I end up wasting my time replacing feature after feature what Xcode provides? That has never been the goal for Tuist, but the more I work on it, the more I realize people want to see in their projects what they see in Xcode. I don't think Tuist should do that because that'll bring the same accidental complexity Xcode ended up with. But that means a lot of energy conveying Tuist's ideas and convincing people to go down a different path. I don't like pushing ideas onto people, or at least feeling that I'm doing it. I tend to have a lot of ideas, which I codify into tools that I build, or guidelines that I publish, like the microfeatures one. If people like them fine ― if they don't like them, that's fine too. However, once they are onboard with some original ideas, doing shifts or doing gentle pushbacks is an uncomfortable thing for me to do. I guess it's something I'll have to learn to do, considering I've been envisioning a handful of Tuist's core ideas.

What I'm doing a lot these days, which helps a lot, is looking at the project from an angle of positivisim:

• The opportunity the project gave me to connect with very talented people with great values. - The opportunity to re-imagine existing workflows that people have accepted for years and challenge myself with simplifying them. - Building simple things in a world of complexity gives me a huge sense of accomplishment. - By building this project I'm impacting people's lives through the companies that have already adopted the project. - Having the opportunity to work on building a community and a product that people can talk about and enage with.

And well, those are my thoughts about my relationship with Tuist in the morning of May 6th 2020. I love this project and I'll continue building great stuff into it.

It made me think that Apple is imposing, perhaps without being aware, a barrier for newcomers to iOS development. As a newcomer, you want to code a few views, and get the app on Testflight so that you and others can try it out. This is what they need to do beforehand:

• Understand how signing works and what are certificates and provisioning profiles. - Know how to set up the app’s build settings to sign the app successfully. - Figure out the difference between build, archive, and export an app.

Many iOS developers nowadays don’t have a good grasp of how those things work because they are typically hidden behind an abstraction automation layer. Or in other words, some Fastlane files.

In the aim of streamlining this process making it possible to sign and upload the app without the cognitive overhead that the current process requires, I’ll try to leverage Tuist’s foundation to provide a very easy workflow:

• tuist init - tuist connect setup - tuist release

That’s how I imagine the process to be for the users, so I’ll start designing everything from there. If you are into tools and frameworks development, I’d recommend start designing them from the experience that you’d like to provide to your developers. Otherwise, you might end up with something that is not user-friendly.

I’ll keep you posted on the progress that I’m making towards this.

Unfortunately, our knowledge is not linear, hence using those apps to dump our brain into the cloud requires a pre-conversion, which takes you away from your root thought and perhaps the opportunity to connect it with other thoughts and ideas.

Some people might not find this annoying, but I certainly do. The way I think is pretty much like Internet and many things in this planet work: as a network of interconnected thoughts where the close ones have something in common.

What I would expect from an app where I can dump my thoughts an ideas is therefore a simple interface to build a graph where the nodes are units of knowledge or ideas.

There are apps like Notion that make that possible with the use of hyperlinks but the interface is fairly overwhelming. Moreover, the experience in mobile is terrible as a consequence of using a webviews.

There are also apps around the concept of mind-mapping. They provide a visual interface to modify the graph. Although that might be handy for short-term graphs, I don’t think it’s the most suitable interface for quick brain-dumps. I think the graph must exist, but it should be an implementation detail.

How do I imagine the app then? I imagine a native mobile app, meaning by native that it uses native primitives and patterns. Most of the time I’ll be in brain-dump mode, so as soon as I open it, I get a form. Moreover, I’d get a default list of labels and other ideas to connect them with.

The other mode the app would have is journey. I could get lost in the graph and revisit those notes that I left for my future self. Pretty much like Pinterest but most knowledge and ideas oriented. Isn’t it beautiful?

I started building it with my wife and sister-in-law. My wife will focus on envisioning and designing the product. My sister-in-law and I will do the coding part. All the projects will be open source in the GitHub organization logosapp.

What's the consequence of that? Crashes landing on master, developers frustrated because the app don't launch after rebasing changes from master, or even worse, users getting an app that doesn't launch.

At Shopify, I tasked myself to put a system in place to catch those errors on CI. In this short blog post, I'll share what we ended up doing.

Since we use the Firebase test lab, the contract with whatever we build needs to build a test. After a bit of reading because I'm not very familiar with Android as a platform, and in particular how testing works in it, I managed to implement the following test:

@RunWith(AndroidJUnit4::class)
class LaunchTest {
 @get:Rule var rule = ActivityTestRule(MainActivity::class.java, true, true)
 @Test
 fun default() {
 Thread.sleep(20000)
 }
}

As you can see, it does nothing but just launching the main app activity and wait for 20 seconds. I first tried to subscribe to the React Native loading events but I couldn't find a public interface for that. 20 seconds should be enough time for an app to boot on an Android emulator. If the test fails because it takes more than 20 seconds to boot, there's probably something else to be looked at because that's a terrible experience for the user.

The test passed for an app that launched successfully, but it also passed for an app that was supposed to crash. Why was that?

Disabling the developer support mode

As you might know, React Native has a developer support mode that is enabled when the app is compiled for debug. That mode prevents the app from crashing and shows a red error screen instead. Because of that, the activity was not crashing causing the test to throw a false positive. The 2 first options that I ended up discarding where the following:

• Use the release variant: Although that could have probably worked, it's not common to run tests using a release configuration. Moreover, we'd have had to sign the app before sending it to the test lab, which is something that we didn't want to do. - Add a debugTesting variant: That extended from debug, and set a build config variable that we can read from the Application to disable the developer support mode. However, that resulted in compilation issues that bubbled up from React Native dependencies.

What I did in the end was defining a custom test runner that leverages shared preferences to pass some variables to the application when it's being run from the test:

class LaunchTestRunner : AndroidJUnitRunner() {
 override fun callApplicationOnCreate(app: Application?) {
 val preferences = InstrumentationRegistry.getInstrumentation().targetContext.getSharedPreferences("TESTING", 0)
 val editor = preferences.edit()
 editor.putBoolean("IS_LAUNCH_TEST", true)
 editor.commit()
 super.callApplicationOnCreate(app)
 }
}

Thanks to that, we could adjust the logic in the application class, to read the value and adjust the developer mode accordingly:

override fun getUseDeveloperSupport() = BuildConfig.DEBUG && !applicationContext.getSharedPreferences("TESTING", 0).getBoolean("IS_LAUNCH_TEST", false)

Moreover, we had to change the testing configuration to use our custom test runner:

testInstrumentationRunner 'com.shopify.app.LaunchTestRunner'

After that, the test was passing when the app launched successfully, and failed when the application crashed.

By default, when building a React Native app for debug it doesn't bundle the Javascript and the resources because it reads them from a local HTTP server that runs alongside the application. Since that's not what we want, before building the app, we run the following command: react-native bundle --platform android --dev false --entry-file index.js --bundle-output app/android/app/src/main/assets/index.android.bundle --assets-dest app/android/app/src/main/res --config metro.config.js

In a follow-up blog post I'll talk about how we achieve a similar thing on iOS. In that case, we didn't have to implement an XCTest test; instead, we added a Rake task that built the app and attempted to launch it on an iOS simulator using the simctl tool.

I'm not sure why, but that made me think about Apple's obsession for control and limitation of the environment and its tools. Unlike more open ecosystems and communities like Javascript or Ruby, where developers don't feel constrained to innovate and buid solutions for the problems and challenges that they encounter, in Apple's, many people dream with that innovation only coming from Apple.

People might critize communities like Javascript or Ruby's and find them overwhelming, but they are so open that the innovation comes in any shape: tooling, libraries, paradigms... React is a good example. With all the support from the community we have seen its ecosystem maturing very quickly. Building stating sites with Gatsby, or building web apps that follow the JAMstack philosophy with RedwoodJS is mind-blowing. On the Apple land, we just saw SwiftUI last year. I haven't tried myself, but it seems that it's still not mature enough, and since the framework is close-sourced, radars is the only contribution that you can do to it. That, and doing a bit of evangelization in the shape of talks, posts, and books.

Until Apple relaxes its closeness and obsession for control, I doubt we'll see Vapor taking off, more companies adopting Bazel because it integrates seamlessly into Xcode, or Swift being used more broadly, not just for writing apps or tools for those apps.

I'll continue using Swift and building things for the Apple ecosystem because I have a emotional connection to it, but I sometimes wish building Tuist didn't feel like fighting the ecosystem, and rather like building an extension for it.

To fix that, I've done the following adjustments to the way I approach spending time with computers:

• I only check social networks when I'm mentally exhausted (i.e. at the end of the day). - If I think there's something worth sharing, I use Buffer instead of openning Twitter and be trapped by the unceasing stream of new things. - I use to asynchronous communications over real-time ones like Slack. I'm moving Tuist's discussions to GitHub issues and a community forum. At work, we are trying to use GitHub issues and documents more. - I reduced the Slack groups I'm part of, especially the community ones. I'm already doing my part of helping the community by building Tuist. - I time-box the time that I dedicate to certain tasks like reading email, answering messages on Slack, or doing open source. - I minimize my go-to programming languages and tools and be ok with not keeping up with updates. I became a goal-oriented engineer rather than technology-enthusiastic. Swift and Ruby are just technologies that enable me to achieve certain goals.

From all of the above, the ones that have helped me the most are being ok with not keeping up with things, and moving away from quick and unceassing communications that happen on platforms like Twitter, or Slack.

I'm way more relieved now, and I feel I can deliver much better things without feeling anxious at all.

This is a constant when working on Tuist. In this case, developers often ask for features that mimic Xcode's complexity, and that's precisely the reason why we are providing Tuist as an abstraction: to conceptually compress Xcode's complexities and initriciacies. My first thought is often: if we add X, Y, and Z, which is what Xcode provides, we'll end up with the same thing, but in a different language. Teams might need that, and that's fine, but unfortunately, that's not what Tuist is amining for. We aim to challenge projects' complexity and nudge them to be simpler. The adoption of Tuist might require simplification on the user side, but believe me, both your team and Xcode will be so thankful for that.

Something that works for me to challenge developers' requests is asking them whys until I reach their core motivation or root problem. They typically come with a solution in mind, without really understanding what they need that for ― they haven't spent time going through those whys themselves.

I'm aware that this mind-set when developing a product like Tuist might suppose not pleasing everyone ― but it's fine because that's not our goal. The goal is to remain small and close to our gist of keeping things simple. That's what makes users of Tuist love it, and most importantly, enjoy scaling up their projects.

If you are a developer working close to product, whether a product is a tool for developers, or a user-facing app, I'd encurage you to work on having this mindset of understanding the motivations behind features, and striving to keep them simple.

The first time that I heard about Nix was on this blog post from Pinterest, but it didn't catch my attention until now. I started reading about it and watching some internal videos that Burke is creating to evangelize the idea. The more I read about it, the more amazed I am with the idea. These are the ideas that struck me:

• Environments are defined in directories with symlinks to other directories that represent nodes of a dependency graph. Each node has a unique hash based on its content, the input, and the output. - Every modification of your environment is tracked and can be rolled-back akin to how Git works. - If one of those nodes needs to be built locally, the output artifacts can be shared remotely and pulled from other environments to speed things up. - The dependency graph extends to components that are very core to the system. That prevents, among others, that macOS upgrades break the user environment. - You can pull and run a package without polluting the environment. - Nix provides its own expressive language that prevents developers from doing operations that might introduce side effects.

I'll keep reading about it. I think Tuist could benefit from some of its ideas. For example, the idea of minimizing the IO and side effects, as well as the way it models the dependency graph.

I hope everyone is safe in these difficult times. Stay at home!

Our industry is filling with people that are constantly trying to catch the latest trend, or create the newest product/project so that people have something to talk about. In most cases, they don't have a genuine interest in the domain, they are just feeding their narcisistic needs. There's a positive thing on that — we are constantly exploring new territories that otherwise would remain unexplored. However, there are important drawbacks:

• Since we don't have interest in the problems' domain, we never engage with our craft because we are constantly thinking about what's next. - It creates anxiety — The anxiety of figuring out how to stay relevant and catching up with everything. - It distances us from the recepients of our craft, who just become a mean to feed our egos.

It's easy to follow that path. I've done that myself, and I don't like it. I prefer to keep my feet on the ground, and nurture the love for my craft. Outside the context of of Shopify, my craft is Tuist.

There are a handful of people in the community that I admire for their lasting and deep love for the craft that they do. Off the top of my head, I really admire's Brent Simmons's ingrained passion for RSS readers and NetNewsWire, and DHH (and Basecamp) and their passion for building Rails and helping teams collaborate. There are probably more, but those are the ones that popped in my mind. They have seen lots of shiny RSS readers being created, and many better-than-Rails frameworks, but there they are. After many years in the industry, they continue doing what they like the most.

As it happened with the definition of dependencies, dealing with certificates and provisioning profiles is something that annoyed me a lot. It takes time to understand all the concepts and get it right right, and it can take even longer to understand issues when they arise. In my experience, there's usually a go-to person in each team to help debug and solve signing issues when they arise. That's pretty bad. Configuring signing should be straightforward and issues should be easier to debug and fix.

Fastlane helped with automating the generation of the certificates and the profiles but doesn't prevent developers from setting the wrong settings to their projects.

How can Tuist do things better? It can make certificates and profiles an implementation detail of signing; like we did with linking build phases being an implementation detail of dependencies. Those are part of the repository and encrypted using a team's key that will need to be present in the local and CI environments.

At project generation time, Tuist will decrypt and validate them, and configure both, the environment and the project, for the signing to work. If something is missing or invalid, we'll fail early to prevent developers from facing signing issues in Xcode.

Moreover, to eliminate the need to configure anything on the user end, we'll establish the following naming convention:

• Certificates: Configuration.p12 (e.g Debug.p12) - Profiles: Target.Configuration.mobileprovision (e.g MyApp.Debug.mobileprovision)

Thanks to that convention, the configuration will be zero, and Tuist will know which certificates and profiles to take from Tuist/Signing, for each of the targets that are part of the dependency graph.

Project generation is a powerful tool to help teams with their scaling issues yet we are just starting to see its real benefits. Check out the docs to know how to adopt it in your projects.

Even though curiosity was knocking the door, something was holding me back. I had to answer the question of whether I wanted to be a Swift specialist, or broaden my skills, not just to include other programming languages, but also to areas like design, product, or even people management. I ended up pursuing the latter: adventuring myself into trying new things.

At work I learned Ruby and Ruby on Rails. I learned how to work in large and distributed organizations and support them with tooling. I learned how to communicate better and how to build a trust battery with other people. I’m also learning how to manage people and how to help them grow and have impact in their careers. In my spare time, I learned React and Typescript and played with Gatsby and theme-ui, which by the way, I fell in love with them both. I learned how to use Swift to implement a command line tool and how to build a great product that cares about the user experience. I learned about design by designing the brand and the website of Tuist. Also with Tuist, I learned how to build a healthy community of users and contributors that engage with challenging problems and that are thrilled to help others.

In hindsight, moving on from the label "iOS Developer" is one of the best things I could have done in my career. These days I’m not the best in any of those areas, nor I want to be. However, I know them well enough that I can explore challenges and ideas from many angles by myself. I feel empowered to build things, and I guess that’s where my motivation for building Tuist comes from. It’s not just about the challenge, which motivates me a lot, but having the opportunity to think of Tuist as a product, as a community, as a philosophy of working. It’s incredibly exciting!

Another advantage of moving on is being able to come up with better and more creative solutions as a result of being more resourceful. If I had remained as an iOS developer, I’d probably tried to push Swift to places where the language is not the most suitable option. For example, I’d have tried to use it to build my website, or implement a web service with it. You can definitively do it, but after learning about other options, I can choose the ones that I think are a a better fit for what I’m trying to do. For instance, I have to build a website, I’d use something like GatsbyJS or NextJS and if I had to build a web service, I’d use Rails. Swift was a good option for Tuist to encourage contributions, and I’d continue to use it for building apps.

Being a T-profiled techie (I originally wrote it as engineer but I that’s a constraining label that I’m trying not to use anymore) might feel exhausting because you are constantly pushing yourself outside your comfort zone, but it’s definitively worth it. It’s the same as learning a new language; it helps you consolidate the languages that you know, and find interesting connections from which you can learn a lot.

I think it’s a wonderful idea because we delegate to the compiler the task of checking whether a resource exists or not. It prevents apps from crashing at runtime, and thus improves the stability of the apps.

Why am I bringing this up? Because I like the idea so much that I’m pondering integrating SwiftGen into Tuist. SwiftGen suggests adding a new build phase to every target for which we’d like to generate the interfaces. However, I’m planning to do it differently. If users of Tuist enable this feature, the interfaces will be generated at the project generation time. The generated project will already contain the resources and their interfaces ready to be bundled and compiled.

I might give this a shot later this week. I had a look at the SwiftGen project and it exports a target that we can link against to use its API. Moreover, the license is compatible with Tuist’s so there shouldn’t be any issue. I’m planning to set up this first integration defaulting to a conventional format for the interfaces and maybe revisit this in the future to add a certain level of configurability.

What I find beautiful about this idea are 2 things:

• Developers don’t need to maintain a translation layer like Fastlane that maps intents to calls to Apple tools. This often becomes a common source of issues and complexity in projects. - They can learn a concise list of commands that they can use to interact with any project defined with Tuist.

My motivation for building new features into Tuist usually comes from trying to iron out some inconveniences, or creating new workflows as I'd like them to be. For instance, implementing project generation in Tuist embracing Swift as an interface language and abstracting the definition of dependencies was motivated by the fact that having more Xcode projects at SoundCloud was becoming painful and error-prone. I implemented an API for describing dependencies that was simple and understandable by anyone.

It's a similar scenario when it comes to automation. The industry accepted Fastlane as the go-to solution to define a CLI for projects. It does a really good job, and we owe a lot to it, but I used at scale results in a lot of duplication and complexity spread across Fastfiles that no one wants to maintain. For that reason, I think Tuist could go one step further and make things simpler leveraging project generation and the foundation that we have built. The way I picture myself as developer working in a large project is the following:

I'd cd into the directory that contains the project that I plan to work on. tuist focus would give me an Xcode project that I can use to edit the code, and I can use tuist build, tuist test, and tuist lint to make sure that the code does what's supposed to do and that it follows the styling conventions.

As simple as that. I can go to any directory that contains a Project.swift file, and run any of those commands knowing that Tuist will know how to proceed.

I'm so excited for this that today I put the first stone towards this vision.

I'm quite happy with how the project has evolved so far with the help of everyone involved in the project. The slow yet steady pace of adoption in the community made it easy to keep en eye on the project's architecture while introducing new features. Doing so is crucial to have a healthy codebase that has little technical debt and allows adding new features easily.

Over the project's lifetime, we moved from a single-target project to a modularized one. Perhaps because I was heavily influenced by my work at SoundCloud, where I introduced the idea of Microfeatures. Although the main goal of modularizing the codebase was to improve developers' productivity, it allowed identifying and defining different areas of responsibility that were represented as frameworks. Teams worked independently but highly aligned thanks to shared utilities that were core to SoundCloud business domain.

I believe the benefits of having a modularized architecture for Tuist are the following:

• Have owners and experts in different domains of the code base. For instance, there can be an owner of the generation of Xcode projects. They'll make sure that manifests are properly translated into Xcode projects, and that the generation of Xcode projects is fast. - Ease first-time contributions because new contributors don't have to get familiar with the whole codebase, just the domain that they are interested in contributing to. - Better design because adding a new feature is not just adding a internal class that I can depend on from other classes. It requires defining where the feature should be implemented (i.e. target), how the feature interacts with others, and what will be its public interface. At least to me, doing this type of engineering work is beautiful.

So far the areas of responsibilities, and therefore frameworks, that we have identified in the project are the following:

• Support: Contains Tuist-agnostic utilities. For example, there's a utility for interacting with the file system, FileHandler, or another one to output information to the user, Printer. - Support testing: Contains Tuist-agnostic utilities for testing purposes. It also includes XCTest extensions for tests to use. - Core: It contains utilities and models that are core to the business logic of Tuist. For example, the Project model is ubiqutuous to all the features of the project and therefore needs to be defined here. - Loader: Contains the logic responsible for reading the manifest files and generating an in-memory dependency graph that is used latere on to generate the Xcode projects. - Generator: Contains the logic that translates the in-memory graph into valid Xcode projects that developers can use to work on their features.

All targets have an associated -Testing targets, which provide test data and mocks to the targets that depend on them. This is another idea that I "stole" from my time at SoundCloud and that I really like because you are facilitating future testing work. Writing a test and realizing there are mocks for our test subject dependencies already defined is priceless. Some people prefer to use tools like Sourcery for this type of work, but I'm a bit old-school here.