Anatomy
┌───────────────────────────────────────────────┐
│ Job notes Saved 14:32 ✓ │ ← one fixed place,
│ ┌───────────────────────────────────────────┐ │ always says something
│ │ Site access is via the rear gate… │ │
│ └───────────────────────────────────────────┘ │
└───────────────────────────────────────────────┘
states: idle → "Saving…" → "Saved 14:32"
↘ "Couldn't save — retrying" (text kept)
- A single, permanent status location. It must never be blank; "Saved 14:32" when nothing is happening is part of the pattern, because absence of a message is indistinguishable from a failure.
- Debounce, then commit on blur. Per-keystroke saving is expensive and produces a useless version history.
- Never touch the field being edited. The most damaging autosave bug is a save response that re-renders and eats a cursor or three characters.
Why it works
It deletes an entire category of user obligation. With explicit save, durability is a task the person must perform; with autosave it is a property of the system. Everything that used to hang off that obligation — the guard dialog, the beforeunload handler, the "you have unsaved changes" state — stops being needed.
The status indicator is what makes it trustworthy rather than merely convenient. People will not stop worrying about saving because you removed the button; they stop because the screen tells them, continuously, that it is handled.
What it costs you
Autosave is not free. It buys durability by taking on three obligations that explicit save did not have:
- Version history. Continuous saving means there is no "before". Without history, autosave converts "I forgot to save" into "I overwrote it", which is worse because it is silent.
- Conflict handling. Two people editing one record, both saving constantly, produces a last-write-wins race that neither of them can see.
- Honest failure. A failed save must be visible and must not lose the text. A silent failure with a green indicator is the worst possible outcome — the person has been told their work is safe when it is not.
If you cannot take on those three, explicit save with a guard is the more honest design.
Getting it wrong
- Saving on every keystroke, which floods the server and makes history useless.
- Re-rendering the active field on save, eating the cursor or characters.
- A blank status area when idle, so silence means both "fine" and "broken".
- Autosaving something with side effects. A half-typed email subject that sends, a booking that provisionally holds a slot — this is the failure that actually hurts customers.
- No version history, so the record has exactly one state, forever, and it is whatever was last typed.
Exemplars
Google Docs is the canonical implementation and, importantly, ships all three obligations: continuous status, full version history, and real-time conflict resolution. It is a good reminder that the visible part of autosave is the smallest part.
Notion shows the pattern applied per block, which keeps the save unit small and the conflict surface narrow.
Linear's issue description demonstrates the boundary well — the description autosaves, but the state transitions that notify people are explicit actions. Composition autosaves; consequences do not.
The extractable rule: autosave what is composed, and require an explicit action for anything that has consequences. The distinction is not the field type, it is whether saving does something a person cannot take back.