Adding tools

Every tool a company adopts is a small tax it pays forever: another login, another integration to keep working, another place the truth might live, another bill. A pile of half-used SaaS tools is how a company ends up with its own operations quietly rotting. So we're deliberate about what we add, and the default answer to "should we get a new tool for this?" is "probably not, let's see if what we have already does it."

What we reach for

• Fewer tools, used fully, over many tools, used at ten percent. One thing everyone actually knows beats five nobody has learned.
• Boring and proven over new and exciting, the same instinct as how we build. A tool is infrastructure; novelty there is a cost you pay at the worst possible moment.
• Open source where it's a real option. We'd rather build on things we can read, fork, and self-host than rent something we can't see inside. It fits how we work, and it's rarely the wrong call.
• Where the work already lives. Most of what a company reaches for another tool to do, GitHub and the handbook already do. Reach there first.

Before you add one

Adding a tool is a decision the whole company inherits, so make it in the open:

1. Say what problem it solves, specifically. "It would be nice" isn't one. A real, recurring pain is.
2. Check we don't already have it. We probably pay for something adjacent. Duplicate tools are how one team's data drifts out of sync with another's.
3. Think about the data. Where does our information go, who can see it, and can we get it back out? A tool you can't export from is a trap with a monthly fee. Anything touching customer data gets a harder look, see security.
4. Someone owns it. A tool with no owner becomes a bill nobody remembers and an integration nobody maintains. If you add it, you own it until you hand it off.