Building a business around Tuist

This blog post will be valuable to those interested in the evolution of Tuist, as well as to individuals starting their own business—whether as indie developers or as a company.

In October 2023, Marek and I agreed we'd build a business to fund the development of Tuist and lay the financial groundwork needed to work full-time on what we like the most: crafting developer experiences for app developers and building a community who would join us in that effort.

At the time, we had the community and a CLI that teams loved and used every day. We had experience at Shopify building solutions for app developers, from tools like tophat, Shipit Mobile, and Mac infrastructure, to building runtime libraries for React Native. We had the necessary ingredients to transform Tuist into a platform to help teams build better apps faster. We only lacked one experience: business.

We'll admit it felt intimidating at first, but we were so passionate about what we wanted to achieve that we threw ourselves into understanding and navigating what it takes to get a business off the ground. Since then, we've learned a lot—sometimes by accident, other times by reading—but regardless, we always tried to follow our instinct and did what we believed was best for the project, its community, and what aligned most closely with the type of company we wanted to build.

What follows is a non-exhaustive list of our learnings that you might find useful if you are transitioning or considering leveraging your development skills to build your own company, either as an indie developer or as a small company. Remember that every company is different, so what worked for us might not work for you. If we had the chance again, we'd absolutely do it again, because regardless of the challenges and the many ups and downs that come with it, it's extremely rewarding being able to create an environment where people can show up and help advance a certain ecosystem. Let's dive right in.

From collaboration to competition

Many people associate gratis with open source. Tuist was both, which is very inviting to contributions, collaboration, and also to donations. Once you build the brand, the project can be the catalyst for other brands. Being associated with open source and recognized community projects is attractive.

But things change when you break the "open means gratis" mental model. You go from being something others want to be associated with to something that has the potential to become a competitor, so dynamics naturally change.

And there's something unique to this kind of competition. It's usually a competitor with limited financial capital but with high social and human capital. This is abstract and hard to measure, but social capital can truly make the difference between thriving or not, and this is core to the way we shaped and continue to shape Tuist. Our interactions with people go beyond "selling," "marketing," or "supporting." We give our hands to everyone. We collaborate with the people who show up. We share how we see the ecosystem and tell them what we are doing to get to a better position. We do so without expecting anything in return, which naturally builds unique momentum and value.

We like to say that we are a tiny fish with little financial capital in an ocean of whales, but with human capital that can move mountains.

We've seen companies evolving their relationships with us, and we'll continue to see that, but we believe that's a natural part of the process. We're embracing it as a positive sign that we are on the right path to having an impact in the ecosystem. And to be honest with you, being able to do so with little capital is exciting because it brings out the most creative and human versions of ourselves.

About markets

Building a company has taught us a lot about markets and business models. For us, we just want to have fun without being too worried about how to fund being able to do this full-time. We believe financial success is a consequence of having an environment where people can craft something for fun, not something easily achievable if you have it as your main goal.

The reality is that it's the goal for many companies, often because there's a set of hidden incentives beyond the company, and this leads to a market-based perception of ecosystems. Let us unfold for you the mental model that we've formed.

Ecosystems are markets—groups of people or companies that can be your customers. The larger the market, the better, and companies will do their best to capture most of it. Having a single company in a market is not good because innovation stagnates, though companies often prefer to be the only ones. Once they are in this dominant position, they can roll out practices that no one can challenge.

Because markets invite competition, companies design products to create vendor lock-in. Some do it through ecosystems and social capital. Why don't you leave GitHub? Because your developer CV is there. You get the idea... At some point, they reach a ceiling. They keep raising capital and making promises that they can break that ceiling through diversifying their offering, but then they force the product in ways that consumers can feel. At the same time, other players join the space. Those players can get capital easily because it's a known market, and then they try to push the prices down and attract customers through cheaper prices. Then, if the vendor lock-in is not effective, customers move on.

At the same time, software commoditizes through open source, which means what was once your competitive asset is no longer one. As we learned through Tuist, once you build an open-source commodity and steward it, it becomes more attractive for the market.

