There is a category of software bug that users blame themselves for. You hit the wrong key, a note disappears, and your first thought is not "this app should have handled that" — it is "I should have been more careful."
You should not have to be more careful. A note-taking app is where you put things precisely so that you can stop holding them in your head, and an app that occasionally eats one has broken the only promise it made.
Notez has four separate recovery mechanisms. They are not redundant. Each covers a failure the others cannot, on a different timescale.
Layer one: undo, for the last few seconds
⌘Z is the layer you use without thinking, and it covers five specific things:
Deletes — you moved a note to the Bin
Card moves — you dragged a card to a different board column
Property changes — you set or cleared a custom property value
Quick captures — you captured something and immediately regretted it
Reminder moves — you dragged a reminder to another day on the calendar
The stack holds twenty actions. Each entry stores exactly what is needed to reverse the operation — for a card move, the column and the position it came from, including whether it came from the uncategorized pile.
Three details in how it behaves are deliberate:
Deletes and captures show a toast; card moves do not. A toast for every drag would make a board-heavy session unusable. Moves are still undoable; they just do not announce themselves.
A property change that changed nothing is not recorded. Opening a select and picking the value it already had does not consume an undo slot, because burning a slot on a non-event means the thing you actually wanted to undo has quietly fallen off the end of the stack.
Capture toasts carry two actions, Undo and Open. The most common thing you want after capturing is not to reverse it — it is to go look at it.
The important limit: the undo stack lives in your browser session. Reload the page and it is empty. It is a fast path for the mistake you just made, not a durable history. That is what the next two layers are.
Layer two: version history, for the last thirty days
Every note keeps its own revision history, retained for thirty days.
Snapshots are taken on save, but not on every save — at most one every five minutes. An edit by AI chat or a connected assistant is the exception: it always saves a snapshot of the note as it was before. The reason is arithmetic. An editor that autosaves while you type would otherwise produce hundreds of near-identical versions for a single afternoon's writing, and a version list with four hundred entries is not a history you can use. Five-minute granularity gives you a list you can actually read.
Each snapshot carries the note's tags along with its content. This matters when restoring: bringing back last Tuesday's version brings back last Tuesday's tags too, rather than restoring old prose into a note whose classification has silently moved on.
Version history is the layer for the failure undo cannot reach: not "I just did something wrong" but "at some point in the last two weeks this note got worse and I do not know when." You preview versions and restore the one you want.
Layer three: the Bin, for the last thirty days of deletions
Deleting a note does not delete it. It marks it deleted and stamps the time, and it stays that way for thirty days, browsable and restorable.
The interesting part is what happens with sub-notes.
Deleting a note deletes its whole subtree. Delete a project note and every note nested under it goes too. This is the only sane behaviour — a child note left behind with no parent is a leak, not a rescue.
Restoring is more careful than deleting. When you restore a note, its descendants come back too — but only the ones whose deletion timestamp exactly matches its own. That is the fingerprint of "deleted as part of this same cascade."
Consider what the naive version would do. Say you deleted one obsolete meeting note in March. In August you delete the whole project, then change your mind and restore it. A naive restore brings the entire subtree back, including the March note you deliberately threw away five months ago. You would have to find it and delete it again — assuming you noticed at all.
Matching on the deletion timestamp means a restore undoes exactly one deletion event and leaves every earlier decision alone.
Layer four: the write that gets refused
The first three layers recover from your mistakes. The fourth exists because a workspace can have more than one person in it, and the failure mode there is different: nobody makes a mistake, and work vanishes anyway.
Two people open the same note. Both edit. Both save. Whoever saves second overwrites the first — with no error, no warning, and no trace that the other version ever existed. The first writer finds out days later, if ever.
Notez refuses that write instead.
Every note carries a content version counter that increments on each content save. When your editor saves, it sends the version it started from. If the note has moved on since, the save is rejected with a conflict rather than applied, and you are told the note changed elsewhere and to reload before continuing.
The check runs twice — once against the note as read, and again as a condition on the update itself. That is not belt-and-braces paranoia: between reading a row and writing it there is a real window in which someone else's save can land, and only the guard on the write closes it.
You lose the few seconds since you last saved. You do not lose the other person's afternoon.
This is the deliberate alternative to real-time co-editing. Merging two concurrent edits to rich text automatically is possible, and it is also how you end up with a paragraph that neither author wrote. Refusing the second write is blunt, but it is always comprehensible: one of you reloads, and both versions still exist.
How the layers divide the work
Timescale | Mechanism | Survives a reload? |
|---|---|---|
Seconds |
| No |
Minutes to 30 days | Version history, 5-minute snapshots | Yes |
Up to 30 days | The Bin, with cascade-aware restore | Yes |
Immediately | Save conflict guard | Yes |
The honest gaps, so you know where the edges are:
Undo is per session. Close the tab and it is gone.
Version history and the Bin both stop at thirty days. Neither is a backup archive.
Undo does not cover note content edits — that is what version history is for.
There is no offline editing, so there is no offline conflict to resolve.
What this is really about
None of these four are difficult features. Undo stacks, soft deletes, snapshot tables, and version counters are well-understood engineering.
They get skipped anyway, because each one only pays off on the day something goes wrong, and on every other day it is invisible. The result is a whole category of note apps that work beautifully in a demo and lose an afternoon of someone's work in month four.
The point of writing something down is to stop carrying it. That only works if you can stop worrying about it too.
Continue reading
Sharing without the merge conflict — why a shared workspace refuses the second of two conflicting saves instead of merging them.
The cleanup job that would have deleted your avatar — how a daily job that deletes unattached files nearly removed workspace avatars that were in use.
Notez: A Note-Taking App Built for Developers — what Notez is, the ways a note gets in, and what each plan includes.