You Can’t Out-Logic a Developer

I’m a developer. I show up at work and complete issues or tickets within the framework of tools and processes that were there before I joined the company. Things are generally fine, I can deliver my work at the expected pace, but there’s this one thing that’s annoying, which is slowing everyone down.

Turns out we are not the only ones with the need to address that to make everyone more efficient at their job. It was so common that someone decided to solve it and sell the solution as a service. The adoption could be one click away, but I’ve been there before. There’s legal, security, and procurement processes I have to go through, which in fact are more painful than the pain that motivated the consideration of a solution in the first place. Why would I go through that painful process?

Turns out there’s a workaround, an open source project that’s not actively maintained anymore, or even better, the opportunity to develop a solution in-house using the technology that I always dreamed of using. This tendency to prefer internal solutions over external ones is what psychologists call the Not Invented Here syndrome. If it turns out well, my leaders will be happy, and if we make it open source, the effort will come with public recognition. My manager is uncertain about the idea. “It’s not the company’s business,” she said. We have these many other priorities to focus on. It’s a difficult conversation for my manager to have because I’m a great asset for the company, but I got motivated so much about the idea of solving that problem that not doing so might lead to me considering leaving the company.

If I have agents helping me write the code, and the company with the infrastructure to run it figured out, why not? I think…

Turns out this is companies’ biggest challenge when selling tools and services to developers. They have the tools to make them believe that it’s more sensible to build something in-house or deploy some open source software over going through a painful procurement, legal, and security process. We see that at Tuist all the time. And we know that most services are more than just the software itself. You need to figure out availability, safety, performance, latency… And this is indeed a big chunk of what they are paying for. But it doesn’t matter, many won’t see that, and will go miles to avoid it.

The other day while listening to an interview with Rik Haandrikman, it was fun to hear that he realized that was RevenueCat’s main challenge when selling to developers. His answer? Let’s be in every single conference with the best booth such that developers perceive us as a cool brand and product to be associated with. Very smart! This strategy leverages the mere exposure effect, where repeated encounters with a brand increase familiarity and positive feelings toward it. Turns out we, logical creatures, are hackable too. Years ago I’d have built a RevenueCat service myself, but today? Seeing many developers building their indie careers with RevenueCat makes me want to pitch it to my employers and go through any necessary pain to have the merit of having introduced RevenueCat at my company. It’s social proof in its purest form. Many developers want to be indies these days and have a revenue, so if you capture that in your messaging, in essence “we are the tool to help you achieve that lifestyle,” you won’t think about anything else. This taps into what psychologists call aspirational identity, where people gravitate toward brands that represent who they want to become. I think it’s very smart.

And how do you get developers excited such that it translates to their employer becoming your customers? Ha! That’s the billion dollar question. One pattern is clear though, when we look at other tools like Supabase or Vercel. The developer doesn’t pay. The developer is one step closer to their employer, which is the account the business is really interested in. Figuring this out is the difference between tapping into a small group of developers, or tapping into a large market from where you can get the largest accounts.

At Tuist we don’t have that figured out yet. There are some constraints we need to work within, like having limited capital. For example, trying to throw money at that is out of the equation for us. We can also focus on building a top-notch product, like Linear is doing in their space. Especially considering that tools in the developer space are not known to place a strong focus on the feeling that using the tool evokes (with some exceptions). But I don’t think that’s sufficient. We need something else. We need something that can make Tuist stand out among its competitors. I don’t know what the exact answer is yet, but I have the gut feeling it’ll revolve around open source.

Tuist was born within open source, and this has had a strong influence in how we shape the company. Most of what we do is in the open. Developers love this. They love looking at the code and being able to learn from it or contribute to it. They like when they see the magic behind what they use, and why not, run it locally and play with it. They like when they feel the company is contributing to some commons, when the company sees the ecosystem as something to make better, while ensuring the business thrives. They like when there’s a layering between the technology and offering it as a service to sustain the development of it. For instance, like Grafana does with Grafana Cloud. This model takes longer to nurture, but it builds deeper and more long-lasting connections with the people that come to the tent. Just earlier today I was chatting with a customer of ours who said it’s so cool that they can point Codex at our codebase and find answers to questions that otherwise would go through our support team. It’s a win-win situation. They get what they need, and even contribute doc improvements, and we don’t need to get involved.

I think the above needs to be spiced with a bit of a lifestyle approach à la RevenueCat. Once again, the million dollar question. We don’t have concrete answers, but we are identifying patterns that we think we can build an overarching story around. A vision that we can share and get developers excited around too. Through Tuist we learned how much teams appreciate feeling productive, something that’s getting trickier as more code is being produced with AI. But making your dev setup productive is something that has traditionally been exclusive to the large enterprises. But what if it didn’t have to be like that? What if your workflows were as fast as they can be by default? Would you say no as an indie developer to save 40% in every build? This is just a very premature idea, but we are starting to build the infrastructure that could enable something there. Productivity pairs nicely with what AI is enabling. Developers are connecting with that momentum and tooling is surfacing the limitations of today’s tooling. The one that we’ve used for decades.

It’s a fun journey. And the best of all is that in 2025 we built the foundations to do those explorations. From an open source foundation to a team to enable this, including a strong brand and the product as the innovative ground to plant new seeds. Which seed will lead to the forest we want? Time will tell.