Naming a project tool "Tree"
How we named a project tool 'Tree.' Forty candidates, ten survivors, three finalists, and the objection from one early reader that became the answer. Plus the costs we accepted (search visibility, social distinctiveness, trademark scope) for a name that's almost too plain.
The naming process for software products is usually some combination of brainstorming, domain availability checking, and increasingly desperate compromise. You start with twenty candidates, fifteen are taken, three are bad, and you ship the remaining two with whatever spelling the .com is still available for.
We did this. The result is "Tree." This post is about how we got there, what we considered and rejected, and why a name that's almost too plain ended up being the right one.
The brief
We needed a name that did three things.
It had to evoke the product's central metaphor. The tool is built around a tech tree: tasks as nodes, dependencies as edges, projects as branching structures. The name should signal that without requiring an explanation.
It had to be short and memorable. Project management is a crowded category. Long names get truncated. Clever names get forgotten. A name that's one syllable and instantly typeable has structural advantages.
It had to feel quiet. Most software product names are loud (Asana, Trello, Linear, ClickUp). The voice we wanted was the opposite of loud. The name had to support the tone, not fight it.
These three constraints narrowed the search faster than expected.
What we rejected
We brainstormed about forty candidates. Most were obviously bad. The ten that survived initial filtering, with the reasons each was rejected, are below.
Branch. First instinct. Captures the metaphor cleanly. Two problems: too on-the-nose (the name is doing too much of the metaphor's work, leaving nothing for the product), and Branch.io is a deep-linking SaaS company that owns mindshare on the word. Rejected.
Forest. Plural of trees. Suggests the bigger picture. Same on-the-nose problem as Branch. Forest.app exists as a Pomodoro timer. Rejected.
Canopy. Evocative. Suggests structure overhead. Already taken by Canopy Tax, Canopy CRM, and several other SaaS products. Rejected.
Roots. Suggests dependencies, foundations. Rejected because it points downward (toward the past) when the product is about pointing forward (toward the unlocks). Wrong metaphor direction.
Trellis. Suggests structured growth. Beautiful word. Difficult to spell, harder to pronounce, and trellis.com is taken. Rejected.
Sapling. Cute. Diminutive. Rejected because it suggests Tree is small and growing, which is true now but not the long-term positioning.
Bough. Single branch. Archaic. Rejected because nobody under 50 uses the word "bough" and the product would have to teach its own name.
Forge. Suggests building, craftsmanship. Already used (Forge.dev, Forge from Atlassian, Forge our parent agency). Conflict on multiple axes. Rejected.
Node. Most obvious. Tree is built on nodes. The name is too generic, technically, and Node.js owns the term in technical contexts. Rejected.
Tier. Suggests progression. Too thin. Doesn't evoke the structure. Rejected.
After the rejections, three names survived: Tree, Atlas, and Vine.
The shortlist
Atlas. Suggests mapping, comprehensive overview, the structural sense of seeing the whole project. Strong name. Multiple existing companies use it (Atlas Obscura, Atlassian, MongoDB Atlas). The Atlassian conflict was disqualifying: we couldn't ship a project tool with a name a syllable away from our largest competitor.
Vine. Suggests organic growth, branching, structure that emerges. Beautiful in some ways. Rejected because the social media product (vine.co, then vine.com) is too recent and the connotation hasn't faded. Also: vines suggest tangling, which is the opposite of what the product does.
Tree. Almost too plain. The objection from one early reader was "isn't that just describing the metaphor literally?" That objection became the answer. Yes, we're describing the metaphor literally. The product is a tree. The name is "Tree." The honesty is the point.
We chose Tree.
Why "Tree" works
The plainness is doing structural work.
The product is a tech tree. The name is "Tree." When you say "I planned my project in Tree," the metaphor and the literal product collapse into the same statement. There's no gap between what the tool is and what it's called.
This is unusual in software naming. Most product names are evocative without being descriptive. Linear evokes clarity but doesn't describe what it does. Notion evokes thoughtfulness but doesn't describe its function. Asana evokes flexibility but is borrowed from yoga. The name and the function are connected by association, not by identity.
"Tree" is connected to its function by identity. The name is the metaphor is the product. This produces a few effects.
The name is unforgettable for users who get the metaphor. Anyone who's used the product for ten minutes will remember the name forever, because the name is the visual structure of what they were just looking at.
The name is interpretable for users who haven't seen the product. "Tree" suggests a tree structure, which is most people's intuition for project organization anyway. The name does explanatory work without trying.
The name is hard to confuse with anything else. There's no Tree CRM, no Tree messaging app, no Tree note-taking tool. The word is so common in everyday language that it's mostly avoided in software naming, which leaves the slot empty for us.
What we gave up
The name has costs.
It's not search-optimized. "Tree project management" returns articles about literal trees, family trees, decision trees, and binary trees long before it returns Tree. We're going to have to fight uphill for search visibility, especially in the early years.
It's not socially distinctive. When someone says "I use Tree," the listener might ask "tree, like the project tool? Or are you talking about something else?" The name produces clarification overhead in conversation that more distinctive names don't.
It's not trademark-friendly. We can't trademark the word "Tree" in isolation. We trademark "Tree" plus visual elements (the logo, the wordmark, the .nl domain) and rely on context to do the disambiguation that the name itself can't.
We accept these costs because the alternative was a more distinctive name that didn't capture the metaphor as honestly. We'd rather have search uphill battles than a name that obscures what the product is.
The domain
We bought treeapp.io and treeapp.nl. The .com is owned by a tree-care company that isn't selling.
This is the standard modern naming reality. The .com is almost always taken. We chose .nl because we're based in the Netherlands and the country code adds a small amount of brand identity that the .com wouldn't have. We chose .io as the international primary because it's the conventional default for software products and wouldn't confuse English speakers.
The dual domain costs us a small amount of clarity (some users will hit the wrong one) and gains us a small amount of distinctiveness (the .nl signals where we are). It's a reasonable tradeoff.
The lesson
The naming process taught us something we'd repeat. The most evocative name is sometimes the most literal one, because the literal name and the product become the same object in the user's head.
Most product naming optimizes for distinctiveness, association, or memorability. We optimized for honesty. The name is what the product is. The metaphor and the noun are the same word.
That's why Tree is called Tree.
If the name and the product line up the way we hoped, join the waitlist.