Blog.
Notes from the build. Why we made certain calls, what we got wrong, and the occasional dispatch from the studio in the dunes.
Task vs issue in agile methodology: tasks are work, issues are obstacles
A task is planned work that produces something. An issue is an unplanned obstacle. Most project management tools collapse them into the same object, and that's the cause of every messy backlog.
The graph, not the list
A tour of the prerequisite model that makes Tree feel different from kanban: how nodes unlock other nodes, and why fog of war reveals more than it hides.
Why our roadmap is a tech tree
We render the public roadmap as an interactive graph instead of a list because that's what shipping software actually looks like. Showing it that way changed what we chose to build first.
Why "blocked" is the wrong word
When a task can't proceed because a prerequisite isn't done, project tools call it 'blocked.' The word is wrong, and the wrongness shapes how teams think about dependent work. The right word is 'locked,' and the difference reorganises how teams report status.
Why we built Tree
Every project management tool we'd used treated work like a list. The list got long. The dependencies got buried. The roadmap drifted. The team kept rediscovering the same blockers a month after they should have been visible. We assumed this was just what project tools felt like.
How to scope a project you've never built before
Most teams scope projects as docs and ticket lists, then discover the structural problems mid-sprint. A four-step graph-first scoping process preserves the dependencies and branches the list format throws away.
Why your roadmap is decaying
You can date a Notion-based roadmap by looking at it for ten seconds. The decay is structural. It's not a process problem or a discipline problem or a tool-choice problem. The standard fixes don't fix it.
Build notes #1: what we got right and wrong in the first month
First in an irregular series of build notes. What we got right (brand-first, voice spec, the public roadmap as a planning artifact), what we got wrong (underestimating marketing scope, email infrastructure timing), and the open questions we're still working through.
The features we deliberately won't build
Most product roadmaps grow by accretion until the product is buried under a decade of feature requests. Tree's roadmap has a list of refusals. No custom workflows, no marketplace, no AI assistant, no mobile-first design, no infinite hierarchy, no 'for everyone'. Here's why each one stays off.
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.
What a critical path actually tells you (and what it doesn't)
Critical path analysis gets used as a priority ranker. It isn't one. Here's what the analysis actually tells you (minimum schedule, slippage impact, parallelism opportunity), what it doesn't (risk, value, people, quality), and why software teams misuse it more than any other industry.
The cost of self-hosting
Tree's pricing model is rare in modern SaaS: free for personal, cheap for teams, one-time license for self-hosting. Why we rejected each of the four standard alternatives and the costs we accepted for the model we picked.
The unbundling of project management
The all-in-one project tool emerged from a real problem in 2008. By 2018, three things broke that thesis. Modern teams ship faster across six specialist tools than across one bundle. Tree fits in a slot the bundles never recognized.
Dependencies are not metadata
Most project tools store dependencies as fields hung on a task. A few store them as edges in a graph. The architectural choice determines what the tool can do, what queries it can answer, and which features fall out for free.
What strategy games taught us about project planning
Civilization V, Stellaris, Factorio, and Slay the Spire solved the same progression-UX problem project tools punted on. Here's what we took from strategy games when we built Tree, and where the pattern import deliberately stops.
The pre-mortem, but as a tree
The standard pre-mortem produces a list of risks that gets ignored by week three. A tree-shaped pre-mortem treats risks as first-class graph nodes, attached to the work they threaten, with mitigations planted as new upstream tasks. The risks stay alive because they're part of the project, not a separate document.