We think CI is a good example of this. It's a highly commoditized space. GitHub and GitLab changed the space by not only building CI into the Git forges, which gives them a unique development experience advantage, but designed it in a way that you can bring your runners and shift the cost to you. Then many companies emerged to provide those runners. They first built on existing cloud providers, and then they rolled out their own hardware. But once the market becomes very saturated, nothing prevents a company like AWS or Cloudflare from providing those runners for you because doing it reliably and fast is indeed their strength. You can't compete with AWS or Cloudflare providing containers close to where you need them because that's a muscle that they've built for years.

What does this all mean? That you need to know well what differentiates you. In the context of CI, for instance, you might have noticed that some companies try to offer more than just pipelines, environments, and build logs. Buildkite, for example, is placing a strong focus on building a top-notch product.

For Tuist, we had to decide what our strength would be. There are not that many options in the dev productivity and app quality space for app developers, and Apple could solve some of the problems that we are solving, so what are we going to do differently to stay relevant and continue thriving? In our case, we decided that we'd focus on the following things:

• Community: We'll continue building on open source, hence why our long-term plans are to open source everything, and create ecosystems of extensions for the toolchain.
• Developer experience: We want to build a product that's a joy to use thanks to our attention to detail. Sounds familiar? Attention to detail is what makes Apple products stand out, and it's the reason why we've built a design system for our CLI and dashboard, Noora. Top-notch experiences are not an afterthought.
• Innovation: We should thrive on innovation. There are many workflows that are not possible in app development, and others that feel broken. Why aren't we able to get a preview by tapping a button? And why are releases still triggered from a CI pipeline? We need answers for these questions. Innovation requires creating a culture where new ideas are embraced and given the time, space, and love so they can emerge.

These are the traits that we see making us unique in our space. Now, what's our space? That's a good question... By saying you belong to a particular market, everyone can immediately understand what you're all about. "I do CI," or "I do analytics..." But we don't fit into any of the pre-established markets. We would say we are creating a new one, but we don't like the idea of markets either because they constrain what you do. We see ourselves as something more fluid. We solve problems and challenges that we think need a solution or a better one, and sometimes that means we'll step into other domains. Are previews the same as nightly builds? They are builds, but closer to where collaboration happens. Will we do CI? We'll figure out how to provision runners for some features, and since that's a base step for CI, we'll provide runners too. CI has already been solved by GitHub. These are just some examples. The core element around which everything gravitates is "apps"—first in the context of Apple ecosystem, which we know well, and potentially exploring others once we feel the time is right.

Why would anyone pay for this?

Providing a solution to a problem is not enough. First, the shape of your solution needs to be something people are used to paying for. Tuist started as a CLI. Trying to charge money for a CLI? Not a great idea. You typically don't pay for a CLI. This is a mental model that would take a tremendous effort to change.

A server? That's a different story. We'd pay for a solution on a server. Preferably, we'd be ok with being the product to get it for free, but if they ask us for money for a server solution whose value we perceive, we'll pay for it.

That meant strategically that we had to focus on problems whose solutions require a server. Moreover, we agreed we'd do so following a model where any client-side technology would be open source and free of charge, and the server would augment it to provide different types of insights. Take, for instance, running tests. Running a test suite just tells you what passed and failed, and how long it took. Store that information over time (in a server database) along with a fingerprint that captures whether it changes or not, and you've got a solution to detect flakiness. We made an exception to this rule which we aim to phase out once we can secure the business: cache.

But we don't want to end here. Our server is closed source, but long-term we want everything to be open. But if we open everything, what do we charge for, right? We are still figuring out what the right model will be, but it'll most likely be a mix of paying for our hosting and a very small subset of features being under a slightly restrictive license to support contributions from larger enterprises for control over the platform. Most of our user base will be able to self-host if they want, as long as they are okay with the responsibilities that come with it. Our hosted instance will come with reliability, updates, speed, security, and support to help you focus on what matters. Many companies in the space try to maximize revenue from everyone, hence the classic "contact sales" or "check this demo" approach to products. We consider that to be inaccessible and hindering to innovation, so we want to take a different approach. Time will allow us to do that.

