Tree is built by a small team in Rotterdam who spend their day jobs at Forge , a digital agency. Tree is a separate product, not a Forge service. The team has been thinking about project tools for years and started building Tree after concluding that the tools we needed didn't exist.

Three reasons. The category has unbundled enough that there's a clear slot for a structural layer. Modern indie tooling (Linear, Figma, Notion, the modern stack) has matured to the point that a sixth specialized tool fits cleanly into the workflow. And the underlying technology (graph databases, modern web rendering, real-time collaboration) is mature enough that a graph-first product is buildable by a small team without requiring enterprise-level infrastructure investment.

Why a tech tree specifically?

Because tech trees solve the UX problem better than any other progression visualization in software. Strategy games have spent thirty-five years refining the pattern. The conventions (locked-but-visible, prerequisite chains, available tier, branching for exploration) generalize cleanly to project work. Other metaphors we considered (Gantt charts, mind maps, flowcharts) each capture some of what Tree captures but miss the planning-as-progression aspect that tech trees handle natively.

What makes Tree different from existing tools with dependency support?

Existing tools treat dependencies as metadata. Tree treats them as edges in a first-class graph. The architectural difference produces a different product: graph algorithms come for free, restructuring is cheap, traversal is symmetric, and the structural information stays visible instead of being buried in fields. We covered this in Dependencies are not metadata .

When will Tree launch?

We don't have a launch date. The roadmap shows what's coming. Pre-launch dates are fiction, especially for indie products with small teams. Joining the waitlist is the right way to find out when the build is ready.

The core is free for personal use. Team plans are paid but cheap. Self-hosted Tree is a one-time license, not a subscription. We covered the pricing logic in The cost of self-hosting .

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.

Then one of us was playing Civilization V on a Sunday afternoon, looking at the tech tree, and noticed that the game had solved a UX problem the project tool on the other monitor hadn't.

This post is about how Tree started, what we ruled out before we built it, and why the metaphor that became the product had been hiding in plain sight for two decades of strategy game design.

The frustration

The team behind Tree spends our day jobs at Forge, a digital agency in Rotterdam. We build software for clients. We use project tools to plan and ship that software. Over the years we've used Linear, Jira, Notion, Asana, Trello, Monday, ClickUp, Plane, GitHub Projects, and a few others we've blocked out.

Each one had moments where it was good. None of them ever felt right.

The problems were specific. Linear's backlog hides the structure of the project. The list view is fast and clean, but you can't see what depends on what without clicking into individual issues. The team would discover dependencies during sprint planning that should have been visible weeks earlier.

Jira's structure is configurable to death. Custom workflows, custom fields, custom transitions, custom permissions. Every team's Jira instance reflects six months of administrative work that doesn't survive the next admin's tenure. The structure exists, but it's locked behind configuration overhead that makes it harder to see than no structure at all.

Notion's roadmaps are beautiful for two weeks and unmaintainable by month three. The flexibility that makes Notion great for docs makes it terrible for structured planning. Field proliferation, view drift, abandoned databases, the standard pattern.

Plane is a faster, cheaper Jira. The same architectural assumptions, just more open and less expensive. Useful for teams whose problem with Jira was the price tag. Not useful for teams whose problem was the model.

We kept trying new tools and kept ending up with the same complaint: none of them showed us the shape of the project. They all showed us a list.

What we ruled out

Before building Tree, we considered three other directions.

Building a Notion template. The first instinct was that the structure could be encoded in a clever Notion database setup. We sketched it. The sketch worked for about two weeks before hitting the same decay pattern every Notion roadmap hits. The architecture wasn't built for the use case. A template can't fix that.

Building a Linear plugin. The second instinct was that we could extend Linear with a dependency visualization layer. Linear has an API. The API supports issue links. We could render the link graph as a visualization on top of Linear's existing data. We started looking at the technical feasibility and found two problems. First, Linear's dependency support is metadata-first, which limits what the visualization could show. Second, building a plugin meant inheriting Linear's product decisions, including the ones we disagreed with. A plugin would have been a workaround, not a solution.

