Principles

These are the values we hire, work, and part ways by. They define what kind of company Tuist is. Everything else (process, tooling, how we run a week) flows from them.

Be developer obsessed

We obsess over developers the way great product companies obsess over their customers. Our job is to make their teams effective: projects that stay healthy, builds you can trust, tests that tell the truth, releases that don't hurt. Speed is a symptom of that, not the goal.

We see customer pain two ways. We dog-food our own tools, so our friction is a signal. And we listen hard to feedback for the pain we can't feel ourselves: different scale, stack, workflow. Either way, we act on it as if we were part of the customer's platform team.

In practice:

• Every proposal answers: does this make a developer's day shorter, clearer, more reliable, or less painful?
• Friction in our own workflow is a product signal, not something to route around.
• A bug report sitting untouched for a week is a failure of this principle, not a backlog item.
• Complaining about a tool without proposing a fix is not a Tuist-shaped activity.

Compound with AI

Tuist is an AI company. Not because we sprinkle LLMs on features, but because we're building for a world where developers ship alongside agents, and we expect everyone here to already live in that world.

AI is a multiplier on work you already do well. The point isn't to make AI the first step in everything. It's to fold it into your workflow so the things you ship are sharper, and there are more of them. A designer who reaches for AI doesn't stop thinking like a designer; they get more of their best work out the door. Same goes for engineering, support, sales, anywhere.

That mindset means staying curious about what AI can and can't do, testing the edges, and sharing what you find. Treating AI as a trend to wait out, or as someone else's problem, is not a fit here.

In practice:

• If a workflow you own hasn't changed in months, that's worth poking at.
• Share what's working: a workflow, a prompt, a failed experiment.
• Skepticism with evidence is welcome. Skepticism on vibes is not.

Ship with taste

AI raises the floor on output. It doesn't raise the ceiling. The ceiling is set by taste, judgment, and care. That's where humans still earn their keep. We expect everyone here to bring great product taste, and to hold a high bar for what ships under our name.

Craft shows up in the obvious places (the design system, the CLI's error messages, the docs, the way a page loads) and the unobvious ones (a clear PR description, a well-named function, a support reply that actually helps). It's the difference between something that works and something that feels right.

Caring about craft is not a license to over-polish. We ship. But we don't ship work we're not proud of, and we don't hide behind "AI wrote it" when it isn't good enough.

In practice:

• Before you ship, ask: would I be proud to put my name on this?
• Use AI to get to a draft faster, then spend the time you saved on taste: naming, clarity, edge cases, the last 10%.
• "It compiles" / "it passes" / "the model produced it" is not the bar.
• Polish small things. The error message, the empty state, the typo in the doc. They add up.

Default to open

We publish our handbook, our dashboards, our code, and our roadmap. We work in public because it makes the company better: more feedback, sharper thinking, stronger trust. Openness is load-bearing for us, not a marketing trick.

Working in public is also how we operate day to day. Decisions happen in the community forum, in public Slack channels, and in GitHub issues and PRs, not in DMs. Shipping is half the work; writing about how and why we built it is what lets others learn from and build on it.

Some things stay private: customer data, performance conversations, unshipped security work, contract negotiations, anything that would put a person or the business at real risk. "It might be embarrassing" or "it's easier" does not clear that bar.

In practice:

• Public channel, public issue, public PR, unless there's a specific reason not to.
• Decisions get written down where the community can find them.
• Ship the work, then write about the work. Both count.
• If you catch yourself defaulting to private, check the reason. Usually there isn't one.

Play the long game

We are building Tuist for decades, not quarters. The Tuist we want to exist is years away, not weeks. That shapes how we trade off short-term wins against long-term trust, quality, and focus.

Playing the long game means saying no to work that would compromise the product, the community's trust, or the team's focus, even when there's short-term pressure to say yes. It means investing in things that pay off slowly: the handbook, the docs, the open source, the relationships. It means not chasing trends we don't believe in.

It also means holding our current views with the humility the long game demands. We bring strong opinions, built from real experience and evidence, and we hold them weakly enough to update when the evidence shifts. The failure mode we care about is ego attached to an opinion. It shows up as defending a position after the facts have moved, or as treating disagreement as a personal attack. Over a decade, the people who are right most often are the ones who change their minds most willingly.

In practice:

• When short-term and long-term disagree, say so out loud before picking.
• We don't ship things we'll regret shipping, even if they'd hit a number this quarter.
• Bring opinions, especially unpopular ones. Silence is not humility.
• If you can't articulate what would change your mind, you don't have a position, you have an attachment.