Mental models

Once people build an idea of what you are, it takes an enormous amount of effort to change. For many people, we are still an Xcode project generator. For another good portion of users, we are still just solving frequent merge conflicts. Many haven't realized that most of our features work with any Xcode projects, so you don't need a generated project. We'll continue to improve and support generated projects for as long as modularization continues to be complex within Xcode and there are no good alternatives.

This transition that we mentioned before—from a pure CLI solution to an ecosystem of solutions with a server at its core—came with a transformation of the product that we need to socialize. And believe us, this takes time and a lot of reminding about how we are evolving and how we see the space. We do that through our blog posts, videos, and content in various social channels. It never feels like enough, but it's remarkable how solidified some models can get in people's heads.

This not only applies to the shape of the product but to people's understanding of a problem space. They are so attached to a particular established solution that they forgot what brought them to the solution in the first place. It has a name: cargo culting. And similarly, influencing it takes time and a lot of energy. To give you an example, many are still using Fastlane's abstractions for building projects. Some might not be needed—they could just be an xcodebuild invocation from a bash script—and if you mention this idea, they look as if you were telling them to replace their build system. Moreover, many of these things happen because of social effects. We humans are social species, so trying to use logic in such a setup is a recipe for frustration. For example, we continue to evangelize the idea that SwiftPM is not always the best solution to model a project if you want a great DX for your team. Often, this feels like sending messages into a void, but sooner or later, people will be present and recognize that pain and will be able to connect it with the many times we talked about how challenging that approach can be. You won't believe this, but we've seen teams going from Tuist to SwiftPM and back to Tuist. We are the first ones to believe that if there's an official solution that works great, you should adopt it, but if there's not, we are honest about it.

Another learning is that people iterate on their mental models incrementally. In other words, they need new ideas to be connected with existing ones. For example, if you are suggesting Mise as an installation tool, you need to connect it with Homebrew, which many people are familiar with, and explain how it's more suitable. Or previews, which many people want to connect with nightly builds, which they are most familiar with. So business-wise, you need to find a good balance between pushing innovation while integrating that with the tools and mental models of people. Quite a challenge, isn't it?

Security

When projects are gratis and open source, companies' security concerns are few to none, even though risks exist. But a company that offers paid solutions changes everything. Suddenly, security becomes a priority. We had to go through the process of being SOC 2 certified, performed penetration tests, and found ourselves in extensive processes with security teams going through checklists of questions.

We care about security, and going through the process helped us improve the overall security of the company, but many aspects felt disproportionate.

First, the process can feel like a checklist where checking off items doesn't necessarily mean you are safer. It's more about making yourself liable through your proofs, such that in case something happens, there's someone responsible. The way we see it is that you build a liability chain: customer > auditor > company. And if something goes wrong, well, these things happen because humans make mistakes, so you'd better have insurance. Throughout the process, there were many times when we felt the approach was more procedural than substantive. And it doesn't matter if you just deal with low-sensitivity data, as is the case for Tuist, where we store information and binaries that are already in the apps that end up being shipped to the App Store. The process is the same for you, a small company that's just getting started, or a company with thousands of employees and in-house departments. And you sadly can't skip this if you want to convert customers.

Sales

Our only experience with sales was when I was younger and worked at family cafes selling coffees and churros. We guess this would be our version of "it all started in a garage." Customers came, and they knew what they wanted. We provided them with a great product and a very human service, and they most likely came back and told others about it. It seemed simple, and most of what we learned there applies to selling software too. We are humans at the end of the day.

Through Tuist, we learned a few things in the area of sales. First, many of the things that you read out there might not work for you because every market is different. So we learned by trial and error. We tried to send emails—the sales lingo for this action is "cold outreaches." Developers, our target, don't typically respond well to that. Developers like to build and avoid bureaucracy. They don't like to see an email in their inbox that says, "Hey! I want to sell you this product." They dislike going through procurement processes so much that they can go as far as building a solution themselves or working around your system. Not everyone is like that, but you can see a pattern. Developers won't make the final purchase decision—that's more of a manager or director responsibility—but they are the ones who can influence the decision, so understanding the psychology is crucial. We are developers ourselves, so we have a good sense of what we'd love to see.

