A simpler alternative to Tana: when supertags are too much

If you use Tana’s supertags, fields, and search nodes to run a personal database, keep using Tana. A simpler outliner will remove the part of the system that makes it valuable. But if you opened Tana because you wanted a better place for notes and tasks, then found yourself naming fields before you could capture a thought, listlis is a better fit.

Tana Outliner is built for structured information. A node can become a typed thing with fields, defaults, views, and searches. That is a strong model for a client list, a content pipeline, or a project portfolio with the same facts on every record. It is also more system than many outlines need.

listlis starts with a narrower promise: one keyboard-driven tree for tasks, notes, and ideas. Add a line. Nest it. Add a Markdown body when it needs more room. Mark it done when the work is over. The structure stays visible, and it does not ask you to classify every thought on the way in.

The decision is about structure

Tana’s supertags turn a node into a reusable type. A #Project node can carry fields for status, owner, deadline, and priority. A #Person node can carry contact details. Search nodes pull those typed records into a view, where they can be filtered and sorted.

That pays off when the same questions come up again and again. Which client has no next step? Which projects are blocked? Which articles need an editor? Fields make those answers consistent because the information was entered in a consistent shape.

The cost arrives earlier. Before a note can become useful, you may need to decide what it is, which supertag belongs on it, and which fields deserve values. That discipline is right for a system of records. It can interrupt rough capture, planning, and ordinary list-making.

There is no prize for turning a grocery list, a meeting note, and a half-formed project idea into database rows. If the work changes shape while you think, a plain hierarchy gives it room to change.

If your work needs	Better fit	Why
Reusable record types, custom fields, and filtered database views	Tana	Its supertags and search nodes are the point
A tree for active projects, notes, and tasks	listlis	The outline stays the working surface
A backlink-heavy knowledge graph	Tana or another PKM tool	listlis is deliberately tree-first
Fast capture before you know how an idea should be categorized	listlis	A line can stay a line until it needs more

Tana is worth the setup when records are the work

Tana is the right choice when you want to build a model and live in it. A consultant tracking people, companies, calls, and follow-ups can give each kind of thing its own fields, then use searches to see work from several angles. A research system can attach sources, themes, and dates to a note, then bring matching material back together later.

That structure is not busywork when it answers questions you could not answer otherwise. If a project is only useful after it has a status, owner, and due date, making those fields explicit is a feature. If you spend time building views and actually return to them, Tana is doing its job.

Stay with Tana if any of these sound familiar:

• You rely on supertags to make recurring kinds of information consistent.
• You use search nodes or table views to review work across your workspace.
• You want an AI-assisted meeting and workflow system alongside your notes.
• You enjoy refining a system and get a real return from the structure.

The test is simple. Think of the last useful thing you found in Tana. If you found it through a field, a search, or a view, the extra machinery is earning its place.

An outline can be enough structure

listlis does not try to copy Tana’s custom fields, supertags, or database views. A node has a title and an optional Markdown body. That limitation is intentional. It leaves the outline free to become a plan, a task list, a note, or a sketch of an idea without changing types.

Here is a small example. Start a root called “Website refresh.” Add the pages beneath it. Nest the work for each page below that. Put meeting notes in the Markdown body of the relevant line. Turn the next action into a todo with !, and press c when it is done. When every child is finished, completion rolls up through the branch.

That is enough to run a lot of real work. The project is visible as one shape: its goals, notes, tasks, and loose ends stay together instead of becoming records in separate views. When a task needs a date, listlis has due dates, recurring items, and smart lists for time-based work. When you need to find a phrase, / searches titles and bodies.

The interaction stays close to the idea. Press o to add a sibling, Tab to nest it under the line above, and Shift-Tab to bring it back out. Reorder a whole branch without reaching for the mouse. A fast outline stays useful when the work gets messy.

A useful boundary before you move

listlis is not a Tana replacement for people whose work depends on structured records. It has no supertag template that makes every project carry the same custom fields. It does not provide a general database view for arbitrary note types, and it does not replace a backlink-driven graph. Moving a carefully built Tana system into a plain outline would trade away the reason you built it.

The inverse is also true. If your Tana workspace contains mostly daily notes, task lists, project outlines, and a few fields you rarely filter on, you may be carrying a system designed for a harder problem. The most useful part of the workspace might be its tree.

Try one live project rather than migrating your archive. listlis imports OPML and Markdown outlines, so a small branch is enough to test the working rhythm. Keep Tana open. Capture the next week’s tasks in listlis, add notes under the tasks they belong to, and see whether you miss the fields in the moment. A week of real use settles this more clearly than a feature chart.

The middle ground: a tree your assistant can read

Some people choose Tana because they want their notes to become useful again later. They want to ask what is open, gather everything about a client, or turn a meeting into the next actions. That need is real. It does not require a chatbot embedded beside every line.

listlis exposes its tree through an MCP server. A connected assistant can search the outline, pull a topic into a bounded Markdown bundle, answer what is due, and create or rearrange subtrees. The assistant works with the same tree you use from the keyboard. There is no second copy of your notes to maintain.

That is a different trade from Tana’s AI workflow model. Tana is built to add AI, fields, and views inside the workspace. listlis keeps the workspace small and lets the assistant you already use work with the outline when you choose. Pick the model that matches your habits.

If you want a less structured outliner without losing the ability to grow, open a root in listlis and start with one project. The outliner comparison hub has the wider map, and the Dynalist alternative guide covers the closest keyboard-first path from another direction.