One tree to rule them all: the resource model

Folders, docs, tables, projects, and chats — all as resources in a single nested tree. Why we unified the model instead of building per-type silos.

One tree to rule them all: the resource model

Most productivity apps have separate silos: a documents section, a tasks section, a database section. You navigate between them with a top-level nav. They don't talk to each other.

We built a single tree instead.

Everything is a resource

A resource is anything that can live in the sidebar: a folder, a document, a table, a project, a chat. Each resource has a type, a parent, and a set of children. The tree is the navigation.

Why unified?

The alternative — per-type silos — forces you to decide where something lives before you create it. Is this a doc or a project? These decisions don't have right answers. They create artificial friction.

With a unified tree, you put things where they make sense. A project can contain docs, tables, and a chat. A folder can hold anything. The structure emerges from use, not from the app's opinions about categories.

Sync implications

A unified tree simplifies sync. Every resource follows the same sync protocol: create, update, delete, restore. Adding a new resource type means adding a Zod schema and a handler — not a new sync pathway.