There are different approaches to reaching developers. We've seen some companies applying techniques that connect to very basic emotions through their solutions. If you've ever been sold insurance, you know what we're talking about... Fear is in everyone; it's our tool for survival. And if we say that by not using our tool, your business might not be going as well as you'd like it to go—there you go, the fear of failing. Who likes that? Even if the connection between the two is tenuous, one thing we learned is that in business, many approaches are possible. Another approach we've seen consists of leveraging our social traits. We, as humans, tend to compare ourselves with each other. In the real world, you can compare your salary, your net worth, your cars, your iPhones... But in the software world, you need to come up with something else, and then you can even build your marketing on it. We prefer not to take that route.

So, with the quick tools out of the equation, how did we manage to get people to pay for Tuist? We focused on solving concerns that we noticed large companies have, like unproductive development environments, and solved them the best way we could, with a product that's very enticing to use. Apple solved people's needs to stay connected, as did Android, but they focused on solving it in the most beautiful way possible. That's similar to what we are trying to do. When you use Tuist, the value and the perceived value need to be as high as they can be—so high that you are inclined to pay for it if we ask for it and that you tell others about it. Like, "Hey! I used Tuist's cache, and now I have this amazing dashboard that helps me make decisions. Until that point, I was on the verge of having to transition my entire suite to React Native because leadership was questioning our ability to deliver."

What's key is that once the developer is convinced Tuist can be the solution to their problems, the process to witnessing the solution with their project needs to be as short as possible. They'll most likely do this in some spare time that they have here and there, so if the process is quite long, they'll most likely drop it, and you'll never be able to sell anything. For that reason, we invested in a new "get started" workflow that takes you through all the necessary steps, including creating an account. We are also making most of Tuist's features work with Xcode projects so that the changes you need to make in your project are as few as possible.

Some of our deals were closed motivated by leadership's pressure to reduce the costs of CI or deliver features faster. Apple's ecosystem has solidified the idea that feedback cycles can take time and that every new year hardware can help cut time, although it's expensive for companies. But leadership doesn't always understand this. They see other ecosystems like the web being faster and cheaper, and they can't comprehend why. Many decide to move to React Native motivated by that. In fact, Shopify did that, and while engineers might have mixed feelings about this, it's their approach to meet the demands of the market.

Dev environments and app quality

If we asked you what makes a healthy dev environment, you'd have a hard time coming up with a concrete definition for it. However, if we asked you if you'd use AI to enhance your dev environment, you'd most likely be inclined to say yes, even if you don't know what "better" is, because everyone is doing it. Do you see our point?

Take test coverage. A high test coverage doesn't necessarily mean the software does what it's supposed to do. However, there seems to be a consensus that that's the case, and we use the number to measure ourselves against ourselves and against others: what's your test coverage? How much higher did it get?

With productivity—something we help improve in dev environments—there isn't a direct number you can put on it. There are endless frameworks that have attempted to quantify it, but since there are many factors that contribute to the speed of delivering software, it's rare to see a company valuing investment in this domain. For instance, we were chatting with a friend who recently joined an AI-first company. They've given all developers access to Cursor and Graphite, but even if that means developers write code faster, other elements in the software delivery chain are preventing any productivity boost. In fact, they can no longer do continuous delivery with confidence.

As mentioned earlier, companies take productivity seriously if they have FOMO—for example, everyone is talking about Cursor and its productivity wins, and you want them too—or financial pressure, like paying a lot for costly CI macOS environments and wanting to cut costs. But a lot of it is just feelings. And depending on who you ask, different people experience productivity differently. For an iOS developer, waiting for a few minutes to see an app compiled is completely normal. A JavaScript developer would not deem it acceptable and would jump into figuring out ways to speed up compilation. So, in other words, the normalization of native app development being slow is our competitor.

