Building a different company

As you might know, @marekfort and I are working on building a long-term company that funds the development of Tuist and open-source software aimed at advancing the ecosystem and enhancing the experience of developing apps for Apple platforms.

We’ve never built a business before, which can be both intimidating and exciting, as it allows us to design the type of company we want to create. We often discuss the principles and ideas we want the company to embody, as well as the things we should avoid because they don’t align with the values of the company we’re building. What follows is a distillation of the cornerstone ideas shaping our company.

Standards

Standards enable interoperability and portability for teams. We want Tuist to be interoperable and give our developers the freedom to move if they think it’s the right thing for their projects. If we no longer play a role in their journey, what are we gaining by retaining them using proprietary designs? We see companies playing that game a lot. For example CI services with proprietary YAML formats, or pipelines whose source of truth is the server, where only a UI editor is available. This won’t be us. Note though that sometimes coming up with something that somewhat feels proprietary is inevitable. One could say that the Project DSL is, and we are aware of that, but we designed it aligned with Xcode projects and SPM as much as possible so that by the time the capabilities of those formats are the ones that are needed to work at scale, we integrate with it and deprecate the Project DSL. Some examples of how we are embracing standards are:

  • The adoption of Package.swift as an interface to define dependencies.
  • The adoption of OpenAPI for our API.
  • (Soon) The adoption of Grafana as a solution to provide a metrics dashboard to organizations.

Openness

We believe the best companies are shaped in the open. When you are open, you are required to show the best version of yourself and leave space for people to shape the product, which depending on how diverse the community is, might translate in that diversity codified into the tool. Being open also means you remove siloes of information. Anyone can find the information that they need. This is key in enabling the remote company that we want to be future. We are documenting how we are shaping the company in the company handbook, and sharing how we are thinking about Tuist, like I’m currently doing in this post.

Many companies out there are driven by fear: the fear of being copied, the fear of being outcompeted, the fear of someone building on your block. And fear leads to building walls, walls create silos, and silos slow down innovation. We want to tear down walls with Tuist and advance the ecosystem by forcing everyone to innovate in new layers.

The challenge here is to balance openness with building a sustainable business. Some companies like Ghost or Grafana have a larger market so the risks of openness would be negligible. But for us, whose market is a portion of the Apple development space, the risks would be significant. But we believe there’ll be an inflection point once the funding is secure after which we’ll be able to open everything except the sensitive information and give our developers and teams the freedom to read all the software that makes Tuist possible.

Simple and transparent pricing

Contact sales! Contact sales! Contact sales!" Banners that follow you across marketing pages and product demos—we’re not fans of those. We know the sales books say this is what you should do, but we’re not a traditional company. We want to respect people’s freedom to explore the tool at their own pace, with full transparency about what they’re paying for and how.

We’re not about “squeezing as much money as possible” or “designing something that gives us the upper hand in negotiations.” We believe people should pay for what reflects the value they derive from each feature, with no need to negotiate. Everyone pays the same price, period. What if you’re not great at negotiating? No problem—you’ll pay the same as everyone else. This isn’t about extracting the most from you; it’s about a fair exchange of value. We provide the best solution to your problems, and in return, we get something that reflects the value you’re receiving. And that money doesn’t just support Tuist—it also fuels innovation in the ecosystem through more MIT-licensed work that helps push the industry forward.

The only pricing we don’t make public is for enterprises wanting customized packages. But as we gain a clearer understanding of common customizations, we’ll structure and publish that pricing as well.

Community-driven

Tuist exists thanks to its community, and they hold a special place in our hearts. We are here for them. When we talk to others and explain what Tuist is and its value, we often highlight our amazing community, always eager to advance Xcode development, scale, and explore new developer experiences that bridge the gaps in Apple’s tooling. Seriously! Our community is truly exceptional, and we feel incredibly fortunate for everyone who has shown up and contributed to Tuist in one way or another.

Building a business is a natural next step to ensure the project not only survives but thrives, bringing in the necessary resources to invest back into the community and the open-source work we do, enabling us to keep innovating.

We’ve noticed that some companies in the developer ecosystem recognize that having a healthy community is crucial for the long-term success of a project. As a result, they throw money at the problem, as if communities could be built with money alone. We don’t believe that. A community is one of those areas where money can’t be a shortcut. Developers notice this immediately. A community is built by being human—by showing up every day, talking to people, understanding their pains and ideas. You build it by empowering people and encouraging them to execute on the ideas they have. You also build it by sharing your vision for the future of the tool they use every day, like I’m doing here.

Tuist is 7 years old, which means 7 years of building its community. It’s valuable, and we’ll continue to support and nurture it.

Joy

When building developer tools, it’s tempting to think we’re building for computers, which don’t have emotions. But no! We’re building for human beings—people who feel emotions and crave joy when using something. That’s what drives us! Thanks to Ruby and Ruby on Rails for setting the precedent—it’s possible to design software that optimizes for joy. We’ve done our best with Tuist, and we’ll continue this approach as we build business features too:

  • It’s a joy to edit your project in Swift.
  • It’s a joy to see the graph of your project.
  • It’s a joy to watch your dependencies become binaries.
  • It’s a joy to share your app with a simple URL.

If a solution isn’t enjoyable, we iterate until we find a version that sparks joy. Is code signing complex? We simplify it conceptually and build something more enjoyable. Does sharing an app involve too many steps? No problem! With TuistPreviews, you can click a link and see the app load in the terminal.

This philosophy extends to the business side too. It’s not enjoyable to feel like a product in a negotiation, so we don’t do that. It’s not enjoyable to be convinced you have a problem just to sell you something you don’t need, so we don’t do that either. If Tuist isn’t solving a problem for you, we’ll tell you. Seriously, we have nothing to gain by optimizing for anything else.

And what do we tell contributors who join Tuist? Do whatever brings you the most joy, as long as it aligns with Tuist. It’s your spare time—don’t waste it on things that don’t bring joy. When people work for joy, wonderful things happen. Just look at Linux!

Is this the right way to build a company? There are many approaches, but this is ours. We want Tuist to thrive in the long term and play a role in advancing the ecosystem, and we believe this is how we can achieve that.

3 Likes