Doing nothing. The third option was to keep using existing tools and stop complaining. This is what most teams do. The tools are good enough. The complaints are universal. Nobody dies because their roadmap decays in week six.

We almost picked option three. Building a project tool from scratch in a category dominated by venture-funded incumbents is not obviously a good business decision. The market is loud. The competition is well-resourced. The buyer is hard to reach.

What changed our minds was realizing the missing tool wasn't a feature gap. It was a category. Nobody was building a graph-first project tool, because the people who would care about graphs were busy building point solutions for execution, docs, and chat. The structural layer was empty, and the empty slot was visible from anywhere on the map.

The moment

The actual moment was a Sunday afternoon. One of us was finishing a Civilization V game while half-watching a planning meeting on the other monitor. The team was debating priorities for the next sprint. The Jira board had thirty-something issues, most of them with unclear blocker relationships. The conversation kept circling: what depends on what, what can we start now, what's actually ready.

The Civ V tech tree was visible in the other window. It had ninety-something nodes. Each node had clear prerequisites. The available techs were highlighted. The locked techs were dimmed but visible. Hovering over any node lit up its dependency chain. Clicking on a far-future node showed the path required to reach it.

The contrast was absurd. The video game had better project visualization than the project management tool.

This wasn't a new observation. Strategy games have done this since at least 1991, when Civilization first shipped. Sid Meier and his team solved the problem of "how do you show a complex progression space to a user planning a path through it" thirty-five years ago. Project tools have been working on the same UX problem for the entire time and have never produced a clean solution.

The gap wasn't a small oversight. It was a category miss. The tradition that produced project tools (spreadsheets, bug trackers, ticket systems) had different assumptions than the tradition that produced strategy games (board games, war games, 4X RPGs). Both traditions converged on the same UX problem from different starting points. Only one of them solved it.

The tech tree was right there. We just needed to apply it to the work that wasn't a game.

Why "Tree"

Once the metaphor clicked, the product fell out of it.

Tasks are nodes. Dependencies are edges. Projects are graphs. The shape is visible the whole way through. Locked nodes are dimmed but visible, the same way locked techs are in Civ V. The available tier is computed continuously, the same way available techs are in any progression game. Branching is structural, the same way it is in Stellaris when you choose between two competing techs.

The mechanics generalized cleanly. The visual conventions generalized cleanly. The mental model generalized cleanly. We weren't designing a new product so much as transposing an existing UX vocabulary into a domain where it had never been applied.

The name followed the same logic. The product is a tree. The metaphor is a tree. The name is "Tree." We considered alternatives (Branch, Forest, Atlas, Vine) and kept circling back to the literal noun. The name and the product became the same object, which seemed honest. We covered the naming process in its own post.

What Tree is for

Tree is for technical teams whose work has dependency structure. Software teams. Some kinds of design teams. Technical PMs. People whose projects look like graphs, even when their tools insist on showing them lists.

Tree is not for teams whose work is naturally list-shaped. Sales pipelines, content calendars, customer support workflows. The graph model would feel forced for those use cases. We're explicit about who Tree is wrong for, because pretending otherwise would mean shipping a worse product to please everyone.

Tree is also not a Linear replacement for teams happy with Linear. The customers we want are the ones whose roadmaps decay in Notion, whose Jira instances make them sad, whose dependency planning happens on whiteboards because nothing else is shaped right. The teams who already have a working stack don't need to switch.

The pitch is simple. If your project work is graph-shaped, Tree is shaped right for it. If it isn't, we won't pretend.

Where we are now

Tree is pre-launch. The marketing site is live. The brand work is done. The roadmap is published. The application is in early development.

We're building toward a product that takes the UX patterns strategy games solved decades ago and applies them to the work that pays the bills. The first interactive tree drops when the build is ready. The roadmap for what's coming is itself a tree, dogfooding the model the product runs on.

If you've ever finished a strategy game session and thought "why doesn't my project tool work like this," the answer is that nobody made one until now.

Join the waitlist if you want the launch.