With app quality, a territory we are stepping into, it's a similar story. What's a healthy app? An app that's lightweight, fast, and stable... but it goes beyond that. It's an accessible app, visually and linguistically, that supports many devices, that makes good use of the device's battery. The list is endless, and without numbers around many of these things, many developers and companies might not see the value in investing in tools that help with that unless there are clear metrics or benchmarks. For example, if your app is above a certain size threshold, a percentage of users might not install it.

Because of this, we are trying to understand how to measure some of these things, quantitatively and qualitatively, and provide teams and developers with those metrics so that they understand how it's impacting them. We are also encouraging developers to share their experiences. We said earlier that many times it's about feelings. We can talk forever about how challenging modular Xcode projects can be, but until you've experienced it yourself, or someone that you trust has experienced it themselves, it remains as something that doesn't or won't happen to you.

Marketing

There are many schools of marketing, and like many things in life, you can attempt to buy things with money—from paying people to talk about you to sponsoring conferences to place your logo. Done sporadically, this has a positive effect creating brand awareness, but doing too much of it can indeed have a negative effect. People can get tired of seeing you everywhere, and it feels forced. Developers don't typically respond well to that. Moreover, if you stop paying, and your logo fades, so does people's remembering of it. It lasts until you stop paying.

We sometimes do a bit of that, but not all the time for the aforementioned reasons. We lean on word-of-mouth marketing. But how do you get people to talk about you without paying them? Or how do we build a solution that creates natural advocacy?

This might sound trivial, and we're sure there are lengthy books written about it, but we get people to talk about us by being human and sharing our passion. We treat everyone as best as we can. They feel the joy we have about the app development space, and it has a contagious effect. They are happy with what they see to the point that they tell others about it, and this compounds. We share how our vision evolves and the things that we learned along the way, like this post that's a bit different from the type of content that you typically find on the Internet. We favor slow and deep content over attention-seeking content that just attempts to hack the algorithm of social networks. We don't feel like participating in those dynamics.

We share a lot of our work as open source and support others in building their own tools and businesses on our foundation. We don't see the space as a competition ground but as a collaborative space where having many players is indeed positive. The more, the better. Our social accounts are just syndication of content that we publish in our blog and community forum.

We show ourselves as we are. If we feel vulnerable, we talk about it. If we feel a space would benefit from some innovation, we share how we'd shape it. There's really no playbook that you can follow top to bottom—it's more about people who share the same values and principles talking about what Tuist believes in and aspires to be.

This has worked well for us, and we continue to see people and companies that come to us because they read about us, were told about us, or had Tuist on the list of tools that they were planning to use. We believe building a strong and long-lasting brand takes time, and while money can speed things up in certain moments, nothing can beat team, passion, and humanity.

The Tuist we want to shape

If you wonder what we want Tuist to look like years from now, we want it to be the best toolchain to help you build great apps fast. It'll hold your hand from the moment you've got an idea, offering you many templates to choose from, making the start more accessible, to doing releases, even on the go from an app. And we want this to span across other mobile platforms and technologies such as Android and potentially React Native. Shapes of this already exist in the web with platforms like Vercel. As development becomes more complex due to the surface of technologies, tools, frameworks, platforms, and products, building the muscle to help you stay focused, be productive, and ship the best apps to your users will get trickier and will require significant investment. While you could build those tools yourself, you can plug Tuist into your repo and App Store Connect, and we take care of the rest.

Sounds ambitious, we know, but we believe we are on the right path. Deciding to start the business was the best decision we could have made for Tuist. We've built a very talented team of people who are unique at their craft and a community that's also excited about evolving the experience of building and releasing apps with the world.

We are figuring out the boring stuff and creating an innovative environment where everyone enjoys doing their best work, and we innovate without having to worry about new ideas having to be immediately monetizable.

If you are going through something similar, want to evaluate Tuist for your project and support us, or you just want to chat, you can reach out to us at [email protected]. We'd love to hear from you.

This post was written by a human and its grammar reviewed with Claude 3.7 Sonnet.