Notez has no folders. This is the design decision people ask about most, so let us make the case.
A folder forces one question at filing time — where does this go? — and then punishes you for answering it wrong. A meeting note about pricing for the mobile launch belongs in Meetings, Pricing, Mobile, and Q3. A folder makes you pick one. So you either pick badly, or you build a nested hierarchy that only made sense on the day you built it.
Notez replaces that one rigid dimension with four overlapping ones.
Tags
Tags are the workhorse. Colored, managed from the sidebar, renameable and deletable, and a note can have as many as it needs.
Under the hood a tag is a built-in multi-select property named Tags. That is not trivia — it means tags participate in the same filtering and sorting machinery as everything else.
Nesting
Any note can have sub-notes, to any depth. Open a note and there is a Child notes section with Add sub-note; breadcrumbs show you the path back up.
This is where genuine hierarchy belongs — a project with its meetings, a book with its chapters. The difference from folders is that nesting is a property of a note, not a container it lives inside. The parent note holds actual content, not just a directory listing.
Boards
Any set of notes can be viewed as a kanban board. Columns come from a built-in Board select property, and switching to Board view gives you drag-and-drop cards, quick-add per column, and featured images on cards.
Boards follow the tree: top-level notes use the workspace board, and child notes use their parent's. A project note automatically gets its own board made of its sub-notes. There is no separate "make this a board" step.
Moved a card by accident? ⌘Z.
Custom properties
This is the layer that turns notes into something closer to a database. Eleven property types:
Type | Description |
|---|---|
Text | A single line of text |
Number | A numeric value |
Date | A calendar date |
Checkbox | A yes / no checkbox |
URL | A web link |
An email address | |
Phone | A phone number |
Select | One choice from a list of options |
Multi-select | Multiple choices from a list |
Relation | Links to other notes |
Member | One or more people in the workspace |
Properties are workspace-scoped, so a Status property defined once is available on every note in that workspace. Select and multi-select options carry colors and their own ordering.
Relation deserves a callout: it links notes to other notes as structured data. A Client property on every meeting note, pointing at the client's note, gives you something a tag cannot — a real reference you can filter on and follow.
Tags and Board are built-in properties and cannot be deleted, which is why they behave consistently everywhere.
Filtering and views
Organization is only worth the effort if retrieval pays it back.
Combine up to 10 property filters at once, ANDed together
Operators include text-contains, number ranges, and date ranges
Filter by tags or the Bin; AI chat and MCP assistants also filter by note type, favorites and top-level notes
Sort by created date, updated date, title, or any custom property
Three views — Table (with a column picker), Grid, and Board
Your sort and filters live in the URL, so you can bookmark or share a particular slice of your workspace with yourself. The view you pick is remembered per workspace and per note, in this browser.
One honest gap: there are no saved views. Filters live in the URL, and there is no named-view feature yet.
Favorites and the Bin
Favorites get their own sidebar section: star a note in its header, or choose Add to favorites in a card's menu. The Bin holds deleted notes for 30 days; Delete in a card's menu moves a note there, and ⌘Z brings it straight back.
Workspaces
Above all of this sit workspaces. Each has its own notes, tags, properties, boards, AI conversations, and API keys. Work and personal stay separate for AI chat and for an MCP key: a key bound to one workspace cannot see another. A connection made by signing in from Claude, ChatGPT or VS Code reaches every workspace you belong to.
Since v0.3.0 a workspace can also hold more than one person: the owner invites members by email, and everyone in it shares the same notes, tags, properties, and boards. Each workspace has its own avatar and settings tab, so several shared workspaces stay distinguishable at a glance.
What sharing deliberately does not add is a second organizational dimension. There are no per-note permissions, no private notes inside a shared workspace, and no folders-by-person. The workspace is the unit of access, which is the same boundary the AI and MCP keys already respect.
How to actually start
Do not build a system on day one. It will be wrong.
Capture everything with no organization at all.
When one kind of note recurs, add a tag.
When you need to track state, add a select property and switch to Board view.
When you need structured data — dates, clients, statuses — add properties for it.
The structure should be discovered from what you actually write, not designed in advance. That is the real argument against folders: they demand the schema up front, before you know anything.
Continue reading
How to Use Backlinks to Connect Your Notes — why a link beats a folder for a note that belongs in three places, and how a hub note collects its backlinks.
Every property, one click away — a select, member or relation property becomes a sidebar section that filters the list in one click.
The list you lose every time you open a note — a note opens in a side panel over the list, so the scroll position and filters stay where they were.