Ninety-five per cent. Not notes, not tasks, not a year of habit ticks. Eighty copied images, averaging 521 KB each, the largest of them 5 MB.

The number that actually frightened me came after: the history limit counts rows. Five hundred rows against a 6 MB per-image cap is about three gigabytes, and nothing in the design said otherwise. Nobody had hit it yet. Somebody would.

A row limit does not bound bytes

This is the whole bug in one sentence, and it is an easy one to write.

"Keep the last 500 clipboard entries" is a completely reasonable rule when you picture a clipboard entry — a URL, a paragraph, a command you copied out of a terminal. Kilobytes. Five hundred of those is a rounding error.

Then you support images, because a clipboard manager that forgets your screenshots is not much of a clipboard manager. And on a Retina Mac an ordinary full-screen grab is 2880×1800. The unit of the limit and the unit of the cost have quietly stopped being the same thing, and every subsequent decision inherits that.

What made it invisible is that the app worked fine. Nothing was slow in a way anyone would report, nothing crashed, no user wrote in. The database was just steadily becoming a screenshot archive nobody asked for, on machines I would never see, because there is no telemetry in this app to tell me otherwise. It surfaced because I went and looked at a real file. That is not a repeatable process, and it is most of the reason I now open one on purpose every few weeks.

The same decision, costing twice

Storage was the visible half. The popup was paying for it too.

Full-resolution image data lived in the same column as text content, base64-encoded. Listing the history selected that column. The popup then drew 36-pixel-tall thumbnails out of it.

Roughly 12 MB crossing the bridge between the Rust side and the interface to paint one screenful of a list — and decoded at full resolution on the other side to be drawn a tenth of an inch tall.

Both problems have the same root: one representation of an image, at full fidelity, used for every purpose. Storing it, listing it, previewing it and pasting it are four jobs with wildly different fidelity requirements, and they were all being served by the largest possible answer.

What replaced it

Every image gets a thumbnail, about 384 pixels, stored beside the original. The list reads only that. Paste and the hover preview fetch the full row by id at the moment they actually need the pixels — which is the moment a user has chosen one specific entry, rather than the moment they opened a list of forty.

A byte budget, not a row count. CLIP_IMAGE_BUDGET caps what the full-resolution copies may occupy between them. Past the cap, the oldest images give up their full-resolution data and keep their thumbnail. That is the part I am happiest with, because of what it does not do: an old screenshot does not disappear. It still appears in the list, and it still pastes. It pastes the thumbnail rather than the original, so it is no longer pixel-exact — a degradation, honestly, but an enormously better one than a gap where your screenshot used to be.

A rule that saved every existing user's history. Rows stored before this change have no thumbnail, and cannot be given one after the fact from the Rust side. Without a special case, the first trim would have looked at those rows, seen an image over budget, dropped the full-resolution data, and left nothing at all — destroying every image already in every user's history, in the update that was meant to fix image handling.

So: a row whose thumbnail is NULL is never emptied, whatever the budget says. Those images keep their pixels until the popup gets around to backfilling a thumbnail for them.

I did not spot that from reading. I spotted it writing out what the trim would do to a row that predates the column, which is a habit worth having whenever a migration adds something that later code assumes is present. Migration 26 in the schema is that column; the NULL rule is the thing that made shipping it safe.

And a check where I had assumed. Thumbnails encode as WebP, which is dramatically smaller — but only where the webview can genuinely encode WebP. The awkward part is that toDataURL does not fail when it cannot; it hands you back a PNG and says nothing. So the app verifies what it actually got rather than trusting what it asked for, and falls back to JPEG where WebP is unavailable. An API that silently substitutes something else is the most expensive kind to trust.

The one that got away for a while

Related, and found the same week: pasting a screenshot into a note took four seconds.

All of it was one call. Handing an image object across the bridge takes a JSON path, and the encoder ran a conversion once per element — 14.7 million calls for a single screenshot. Isolated, the same serialisation was 43ms without that step and 2,672ms with it. It was never bandwidth. The Rust side, at 243ms, was never the bottleneck either.

Sending the PNG bytes and letting Rust decode them removed the JavaScript decode, a canvas round trip and a full pixel copy along with it. A 2560×1440 paste went from 3,151ms to 256ms. On a Retina Mac the four-second case was the common one, because a full-screen grab is exactly that size.

Correctness got checked at the byte level rather than by eye: a known image round-tripped through the pasteboard came back pixel-identical, and the pasteboard was dumped from outside the app to confirm that what any other application receives on ⌘V is a valid, complete PNG. Looking right is not the same as being right, particularly with images, where an off-by-one in a stride produces something that looks perfect and is subtly wrong.

What I would tell the version of me who wrote the original

State the limit in the unit of the cost. If what you are protecting is disk, the limit is bytes. A row count is a proxy that holds exactly until one row can be a thousand times bigger than another, which — for anything touching user-supplied media — is immediately.

Degrade instead of deleting. The budget could have dropped whole entries. Keeping a lower-fidelity version means the history stays complete and the user never encounters an unexplained hole. People forgive fuzzy. Nobody forgives missing.

Check what an API gave you, not what you asked for. WebP that is silently a PNG. A from_bytes call that returns a stub because a build feature was not enabled. Both were caught by verifying the result; neither would have failed loudly on its own.

All of this shipped in 1.0.3, where the public note says the clipboard takes up far less space and its list opens faster when it holds screenshots. Both true. The clipboard manager page covers what it does; when a free clipboard manager stops being enough covers why you would want unlimited history in the first place — a promise that is only honest if somebody has done this arithmetic.

Four times per launch.

None of that was a mystery once I looked, and looking was the entire trick. What follows is six problems found in one sitting, all of them measured rather than suspected, several of them in code I had written and read a dozen times without noticing anything wrong.

The sidebar

The list query was SELECT *.

Every row therefore carried its whole rich-text document — the full note, as JSON — across the bridge from the database to the interface, where it was parsed into an object and thrown away, because a sidebar row needs a title and a short snippet. Then, for each note, a second query fetched that note's tags. Hence 10,001 statements: one list, ten thousand tag lookups.

The fix has nothing clever in it. Select the four columns a list row actually needs. Let SQLite cut the snippet, rather than shipping 8 KB of document to take 60 characters off the front. Read a code note's file path with json_extract instead of parsing the entire document in JavaScript to reach one field. Fetch every note's tags in one grouped query instead of ten thousand.

Same database: 2 statements, 1.4 MB, and 527ms became 47ms.

Backlinks got the same treatment, because that one runs on every note open rather than at launch, and was doing the same thing for the same reason.

The idle costs

The sidebar at least happened when something happened. These four ran while the app sat there doing nothing.

The reminder sweep read everything, every 30 seconds. Every to-do and every calendar event, in full, twice a minute, forever, to find out whether anything was due. On the test database — 767 events — that is 1.18 GB a day of reading to almost always learn that the answer is no. It asks for armed rows only now: the ones with a reminder set, in the window. Ninety-nine per cent of that traffic was learning nothing.

The clipboard poll read the clipboard twice a second. Including, if an image was on the pasteboard, a full owned RGBA copy of it. Every half second. Forever. macOS offers NSPasteboard.changeCount — a single integer that increments when the contents change. The poll reads the integer and touches the actual contents only when it moves. A copied screenshot now costs something once, when you copy it, instead of 172,800 times a day.

The status bar split the entire note into words on every keystroke. Word count. On a long document, on every character typed. That is the sort of thing that feels free in a small test note and turns a 5,000-word document into a typing experience people describe as "laggy" without being able to say why.

And the editor re-rendered on any state change at all, because it subscribed to the whole state store rather than the parts it uses. Toggle a setting in a modal on the other side of the app and the heaviest subtree in the application rebuilt itself.

Two more, in the writing path

Saving a note deleted and rewrote its links every time. Every debounced save issued a DELETE plus one INSERT per link — to usually change nothing at all, because the links in a note are stable across most keystrokes. Compare first, write only on a difference.

And startup re-read and re-rendered the entire tree after a housekeeping pass that had deleted nothing. The pass was correct; the unconditional refresh after it was not. If nothing changed, nothing needs redrawing.

The indexes, and the one I did not add

Three indexes went in for lookups whose column was not the leading column of any existing key: note nesting, tag lookups, backlink targets. The nesting one took a query from 7.1ms to 0.007ms.

A fourth looked equally obvious — an index covering the sidebar's own list query — and it was a trap. That query already had a plan SQLite was happy with, and the index would have cost a write on every single save in exchange for a read that was no longer slow. It is not there, and the migration says why, with numbers, because in six months I will look at that query and think the same obvious thought again.

What actually generalises

The bottleneck was never where I thought. I would have guessed rendering — long lists, virtualisation, React. Every one of these was data access: how much was read, how often, and how much of it was thrown away on arrival. Not one of the six was fixed by making the drawing faster.

"It feels fine" means your test data is too small. Every one of these was invisible on the 40-note database I develop against and obvious on a 10,000-note one. Generating a large database and running against it occasionally is the cheapest performance tool there is, and I had not been doing it. Why a notes app should open instantly is the promise; a realistic test database is what makes it true for someone with eight years of notes rather than eight.

Idle cost is invisible and adds up. Nobody files a bug that says "your app read 1.18 GB today while I wasn't using it". They notice their battery, blame something else, and quit the app that happened to be open. A poll that reads one integer instead of copying an image is not a clever optimisation — it is the difference between a menu-bar app that costs nothing and one that quietly costs you an hour of battery.

Measure in the running app, not in a benchmark. The image-paste problem in the clipboard work looked like bandwidth right up until it was isolated and turned out to be a serialisation step costing 2,672ms against 43ms. Anything you believe about where the time goes, without a number beside it, is a guess with good posture.

None of this appears in a changelog. The public note for the release that carried it says "bug fixes and improvements", because the notes are deliberately vague and nobody outside can see any of it directly. What they can see is an app that opens in well under a second on a database with ten years in it, which was the entire point.

Here is how, because the shape of the mistake is more useful than the mistake.

The design that was wrong

Picking an entry did two things. It put the content on the system pasteboard, then it synthesised a ⌘V keystroke — posted to the system, delivered to whatever application happened to be frontmost at that instant.

The assumption baked into that second step: whatever is frontmost is the app the popup opened over. Usually true. It is the app you were in a moment ago, and the popup is a floating panel that deliberately does not take over.

Usually. A mouse click on the popup could hand Cyanote the foreground first, and then the keystroke went to Cyanote — which pasted the entry into whichever note happened to be open. Keyboard selection mostly won the race. Mouse selection sometimes lost it.

Read that back with the contents of a clipboard history in mind. The entries most worth protecting are exactly the ones you copy and paste immediately: a password out of a manager, an API key, a card number. The failure landed those in a document, silently, in the app that had just promised to be careful with them.

Nobody reported it. I found it while chasing something else, which is the ordinary way these are found, and is an argument for reading your own code paths on purpose rather than waiting.

Guarding versus making it impossible

The obvious fix is a guard. Before posting the keystroke, check whether Cyanote is frontmost; if it is, bail out or restore the other app first and try again.

I had guards. That is what the original design needed to work at all, and one of them had started refusing a legitimate case — pasting into Cyanote itself, which is a completely reasonable thing to want. The guards were accumulating, each one narrowing a broadcast that was wrong in principle.

Broadcasting a keystroke to "whoever is in front" is a message with no addressee. Every guard is an attempt to reason about who might receive it, from a process that cannot actually know.

CGEvent::post_to_pid takes an addressee. The event goes to one named process, whatever is in front.

So the popup now captures the process id of the app that was active at the moment it opened, and the paste is delivered to that pid. Where a paste lands stops being a race and becomes a value recorded up front. The wrong-app paste is not guarded against; it is unrepresentable — there is no longer a code path that can express "send this to whoever is in front", so no future refactor can reintroduce it by accident. The guards came out with it, and pasting into Cyanote works again, because it is now just another pid.

What fell out of the Accessibility grant

Synthesising keystrokes on macOS requires the Accessibility permission, and that grant is per-binary — a detail with two consequences the app had never said out loud.

Restoring the foreground needed the same permission, and used to fail with it. The old code asked System Events to bring the previous app forward, which is Apple Events, which needs the very grant that was missing. So on a build without it, the paste failed and the restore failed together, and the popup looked simply broken rather than blocked. NSRunningApplication.activate needs no permission at all and does the same job. Restoring the window you came from is now unconditional.

A paste that cannot happen says so. If the grant is missing, the popup reports it, offers to open the right settings pane, and points out that the entry is on the clipboard already — so you can press ⌘V yourself and get on with your day. Before, it closed and nothing arrived. Silence is the worst possible response to a permission problem, because the user's only theory is that your software is broken. Why a Mac app asks for Accessibility is the longer version of that argument.

And the order of the two final steps matters more than it looks. The foreground is handed back before the popup's panel is ordered out, not after. When a panel goes away, AppKit has to move key status somewhere, and it picks the app's main window — which raises Cyanote in front of whatever you were doing, one beat after you asked it to get out of the way. Restoring first means that reassignment happens inside an app that is no longer active, so nothing is raised. The same ordering fixes Escape: dismissing the popup without picking anything now puts you back where you were too.

That last one took an embarrassing while to see. I kept reading the activation code, because that is where the bug obviously was, and the bug was in a line of window teardown two functions away that I had never once suspected.

What I took from it

The clipboard is the part of the app with the most exposure to the rest of the system — it opens over other applications, reads what they put on the pasteboard, and types into them. Every one of those is a boundary where "usually true" hides.

Two rules came out of it, and they now apply well beyond the clipboard:

If the code can express the wrong outcome, it will eventually produce it. Not through malice or carelessness — through a race, a refactor, or a user doing something reasonable in an order nobody tried. Deleting the expression beats adding a check.

A silent failure at a permission boundary is worse than a loud one. The user cannot see the boundary. If the app does not name it, the app is what looks broken.

All of this shipped in 1.0.4, described in the public notes as pasting "always landing in the app you were working in", which is accurate and considerably less alarming than the paragraph above. The clipboard manager page covers what it does day to day; when a free clipboard manager stops being enough covers why you would want history at all.

On disk, in the version before 1.0.3, the plaintext was sitting right there beside the encrypted copy. Searchable. Showing as the note's own title in the sidebar.

It took two numbers to produce, and they are the most instructive pair in the whole codebase.

500 against 138

Typing in a note does not write to the database on every keystroke. It schedules a write 500 milliseconds later, and each new keystroke pushes that out — an ordinary debounce, in every editor ever built.

The save function decided, at the moment it was scheduled, whether the note was locked. If unlocked, write the plaintext. If locked, encrypt. Sensible-looking code. The decision was captured in a closure, and the closure ran half a second afterwards.

Locking a note took about 138 milliseconds, measured.

So: you type. A write is scheduled for 500ms from now, carrying a captured decision that says this note is unlocked, write it in the clear. At 138ms you finish locking. At 500ms the stale closure runs and does exactly what it was told half a second ago.

The row it left behind: is_locked = 1, a valid encrypted blob, and the plaintext in content_json and content_text beside it. Both true at once.

Why that was worse than it sounds

Plaintext on disk under a lock is bad enough. The full-text index is what made it serious.

Cyanote's search index is kept in step with the notes by triggers. A write to content_text fires the trigger. So the secret was not merely on disk — it was indexed, and a search for a word inside a locked note would find it, without the password, while the note itself still showed the lock gate.

The sidebar draws a note's title from the same text. Whatever you had typed in those last few seconds became the note's visible title.

None of that is subtle once you see it, and none of it was visible from inside the app. The interface was completely honest: the lock was on, the gate appeared, the password was required to open it. Every user-facing signal said the note was protected. The disk disagreed.

The same bug, pointing the other way

Chasing the leak turned up its mirror image, which lost data instead of exposing it.

"Lock now" deleted the in-memory session key synchronously. If a write was already queued, it ran a moment later, found no key, and hit the guard that stops a locked note being written in the clear. The guard worked. The edit was dropped — no toast, no retry, gone.

Unrecoverable, too, and for a deliberate reason: the app keeps an unsaved snapshot to recover from a crash, and that snapshot is withheld for locked notes, because a plaintext recovery file for an encrypted note is the same bug in a different place. The safety mechanism removed the safety net.

So one race leaked the last words you typed, and one lost them. Both from the same root: a decision about lock state made at schedule time and acted on at run time.

The fix, in three parts

Locking cancels the pending write rather than flushing it. This is the part I got wrong in my first attempt. Flushing feels safer — do not lose the edit, write it first, then encrypt. But flushing writes plaintext to disk on the way past, which is precisely the thing being fixed. The newest text is already going into the encrypted blob, because locking reads the live editor content. So the pending write has nothing to contribute and everything to leak. Cancel it.

Ending a session flushes before the key goes. The opposite order, for the opposite reason. Here the note stays locked and the key is being dropped from memory; the queued write can still be encrypted, so let it complete first.

And the write closures now re-read the lock state when they run, instead of trusting the flag they captured. This is the actual fix; the other two are the specific paths. Any decision that can change during a debounce window must be made inside the window, not before it. That one line also covers the case I would never have thought to test: a write queued while the note was locked, running after the lock was removed.

What I actually take from this

Two independent representations of one fact will disagree. is_locked said one thing, the presence of plaintext said another, and nothing in the schema prevented both being true. The lasting fix would be a shape where they cannot both exist — where the encrypted blob and the plaintext columns are not simultaneously expressible. I have that on the list, and I am aware that "check it more carefully" is a weaker answer than "make it impossible", which is the lesson from the clipboard arriving again in a different costume.

A debounce is a promise to act on stale information. Every scheduled callback in a UI carries a snapshot of the world from before the user's most recent action. That is what it is for. Any security decision inside one is a decision made in the past about a present it cannot see.

The interface being right is not evidence. Everything on screen behaved correctly throughout. If I had verified this the way a user would — lock a note, confirm it asks for a password — it passes. It only appears if you look at the row on disk, which is why the check that now guards it queries the database directly and asserts the plaintext columns are empty.

This shipped in 1.0.3, where the public note reads: locking a note now keeps everything you just typed, including the words written in the moments right before you locked it. True, and about a tenth of the story. The changelog is deliberately vague about which code paths were unreliable, which is the right call for a public release page — and the reason a blog exists is so the full version has somewhere to go.

If you use locked notes: this was fixed before the app went on sale, in the 1.0.x series, and the note protection design covers what the lock does and does not claim.

That reads like modesty. It is closer to a budget. Each of those noes is load-bearing, and I would like to go through them one at a time, because "we decided to stay focused" is the kind of thing every product says and almost none of them mean specifically.

Sync

The most requested, by a distance, and the one I am most confident about.

Sync is not a feature you add. It is a distributed systems problem you adopt. The moment two machines can both edit a note, you own conflict resolution, offline queues, partial failures, clock skew, and a class of bug where the wrong version wins and someone's afternoon disappears. Ask anyone who has shipped it. The demo is a weekend; the correctness is years.

And it needs a server, permanently, per user. Go back to the arithmetic of a $10 app: a one-time payment against a recurring per-user cost has exactly one ending, and it is a subscription announcement dressed up as a "sustainability update".

So the no here is not "sync is hard". It is: a synced Cyanote could not be a $10 app you buy once, and if I have to choose between those two things, the pricing is the part people cannot get elsewhere.

What exists instead: the database is a single file, and Settings will put it wherever you like — including a folder that Dropbox or iCloud Drive already syncs. That works if you are careful about not running both Macs at once, and I say so plainly rather than pretending it is a feature. Two Macs, one system is the honest guide to the trade-offs.

An iPhone app

The second most requested, and the answer is arithmetic again, of a different kind.

A native iOS app is a second codebase. Not a port — a different interface, different interaction model, a review process with its own timeline, and a permanent doubling of every future change. One person maintaining two platforms ships each of them half as well.

There is a worse version of this that I want to name, because it is the trap. A mobile app that is useful needs to see your notes, which means it needs sync, which means the server, which means the subscription. The iPhone request and the sync request are the same request, and answering it turns Cyanote into a different company.

If you need your notes in your pocket, Cyanote is the wrong app, and I would rather you learn that from a blog post than from a refund form. Getting a note to your phone without sync covers what actually works when it is occasional rather than constant.

Collaboration

Shared notes need identity: who are you, what may you see, who changed this. Identity means accounts. Accounts mean a user database, a password reset flow, a breach surface, and a server that has to be up for you to open your own notes.

Cyanote has no account because it has nothing to sign into, and that is the single strongest privacy property it has — not a policy, an absence. What an account actually buys you goes through what disappears along with it.

It is a desktop app for one person on their own machine. If two people need the same document, use something built for that; there are good ones, and this is not one of them.

AI features

The interesting no, because I do not think AI in a notes app is stupid. Summarising a long meeting note is genuinely useful.

The problem is the direction the data flows. Any model worth using runs on someone else's hardware, which means your notes leave your machine to be useful. The app's whole promise is that they do not. You cannot hold both. "We only send the note you asked about, and we don't train on it" is a policy — revocable, unverifiable from where you sit, and a completely different kind of assurance from the app makes one network request ever, and it is a version check.

A local model would keep the promise, and someday that may be genuinely good enough on ordinary hardware for a specific job. It is not a no forever. It is a no while the honest version of the feature is "your notes get uploaded". AI features and private notes has the longer argument.

Plugins

Plugins look free. Other people write the features, users get what they want, nobody is asking me for a Kanban swimlane.

What a plugin API actually does is turn your internals into a public contract. Every table shape, every state store, every editor node that a plugin can reach is now something you may not change without breaking somebody's setup. Cyanote has 26 shipped database migrations and I have edited the data model on a dozen ordinary afternoons. That freedom is what has kept it moving. A plugin ecosystem trades it away permanently, at exactly the stage when I still get the shape wrong regularly.

There is also the security half: a plugin runs inside an app holding an unencrypted clipboard history. "Install this handy extension" is not a sentence I want anywhere near that.

Themes were the compromise, and the right one. Fifteen built in, plus an editor for the seven colours the whole app is drawn from — real customisation, no API surface, nothing executing.

Telemetry

No analytics, no crash reporting, no "anonymous usage statistics to help us improve".

This one costs me the most, and I want to be straight about it rather than noble. I have no idea which features get used. I do not know how many notes a typical database holds, whether anybody opens the board view, or which of the fifteen themes is anyone's favourite. Every product decision is made without the data that every other product team considers a baseline.

I took that trade because a searchable index of everything you copy sits in this app, and "we collect anonymous usage data" is where the erosion always begins. Not with a scandal. With a reasonable-sounding paragraph in a privacy policy, then a slightly wider one.

The replacement is worse and slower: people email me. That is a biased sample, it is a fraction of a percent of users, and it is what I have. Support for an app with no accounts covers what that is actually like.

What the noes cost

Every one of these loses sales. Sync and mobile lose the most, and they lose them silently — people read the page, see what is missing, and close the tab, and I never learn their names.

What is left is an app that opens instantly, works with the wifi off, keeps everything in one file you can copy to a USB stick, and costs $10 once. Those four properties are downstream of the six noes. Add sync and you lose the price. Add AI and you lose the privacy. Add plugins and you lose the ability to fix things quickly.

I would rather be exactly right for a smaller number of people than approximately right for everyone. That is a real position with real costs, and this is the list of them.

At $10 a copy, with the payment processor's cut taken out, that is eleven sales a year to stand still.

I want to lay out the rest of the numbers, because "one-time purchase" gets discussed almost entirely from the buyer's side — as a nicer line on a bank statement — and almost never as the constraint it puts on the person on the other end. The constraint is the interesting part. It shapes what the app is allowed to be.

Where the ten dollars goes

Take one sale. Lemon Squeezy is the merchant of record, which means they handle sales tax in every jurisdiction that wants some, and they charge 5% plus 50¢ for the service. On a $10 sale that is a dollar, near enough, so about $9 lands.

Against that, the recurring costs:

Apple Developer Program, $99/year. Not optional. Without it there is no Developer ID certificate, which means no notarisation, which means every buyer meets the warning that macOS cannot verify the app and a meaningful share of them stop right there.

A domain, about $12/year. Boring, unavoidable.

Hosting, near zero. The site is static and sits on GitHub Pages. The update payload goes to a Cloudflare R2 bucket, which is free until a level of traffic I would be delighted to reach.

So the floor is roughly $111 a year, or about thirteen copies. That is the whole cash side. It is small enough that I could pay it out of pocket forever and never notice, which tells you immediately that money is not the real cost here.

The obligation the buyer never sees

The moment someone pays $10, they get free updates for life. That is on the pricing page, and I meant it when I wrote it.

Now count what "life" contains. macOS ships a major version every autumn. Each one has, historically, been able to break something: a permission prompt that used to appear once and now appears every launch, a window behaviour that changes, a system API that gets deprecated with two years' notice. None of that generates a single new sale. All of it has to be fixed, for people who paid once, three years ago, and are entirely right to expect the app to keep opening.

The surface that has to survive those autumns is about 36,000 lines of TypeScript and 3,500 lines of Rust, sitting on a webview that Apple ships and I do not control.

This is the honest asymmetry of buy-once software, and the reason so many good apps drifted to subscriptions: revenue is a spike at launch and a long tail after, while the maintenance is flat forever. Anyone who tells you the model is simply better for everyone is selling you something. It is better for the buyer, plainly. For the developer it is a bet that enough new people keep arriving to fund work that existing customers have already paid for.

What the price makes impossible

Here is where the arithmetic stops being accounting and starts being product design.

$10 once cannot fund a server. Not a sync server, not an account system, not a licence server that phones home on every launch. Run the numbers on any of those and you get a per-user, per-month cost against a one-time payment that was already spent — the classic way a buy-once app becomes insolvent about eighteen months in, quietly degrades, and then announces a subscription.

So the architecture had to make servers unnecessary rather than cheap. Everything lives in one SQLite file on your own disk. There is no account because there is nothing for an account to sign into. The licence key is checked once, on first launch, and never again — which creates its own support problems, and I would rather have those than the alternative.

I did not arrive at local-first from an ideology about data ownership, though I have since acquired one. I arrived at it because it is the only shape that a $10 payment can actually sustain. What local-first means for your notes is the buyer-facing version of that argument; this is the ledger underneath it.

$10 also cannot fund a support team, which is why the app tries hard to explain itself in place — a paste that cannot happen says what permission is missing rather than failing silently and generating an email.

The refund line

14 days, no reason required, no proof of uninstall.

The received wisdom is that a no-questions refund policy on a cheap product invites abuse. Maybe. What it definitely does is remove the reason a person hesitates at a checkout for a $10 app from a developer they have never heard of, with no free trial, that they cannot try before buying. That hesitation costs far more than the refunds will.

There is also a version of this that is just self-interest: a refund tells me something. A stream of them clustered around one feature is the most direct signal I will ever get, given that there is no telemetry in the app and I have deliberately given up every other way of knowing what people do inside it.

What I would tell someone pricing their own

Three things, learned mostly by doing them in the wrong order.

Price the maintenance, not the build. The build is finite and mostly already spent by the time you have a price. The maintenance runs until you stop, and the price is the only thing funding it. $10 is defensible for Cyanote because the app has no per-user running cost. If yours does, $10 is a slow way to lose money and no amount of goodwill fixes that.

Make the promise you can keep, and write it down narrowly. "Free updates for life" is a promise about updates to this app on this platform. It is not a promise that every future thing I build is free, and the pricing page says so in plain words. Vague generosity at the point of sale becomes a bitter argument in year three.

Do not pretend the model has no downside. The thing a one-time price genuinely buys is real and worth having — no renewal date, nothing taken away for lapsing, an app that still opens if I disappear. The thing it cannot promise is an infinite runway. Anyone who has watched a beloved buy-once app go quiet knows the failure mode, and pretending otherwise on a pricing page insults the reader.

The arithmetic is not comfortable and it is not a secret. Eleven sales a year covers Apple. Everything after that funds the autumn when macOS changes something and a few thousand people who paid once, years ago, expect their notes to open exactly as they did the day before.

There is no account to look up. No dashboard showing their version, their settings, their last twelve sessions. No error report that arrived before their email did. No record that this person exists, beyond a payment receipt in a system I do not control.

This is the direct consequence of the choices on the front of the site — no account, no telemetry, everything on your own machine — and I want to describe what it is actually like, because those choices get sold as pure wins and they are not.

What disappears along with the account

A user database is not only a privacy liability. It is the substrate half of modern software support runs on.

Gone with it: password resets, because there is no password. Account recovery, because there is no account. "Let me check your subscription status." "I can see the error in your logs." "I've pushed a fix to your instance." Every one of those sentences requires a server that knows who you are, and there isn't one.

Some of that absence is straightforwardly good. Nobody can ever email me and ask me to hand over a customer's notes, because I do not have them. There is no breach that exposes what you write, because there is nowhere for it to leak from. A company that cannot be compelled to produce something has a much simpler relationship with the question than one that promises not to look.

And some of it is just harder. If you lose the file that holds your work, I cannot restore it. There is no copy. That is the same property, read from the other side, and it is why the backup story gets more attention in this app than it does in one where the cloud quietly holds a version for you.

The one thing that replaced logs

You cannot print your way out of a problem in a shipped desktop app. A GUI binary has no console attached — the diagnostic line you carefully wrote goes nowhere at all on the platform where the bug actually reproduces.

So the app writes a small diagnostic file locally. Not analytics; it is never sent anywhere. It is a file on the user's own disk, which the user can read, that says what the app did on launch — so that when someone writes in, there is one thing I can ask them to attach that turns "it did not work" into a sequence of events.

Three constraints on it, all learned rather than designed:

Bounded. 32 KB, capped. An unbounded diagnostic file on a machine you cannot reach is a disk-space bug waiting for the one user who leaves the app running for eleven months.

Best-effort throughout. Every write can fail silently. A diagnostic that can fail a launch is strictly worse than no diagnostic at all, and it is very easy to write the version that throws on a read-only directory and takes the app down with it.

It records the questions, not just the answers. This is the part I got wrong first. Logging what happened is not enough when the interesting case is a step that never ran. If the record shows the app asked a question and got an answer, the problem is in what it did next. If the line is absent entirely, the problem is that it never asked, which is a different bug in a different place. Without that distinction the two are indistinguishable from the outside, and I spent nine round trips with a tester learning that the hard way.

Instrument first, then fix

The habit that came out of that: when a bug arrives that I cannot reproduce, the first change I ship is not an attempt at a fix. It is the thing that will tell me which of two explanations is true.

That feels like a delay. It is faster nearly every time, because the alternative — guessing, shipping a plausible fix, and asking a volunteer to try again — costs a full round trip per guess, and a round trip with a real person is a day, not a minute. Three guesses is a week. One instrument is an afternoon.

It has a second benefit I did not anticipate. A fix shipped on a guess, which appears to work, leaves you unsure forever whether you fixed the bug or moved it. A fix shipped against a recorded sequence of events is a fix you can prove. When the bug is in a path that touches somebody's data, "it seems fine now" is not a standard I am willing to ship against — the locked-note race is the case that settled that for me permanently.

Support that happens inside the app

The cheapest support ticket is the one that never gets written, and with no team to answer them, that stops being a platitude and becomes the design constraint.

So the app tries to explain itself at the exact moment it fails. The clearest example: pasting from the clipboard history needs the macOS Accessibility permission, and without it the paste simply cannot happen. The old behaviour was to close the popup and do nothing — which is indistinguishable from broken software, and generates an email that begins "your clipboard doesn't work". Now it names the missing permission, offers to open the right settings pane, and points out that the entry is already on your clipboard so you can paste it yourself. Why a Mac app asks for Accessibility exists for the same reason: the question is predictable, so answer it before it is asked.

Every silent failure is a support ticket with a delay on it. That is the rule, and it has changed how I write error paths more than any other single idea in the project.

The refund policy is an admission

14 days, no reason needed, no proof of uninstall.

That last clause is not generosity. It is honesty about capability. I could not verify an uninstall if I wanted to — there is no phone-home, so there is nothing to observe. A policy demanding proof I cannot check would be theatre, and the sort of theatre that makes a person feel accused on their way out the door.

The same absence shapes what a refund tells me. With no analytics, a cluster of refunds mentioning the same feature is one of the very few real signals I get about what the app is like to use. It is a terrible instrument — tiny sample, self-selected, arriving only from people annoyed enough to act. It is also nearly all of it, along with email, and I would rather work from a biased sample than hold a database of everything everyone does inside their own notes.

That is the trade, stated plainly. I know less about my users than any product manager would consider acceptable, and in exchange the app can promise something almost nobody else in this category can: it makes one network request, ever, and it is a check for a new version. Everything else stays on your Mac, including the record of what went wrong.

I have written the buyer's side of that warning already. This is what it looks like from the other end.

What the $99 buys

An identity on file with Apple, and the certificate that proves it.

Enrolling in the Developer Program is $99 a year. What you get, for the purposes of shipping outside the App Store, is a Developer ID Application certificate — the thing that signs a binary such that macOS can say who shipped it and confirm nothing has been altered since.

That is the whole of it. Not a review, not a listing, not a store. The right to have your name attached to a file in a way the operating system will accept.

Two consequences people outside this get wrong. It is not a quality bar — nobody at Apple looked at Cyanote. And it is not free of teeth: a Developer ID can be revoked, and a revoked certificate takes every copy of your app with it, on every machine, immediately. The identity is the point. Your name is the collateral.

The four variables

A production build here needs four environment values, and the shape of them says a lot about the process:

APPLE_SIGNING_IDENTITY   Developer ID Application: Name (AB12CD34EF)
APPLE_ID                 the account email
APPLE_PASSWORD           an app-specific password
APPLE_TEAM_ID            ten characters

The third is the interesting one. You cannot notarise with your actual Apple account password — you generate an app-specific password at appleid.apple.com, a one-purpose credential that exists so an automated build is not carrying the keys to your entire Apple identity. Good design. It also means the credential is a string that a script needs and a human generated, which is exactly the kind of thing that ends up pasted into a shell history at midnight.

Locally, none of this is needed. Development builds are signed with a self-signed certificate called cyanote-dev, which macOS accepts on the machine that made it and nowhere else. Two paths, deliberately: the dev one is fast and offline, the production one is slow and talks to Apple. Conflating them means every test build waits on a network round trip.

Build, sign, notarise, staple, verify

The production script does five things in order, and every one of them can fail in a way worth handling.

Build universal. arm64 and x86_64 in one binary, so the app runs natively on Apple Silicon and on the Intel Macs people are still perfectly happy with. No Rosetta, no second download, no "which one do I want" on the download page. It doubles the compile time and I would not trade it — an older Mac is a large part of who this app is for.

Sign with the Developer ID identity.

Notarise. Upload the build to Apple, which runs an automated malware scan and, if it passes, issues a ticket. This takes anywhere from a couple of minutes to considerably longer, entirely outside your control, at whatever hour you decided to cut a release.

Staple. Attach the ticket to the file itself, so a Mac can verify it without asking Apple anything. This is the step that matters for the promise the app makes about working offline: an app that had to phone Apple to check its own notarisation on first launch would be a different app. Stapled, the check is local. Skip stapling and everything looks fine on your machine — which has already cached the result — and fails on a fresh one with no network.

Verify, and refuse to continue if it fails. spctl has to say accepted, source=Notarized Developer ID for both the DMG and the app inside it. Both, because they are separately notarised objects and it is entirely possible to staple one and not the other. The script exits rather than uploading something that will greet a buyer with a warning.

The step that needed a human

For a while, the release could not run unattended. One step wanted the app-specific password typed at the keyboard.

That sounds minor. It is the difference between a release being a command and a release being an occasion. A process with a human step in the middle gets run less often, which means fixes sit in main waiting for a big enough batch to justify the ceremony — and batching changes is how a release becomes risky. The bug you shipped is somewhere in eleven commits instead of one.

Getting the human out of it is now, in my head, a first-class feature rather than tooling housekeeping. The whole thing is one command that builds, notarises, publishes the update payload, cuts the notes-only release, deploys the site, and pushes the tag. It is safe to re-run: every step after the build checks whether it already happened, because the failure mode you actually hit is a release that dies three-quarters of the way through on a network timeout.

It also refuses to start if CHANGELOG.md has no section for the version being released — the same text the app shows before anyone accepts an update. A release with no notes is not a release anyone should accept.

A detail that took an afternoon

Building the DMG briefly opens a Finder window. It has to — the disk image's layout is configured by actually mounting it and arranging it.

Harmless, and deeply irritating when it happens on every dev build while you are working. So it happens only on production builds now, which is a two-line change that meaningfully improved my day and would never appear in any changelog.

The other one: notarising the DMG and notarising the app inside it are separate operations, and a stapled DMG containing an unstapled app passes a casual check on a machine that has already seen the app. That is the class of bug where the only honest test is a fresh Mac with no network — which is the test I now run, because everything else confirms what you already believe.

Windows, in comparison

The Windows build exists, and is not on sale, and one reason is that the equivalent process there is worse in an instructive way.

Authenticode signing has no $99 flat rate. It is a certificate from a commercial authority, priced per year, with identity validation attached, and until recently the norm was a physical hardware token that someone posts to you — which makes automated CI signing an interesting problem involving a USB device plugged into something. Cloud signing services have improved this a great deal. It is still several times the friction of Apple's process, and Apple's process involves a mandatory malware scan by a company that can revoke your identity.

I say that as someone who complains about Gatekeeper regularly. Having now done both, $99 and a stapled ticket is the better arrangement, and the same $10 licence will cover Windows when it ships.

That is the property the whole app is built around, so it is worth showing what is actually in there.

The fifteen tables

They group into five areas, which is roughly how the app grew.

Notes. folders, notes, tags, note_tags, attachments, note_links. A note holds its document as JSON, plus a plain-text copy for searching. note_links is what makes [[ work in both directions — it records that A points at B, so B can show a backlink without anybody scanning every note to find out. notes also points at itself through parent_id, which is how a note nests inside another note rather than sprawling across the sidebar.

Tasks. todos. One table. Priority, due date, reminder time as epoch milliseconds. The board view and the list view are the same rows read two ways — there is no board table, because a card and a to-do were never different things and modelling them separately would have created a synchronisation problem out of nothing.

Time. calendar_events, note_calendar_links, calendar_sources. The last one holds subscribed iCal URLs, which is how Google Calendar works here without a sign-in: you paste an address, the app fetches it.

Habits. habits, habit_logs, routines. A log row per tick, not a counter — so a streak is derived, never stored, and filling in last Tuesday is an insert rather than a repair of some running total that has been wrong since March.

Clipboard. clipboard_history, clipboard_pinned. The part that grows fastest, and the part that taught me the most painful lesson in the project.

Fifteen tables for an app that covers notes, tasks, a board, a calendar, habits, routines and a clipboard manager. Not because I was being clever — because most of those things are lists of dated rows, and the honest schema for a list of dated rows is a list of dated rows.

The search index is not data

notes_fts arrived in migration 18: an FTS5 virtual table, kept in step with notes by triggers. You type, the trigger fires, the index updates. Search reads the index, not the notes.

Two rules fall out of that and both were learned the hard way.

Never back it up. A backup walks the user tables, and a virtual table's shadow tables look exactly like user tables from a distance. Include them and a restore writes rows into an index that is simultaneously being rebuilt by the triggers, which produces corruption of the particularly annoying kind — the data is fine, the search results are quietly wrong. So the backup filters virtual tables and their shadows out, and a restore lets the triggers rebuild the index from the notes. The index is derived. Derived things are recomputed, not restored. The backup format has the user-facing side.

Never hand FTS5 raw user input. Type C++ into a search box and FTS5 sees operators, not text. Ordinary punctuation — a hyphen, a quote, a colon — turns a search into a syntax error or, worse, a different query than the one asked for. Everything goes through a function that builds a MATCH expression properly. The three kinds of search post covers what that feels like from the outside.

The lock file that refuses to let me lie

Here is the rule that governs everything else: a migration runs once per database, forever.

The plugin records which version a database has reached. Editing a migration that has already shipped does nothing at all for the people who ran it, and everything for the person installing tomorrow. You end up with two populations, both on "version 19", with different schemas. Every bug report after that is unreproducible, and you will not suspect the migration, because it is right there in the source saying what you meant.

So there is a file, migrations.lock, with one line per shipped migration: version, description, and a SHA-256 of its canonical content — byte-exact, whitespace included. A check runs on every build. Edit a shipped migration and the build fails.

   1  424a2480…  initial schema
  14  c46a8c60…  locked notes: is_locked flag
  18  29ed172d…  full-text search index over notes (FTS5)
  22  6dfa0592…  index clipboard history for paging and dedup
  26  6d52f7dd…  clipboard image thumbnails

Twenty-six shipped, at the time of writing. The file's own comment includes the instruction that matters most: never hand-edit a hash to make the check pass. That is the exact failure this exists to catch, and it is a five-second fix that produces a six-month bug.

I like this file more than almost anything else in the project. It is thirty lines of tooling that converts a mistake I would definitely make into a build error I cannot ignore.

Indexes, and one I nearly added

Migration 25 added three indexes: notes(parent_id), note_tags(tag_id), note_links(target_note_id). All three cover lookups whose column was not the leading column of any existing key. The parent lookup went from 7.1ms to 0.007ms on a 10,000-note database — a thousandfold, for one line of SQL, which is the sort of ratio that makes you want to add indexes everywhere.

Which is the trap. A fourth index looked equally obvious — one covering the sidebar's own list query — and it was wrong, because that query already had a plan SQLite was happy with, and the index would have cost a write on every save to speed up a read that was not slow. The migration carries a comment explaining why it is not there, with the numbers. Comments about what you deliberately did not do age better than comments about what you did.

The rest of that performance story — where the sidebar was actually spending its time — is its own post, and it was not the indexes.

Why it matters that it is one file

Because you can pick it up.

A database that is one file, with no server, no proprietary container and no sidecar directory, is a database you can copy, move to an external drive, keep in a synced folder, and back up by any means you already trust — Time Machine included, no plugin required. Settings will move it for you. Nothing about the app cares where it sits.

It is also the answer to the uncomfortable question every app in this category should be asked: what happens when the developer stops. SQLite is a public format with a thirty-year support commitment and readers in every language there is. If Cyanote vanished tomorrow, your work is a .db file and SELECT * FROM notes gets it out — no export feature required, no cooperation from me needed. What happens when your notes app shuts down is the version of that argument written for people who do not care what a table is.

Fifteen tables and a lock file is not an exciting architecture. It is the one that survives me.

It worked perfectly in development. On every machine it was ever tried on. Type checking passed, the linter passed, the test suite passed, CI passed.

This is my favourite bug in the project, because everything that was supposed to catch it did its job correctly and none of them could have.

The failure

Clicking Format on a CSS note produced: Module name, 'prettier/plugins/postcss' does not resolve to a valid URL.

Only JSON worked. And only by accident — that path returns early on the browser's own JSON.parse before it ever reaches the loader that was broken. One of seven working, for a reason unrelated to the six that did not.

The cause was a single annotation. The formatter's plugin path was assembled as a template literal and marked with a comment telling the bundler not to analyse it. That comment is a real tool with real uses; it means "I know this looks like an import, leave it alone".

The bundler duly left it alone. It emitted no chunk for any plugin, and the shipped application contained the bare string prettier/plugins/ and a request, at runtime, for the webview to resolve that as a URL. Which it cannot. Browsers resolve URLs; they do not resolve npm package names. There is no package directory inside a Mac app.

Why nothing caught it

Here is the part worth the post.

In development, the dev server resolves bare package names itself. That is one of the main things it is for. So during development the import worked, the formatter loaded, and the button did what it said. There was never a moment where the bug was visible on my machine.

Type checking cannot see it. The specifier was a string built at runtime. As far as the type system is concerned, a string is a string.

The linter cannot see it. The annotation that caused the problem is the documented way to suppress exactly the analysis that would have flagged it. I had explicitly told the tooling not to look.

The tests cannot see it. They run against the source, in the same environment as the dev server, with the same resolution. A test asserting that Format produces formatted CSS passes, because in that environment it does.

And CI cannot see it, because CI ran the same three things.

Every one of those tools examines the source. The bug existed only in the output — in the artefact produced by the build, which nothing in the pipeline ever opened. There was a hole in the shape of "the thing we actually ship", and four layers of quality tooling sat neatly around it.

The fix, and the better fix

The immediate repair is dull: literal specifiers, one per language, in a map. A typo becomes a type error instead of a runtime one, and each plugin stays a separately loaded chunk so the formatter is still kept off the startup path — an app that opens instantly does not load a code formatter to show you a note. That last part got verified rather than assumed: no formatter chunk is reachable from the entry bundle, only from the code editor.

The fix that matters is the other one. A script now reads the built chunks and fails the build if any dynamic import still carries a bare package name. It is wired into the build command itself, which is the step every path runs through — the dev build, the production release, CI. There is no way to produce something shippable that skips it.

And it was verified the only way such a thing can be: by restoring the broken code and watching the build refuse it. A check you have never seen fail is a check you are only assuming works. I have shipped a green light attached to nothing before, and it is a considerably worse position than having no light at all.

The same gap, twice more

Once you have the shape — the thing you verify is not the thing you ship — it turns up everywhere.

Notarisation. A stapled disk image containing an unstapled app passes every check on the machine that built it, because that machine has already cached the result. It fails on a stranger's Mac with no network. The only honest test is a machine that has never seen the app, which is now part of the release path rather than something I do when I remember.

An image encoder that substitutes silently. Asking a canvas for WebP does not fail when WebP is unavailable; it hands back a PNG and says nothing. Everything downstream then believes it has a WebP. The clipboard work checks what it actually received rather than what it requested, for that reason.

Both are the same mistake in different clothes: confirming the input to a process instead of the output.

The two-backend design, and the risk I took on purpose

There is a deliberate version of this divergence in Cyanote, and it is worth admitting.

All data access goes through one interface with two implementations: SQLite when running as the real app, and a browser-storage version when running as a plain web page. That means the entire application runs in an ordinary browser tab — which is how the screenshots on this site are made, why they show real software rather than a mockup, and why a UI change can be tried in a second instead of a rebuild.

It is also, structurally, exactly the situation that produced the Format bug: a development environment that is not the shipping environment. I keep it because the benefit is large and the risk is manageable, on one condition — every data change has to be implemented in both backends and the rules they follow have to match. Search is the sharpest case: the browser version mirrors the same matching rules in JavaScript that SQLite's full-text index applies, specifically so a search behaves identically in both. When they drift, you get a bug that only exists in the shipped app, and you get it in the part where everything is stored.

I am not recommending this to everyone. I am saying it is a trade I made with my eyes open, and the mitigation is not discipline — it is that the build now inspects its own output.

The rule I write on things now

Every check in a pipeline should be asked one question: does this look at the artefact, or at the source it came from?

Both are worth having. Only one of them can tell you what your users will get. For a desktop app, where a bad build reaches people through an auto-updater and cannot be rolled back the way a website can, the second sort is the one that matters, and it is almost always the one missing.

Six of seven languages, in every shipped copy, working flawlessly on my machine. I would have bet money that button was fine.

Each of these took you forty minutes the first time, mostly spent finding the answer. Each of them takes about forty minutes every subsequent time, because you did not write the answer down, and the reason you did not is always the same: at the moment you solved it, you were relieved and late and moving on.

The shape of the loss

The tell is a specific feeling. You start a task and think I have done this before — and then discover you remember having done it, and not how.

Partial memory is worse than none, because it makes you confident enough to start without looking it up, and then you spend twenty minutes retracing your own steps to reach the point where you concede you have forgotten. The knowledge decayed into an index entry with no page behind it.

This happens with anything you do more than once and less than monthly. More often than monthly and you retain it; less often than yearly and you accept looking it up. The band in between is where a personal runbook pays, and it is a wide band.

The ninety seconds

Immediately after it works, before you move on. Not later.

The exact commands or clicks, in order. Copied, not paraphrased. The real flags, the real menu names. A paraphrase is a description of the solution; the literal steps are the solution.

What did not work. One line. The obvious approach that failed, so next time you skip it — this frequently saves more time than the working steps, because next time you will have the same wrong instinct.

The thing that was not obvious. There is always one. The setting in a different menu, the order that matters, the fact that it has to be done twice. This is the line that took you thirty of the forty minutes.

Where you found the answer, if it came from somewhere. A link, an issue number, a person's name.

Ninety seconds while it is fresh. The same window as an incident timeline and for the same reason: understanding starts unloading the moment the pressure comes off.

Write it for a stranger

The mistake that makes runbooks useless is writing them for the person you are right now, who has all the context.

"Restart the service" is a note by someone holding the whole picture. In eight months you will not know which service, on which machine, or how one restarts it here. Write the machine, the exact command, and the check that tells you it worked.

The test: could you follow this at 2am, tired, having forgotten everything? That standard sounds excessive for a personal note and it is exactly right, because 2am and having forgotten everything is the realistic condition of use. Nobody consults a runbook on a calm afternoon when they remember how it works.

Length is not the fix — most good runbooks are eight lines. Specificity is.

What deserves one

Anything you have now done twice. Twice is the threshold, and it is worth being mechanical about it. The second time you solve something, you have proof it recurs, and you are holding the answer.

Anything that only happens once a year. Tax filings, renewals, the annual report, the certificate. You will forget completely, guaranteed, and there is no possibility of retaining it.

Anything you do under pressure. When something is broken and people are waiting, working from a written sequence is dramatically better than improvising from partial memory — that is the whole reason runbooks exist in operations.

Anything involving a system with a bad interface. Government portals, banking, enterprise software, anything where the correct sequence is arbitrary and undiscoverable. These are pure runbook material, because nothing about the interface will remind you.

Where they belong

Personal ones in your own notes. Findable by search, because you will not remember what you called it — you will search for the error message or the tool name. That means search has to reach inside code blocks, which is where the commands are.

Shared ones in the shared place. If a colleague could need it, it belongs in the team's documentation. Keeping operational knowledge in a personal file makes you a bottleneck, and being a bottleneck feels like job security and is actually just being interrupted a lot — the thing a handover document exists to unwind.

When you use it, fix it

The maintenance rule, and it is the only one.

Follow your own runbook and something will be slightly wrong — a menu renamed, a flag deprecated, a step no longer needed. Fix it then, in the two minutes you are already there. Not later.

A runbook corrected on each use stays accurate indefinitely. One never revisited rots, and a rotted runbook is worse than none: you follow it, it fails halfway, and now you are debugging both the problem and the instructions.

The honest version

Nobody writes these at the moment of relief. That is the entire difficulty and no amount of agreeing with the principle changes it.

The one intervention that works is making the writing take ninety seconds instead of ten minutes. Paste the commands, add two lines, done. Any attempt at a proper document — a title, a structure, an explanation of the system — is a ten-minute job, and ten-minute jobs do not happen at the moment you have just fixed something and are already late.

Cyanote is a reasonable home for these: code notes with syntax highlighting and language detection for the commands, prose notes with code blocks inline when you need explanation around them, and ⇧⌘F searching the body of everything including the code — so the error message you paste today is what finds this note in eighteen months. It is one local database on your own Mac, which for the set of instructions that make your own machines and accounts work is where it should be.

That is the normal outcome, and the causes are structural rather than a failure of anyone's diligence.

Why most reviews change nothing

Written too late. Memory of an incident degrades unusually fast, because most of it was formed under stress and much of it was wrong at the time. What survives at day nine is a tidy narrative in which the sequence made sense — which is precisely the version that contains no lessons.

The timeline is reconstructed instead of recorded. A timeline assembled afterwards has hindsight in every line. "At 02:14 we realised it was the cache" is nearly always wrong; at 02:14 someone suspected the cache, among three other theories. The suspicion and the alternatives are the interesting part, and reconstruction deletes them.

Blameless is stated but not practised. If the document says blameless and the meeting looks for who deployed it, everyone learns which of the two is real, and the next review will be written defensively. A defensive review has no useful content.

The actions are aspirational. "Improve monitoring" is not an action. It has no owner, no date, and no definition of done, and it will be on the next review too.

Root cause, singular. Complex systems do not have a root cause. They have a set of conditions that were individually survivable, and the search for the one cause stops the investigation at whatever is easiest to blame — usually a person or the last change.

Record during, not after

The highest-leverage change, and it costs one person's partial attention.

During an incident, someone writes timestamped lines as things happen. Not analysis — observation:

02:04  alerts on checkout latency
02:09  suspect the deploy at 01:50, start rollback
02:14  rollback done, no change — so not the deploy
02:20  noticed cache hit rate fell at 01:30, before the deploy
02:31  restarted the cache nodes, latency recovering
02:46  green. leaving the rollback in place, unclear why 01:30

Six lines, written in the moment, and they contain something no later reconstruction can: the wrong theory, and how long it cost. Twelve minutes went to the deploy hypothesis. That is a finding — it says something about what the dashboards were showing and what people reached for first — and it is invisible in every version of this document written the following week.

The person taking notes should not be the person fixing. It is a real role, it is the easiest one to fill, and it is what makes the difference between a review with content and a review with a narrative.

The five sections

Longer templates exist. These five carry the value.

What people experienced. Not "elevated 5xx" — "customers could not check out for 42 minutes, about 900 attempts failed." Impact in human terms, at the top, because it is the only part most readers will read.

The timeline. As recorded, including the wrong turns, with times. If it is tidy, it has been laundered.

What made this possible. Plural, deliberately. The change that triggered it, the monitoring that did not fire, the alert that fired and was muted last month for good reasons, the runbook that was out of date, the fact that only one person understood the system. Every one of these is a contributing condition, and every one is an opportunity. Naming one of them "the" root cause discards the rest.

What made it hard to fix. Frequently more valuable than the cause. Nobody could find the dashboard, the on-call did not have access, the rollback took nine minutes, the logs were in a format nobody could read at 2am. Time-to-recover is where most of the real damage is, and it is the part most reviews barely mention.

What we are changing. Two or three items, each with a name and a date. Not eleven. Eleven means none, and everyone in the room knows it.

The blameless part, done properly

Not "we will not say who". That is silence, not blamelessness.

It is: assume everyone acted sensibly given what they knew at the time, and ask what made the sensible action wrong. Somebody deployed on a Friday afternoon — why did that seem fine? Somebody muted the alert — what was it doing that made muting reasonable? Those questions produce fixable answers. "Who deployed it" produces a person who will be more careful and a system that is exactly as fragile as before.

The practical test is whether people write down their own mistakes in the timeline. If they do, you have it. If the timeline is written in the passive voice throughout, you do not, whatever the template says.

What happens afterwards

Two things, neither of which is the meeting.

The actions become real dated tasks with owners, in whatever system that team actually uses, that day. An action item living only inside a document is a wish. This is the step that separates teams whose reviews change things from teams whose reviews accumulate.

Somebody reads the last five before writing the sixth. The single most valuable habit in this whole area, and almost nobody does it. Repeats are the signal — the same contributing condition showing up three times means the fix from last time did not happen or did not work, and that pattern is invisible one document at a time. It is the same reason a decision journal only works if you reread it.

Which means the reviews have to be findable by content, not filed by date. You will search for "cache" or "rollback", not for "the March one".

The personal version

Not everyone works somewhere with a process. The same shape works for one person.

Anything that went badly and took real time — a bad deploy, a lost afternoon, a data problem you had to unpick — is worth six lines: what happened, what you thought at the time, what actually caused it, what made it hard to fix, one thing to change. Ten minutes, once.

A year of those is a remarkably good picture of how your own systems fail, and it is the material that turns "I have been doing this for five years" into something more useful than time served.

The honest version

If you run incidents at any scale, use an incident management tool. Timeline capture, paging, status pages and action tracking are a real product category and they do things a notes app will not.

For a small team, a solo operator, or the personal version, the shape above is most of the value and it needs a text editor and the discipline to write during rather than after.

Cyanote has incident review and retro templates in the / menu — the five sections in order, so the document starts as prompts rather than a blank page. Notes hold timestamped lines, code blocks with the actual error, and images of the graph, all in one document; ⇧⌘F searches the body of every review you have written, which is what makes "have we seen this before" a question you can answer in four seconds. It is one local database on your own Mac, which for the personal version is the point — your record of how things fail is yours, not your employer's.

The problem is that nothing tells you when to move. There is no error, no warning, no point at which the app declines. It just gets gradually worse at a job it was never for, and you notice about four days after you should have.

The four points where it breaks

Around 3,000 words: navigation. Below that you scroll. Above it you need a table of contents, an outline you can jump around in, and the ability to collapse sections to see the shape. A long note with no outline is a document you can only experience linearly, and you cannot think about the structure of something you can only read from the top.

Around 8,000 words: revision. This is where you need to move section four above section two, see both versions, and change your mind. Notes apps are built for appending, not for restructuring, and the operation you actually want — drag this chapter there — is either missing or is a cut-and-paste with a real risk of loss.

As soon as anyone else reads it: change tracking. Comments, suggestions, a record of what changed between the version they read and the one they are reading now. This is not a nice-to-have once a document is being reviewed; it is the entire mechanism of collaborative editing, and notes apps have none of it.

Whenever the output format matters. A submission with a required layout, a citation style, page numbers, a specific typeface. If the document has to look a certain way when it leaves, you are producing a formatted artefact, and that is a different category of software.

If you have hit none of these, stay where you are. Moving early costs more than it saves.

What a notes app is genuinely better at

Worth saying, because the answer is not "always use a word processor".

Everything before the first draft. Fragments, quotes, half-arguments, the paragraph you wrote in the wrong order. Research and thinking are exactly what a notes app is for, and doing them in a word processor produces premature formatting — you start choosing headings for a thing whose shape you do not yet know.

Anything with code in it. Word processors handle code badly. Smart quotes, autocorrect and automatic capitalisation are actively hostile to a shell command, and no amount of style configuration fully fixes it.

Documents that never leave. An internal note, a personal essay, a design rationale, a record for yourself. If nobody is reviewing it and nothing depends on the layout, the notes app is fine at 12,000 words and moving is busywork.

The notes about the document. Which stay behind when you move the prose out, and are the reason you should not delete the note when you migrate.

The split that works

Most people who write long things end up with the same two-place arrangement, and it is worth adopting deliberately rather than discovering.

The notes app holds the thinking. Research, sources, the outline, the arguments, the offcuts. It stays authoritative for that material for the whole life of the project — including after the document is finished, because it is the part you will want next time.

The document lives in a real document tool. Once the shape is decided, the prose moves and the notes stay. From then on the notes app is where you go to find the thing you read in March, and the document tool is where the writing happens.

The failure is trying to make one of them do both. Drafting in the notes app past the point it works produces a document you cannot restructure; researching in the word processor produces a folder of half-documents with no way to search across them.

Choosing the second tool

Briefly, since it depends entirely on the document.

Something with a real outline and restructuring. Scrivener is the long-standing answer on the Mac for book-length work, and the reason is precisely the second failure point above: it is built for moving sections around.

Something with comments and suggestions. If anyone reviews it, this is the deciding feature and it is why Google Docs and Word own that stage regardless of anything else.

Something with a stable file format, if the document will outlive the software. Markdown or LaTeX in plain files will be openable in twenty years. A proprietary format may not be, which is the same portability question that applies to your notes.

Something with citations, if you need them. A reference manager plus whatever it integrates with. Doing citations by hand in a long document is a decision you regret exactly once.

Two things worth doing before you move

Get the outline right first, in the notes app. Moving a document with a settled structure is a copy-and-paste. Moving one whose shape is still changing means you will restructure it twice, once in each tool.

Keep the note. Do not delete the draft when you move it out. It is the record of how the thing was made, it contains the paragraphs you cut and will want back, and it costs nothing to keep. Link it to the finished document so the two ends of the project are connected — a small use of linking that pays off years later when you write the follow-up.

The honest version

There is a strain of advice that says you should write everything in one tool, and it is wrong in both directions. Writing your research notes in a word processor is miserable. Writing a book in a notes app is a slow-motion structural problem.

Two tools with a clear boundary is not a failure of tooling. It is what having different jobs looks like.

Cyanote is the first half of that split and does not pretend to be the second. Notes nest into sub-pages, headings give a document structure, [[ links connect research to whatever it is for, and full-text search finds a quote you saved eighteen months ago. There is no outline pane, no change tracking, no comments, no citation manager and no page layout — so somewhere around a few thousand words of finished prose, the right move is to take the writing somewhere built for it and leave the thinking where it is.

What two seconds is, is long enough to notice. And the thing you do when you notice is decide — quickly, without articulating it — whether the note is worth the wait. Most of the time it is. Some of the time you were only going to write down four words, and four words are not worth a spinner, so you keep them in your head instead and they are gone by lunchtime.

That is the actual cost of a slow launch. Not the seconds. The notes that never got written because opening the app was a decision.

The four-second thought

Capture has a shelf life. Something occurs to you — a name, a thing you owe someone, a fix you just worked out — and you have a few seconds of willingness before your attention is somewhere else.

Everything that happens in those seconds is competing for the same budget: reaching for the machine, finding the app, waiting for it, finding where to type. A launch that costs two of the four is not taking half your time. It is taking half your willingness, and willingness is the scarce thing.

You can watch this in how people behave rather than what they say. The app that ends up holding the scraps is almost never the most capable one. It is whichever one is already open, or opens fast enough that using it never felt like a decision. Fast is not a nice-to-have in this category; it is most of the product.

What makes a launch slow

Four things, roughly in order of how much they cost.

A network request on the critical path. The app opens, then asks a server something — is this session valid, is the licence current, what changed since last time — and will not draw your notes until it has an answer. On good wifi this is a few hundred milliseconds and nobody notices. On hotel wifi it is a spinner, and on no wifi it is a spinner that eventually times out, which is the worst launch in software: slower when there is nothing to fetch.

Loading everything before showing anything. Some apps read the whole collection into memory at startup. Fine at 50 notes. Not fine at 5,000, and it degrades exactly as your investment in the app grows, so the app gets worse the more you have used it.

Rendering the world before the window. Building every sidebar, every list and every panel before painting anything. The fix is boring and known — draw the window, then fill it — but it takes deliberate work that nobody does unless somebody measures.

A runtime that has to start first. If the app ships its own browser engine, that engine boots before your notes exist. This is the one people argue about, and the honest position is that it is real but smaller than the internet thinks: a well-built Electron app can start fast, and a badly built native one can be slow. It is a handicap, not a verdict.

Cold, warm, and the number that matters

If you measure this yourself, measure the right thing.

Cold start is after a reboot, or after the app has been closed long enough to fall out of the file cache. It is the slowest number and the least frequent.

Warm start is the one you live with: quitting and reopening in the same session, everything still cached. This is what "open the app to write four words" actually costs, and it is usually a fraction of the cold number.

Time to first useful keystroke is the only measure that matters, and almost nobody publishes it. Not when the window appears — when you can type and the characters land in the right place and are being saved. Plenty of apps show a window quickly and then swallow the first half-second of typing, which is worse than a longer honest wait, because you have to check whether your words survived.

Test it the way you use it. Quit the app, open it, and start typing immediately. Did every character arrive?

Memory, and why it shows up as speed

Idle memory footprint gets discussed as if it were a virtue in itself, and mostly it is not — unused RAM is wasted RAM, and a browser tab you left open probably costs more than any of this.

It matters at the edges, and the edges are where people live. If you keep an app open all day alongside a browser, a chat client, a design tool and a couple of editors, a laptop with 8 or 16 GB starts swapping, and swapping is felt as everything being slow. The app that quietly holds several hundred megabytes to show you a list of notes is not committing a crime; it is spending a shared budget you did not know it was spending.

The mechanism worth understanding is where the browser engine comes from. Apps built on Electron ship their own copy of Chromium, so every such app on your machine is a separate browser. Apps built on the system webview — which is what Tauri does, using WebKit on macOS — use the engine that is already running as part of the OS. It is the same rendering technology either way; the difference is how many copies of it are resident.

What "instant" is worth as a target

Under a second to a usable window, on the machine you actually own rather than the developer's.

The reason to hold that line is not benchmark pride. It is that under a second, the app stops being something you open and becomes something that is simply there — the same way a text field on a page you are already looking at is there. Above a second or two, some fraction of your thoughts stop making the journey, and you will never know which ones, because unwritten notes leave no trace.

It is the same argument as the habit tracker that needs its own icon and the clipboard popup that comes to you: every unit of friction between the impulse and the writing costs you some of the writing, and the losses are invisible.

The honest version

Startup time is not the most important thing about a notes app. It is a hygiene property, and plenty of excellent apps take a beat to open because they are doing something worth doing — indexing a large library, restoring a real session, rendering a document that deserves it. If an app is slow and you love it, that is a completely defensible trade and I would not switch either.

What is not defensible is being slow because of a server, on a machine that already has all your notes on it. That is a launch delay you are paying for architecture you did not ask for.

Cyanote's startup budget is under a second to a usable window, and it holds because there is nothing to wait for: no session check, no sync handshake, no server in the path. Everything is read from one SQLite database on your own disk, and the app is built with Tauri, so it draws through the WebView macOS already has rather than shipping a browser of its own. With the wifi off it opens in the same time, because the wifi was never part of opening it.

The reaction is correct. It is the broadest permission macOS hands to a normal app, and being asked for it should make you stop. It is also, for this particular category, genuinely unavoidable — and worth understanding, because "the app asked and I clicked yes" is not a security decision.

What it is actually called and why the name is wrong

The setting lives under System Settings → Privacy & Security → Accessibility, and its name is historical. It was built so assistive software — screen readers, switch controls, alternative input devices — could operate the interface on a person's behalf.

Doing that requires two capabilities: reading the interface of other apps (what windows exist, what the buttons say, where the focus is) and sending input to them (keystrokes, clicks). Which is exactly what any automation tool needs, so macOS reuses the same gate for all of it. A window manager, a text expander, a keyboard remapper, a screenshot annotator and a clipboard manager all end up in the same list as a screen reader.

The name has nothing to do with why most of the apps in that pane are there.

What granting it actually allows

Be clear-eyed about this, because it is broad.

An app with Accessibility permission can, in principle: read the contents of other apps' windows including text on screen, see what you are focused on, send keystrokes and clicks to any app, and drive interfaces you are not looking at. It is not a scoped permission — you cannot grant it for one app or one action. It is on or off for that binary.

That is a lot. It is more than the app in front of you probably needs, and macOS gives you no way to give it less.

Two things narrow the risk in practice. It is per binary, and macOS ties the grant to the app's code signature — replace or tamper with the app and the permission is revoked until you grant it again, which is a meaningful protection against something being swapped underneath you. And it is revocable in one click, in the same pane, at any time.

Why a clipboard manager needs it

The mechanism is worth knowing, because it explains why there is no clever workaround.

Recording what you copy needs no permission at all. The clipboard is a shared system service, and any app can read it. That half is free.

The other half is what you actually want: press a key, pick an old item, and have it land in the app you were in. To do that, the manager has to put the item on the clipboard and then send a ⌘V keystroke to the other app. Sending a keystroke to another application is synthesised input, and synthesised input is exactly what the Accessibility gate exists to control.

There is no API that says "paste into the frontmost app, and nothing else". macOS does not offer a narrow version of this permission, so the app has to ask for the broad one to do the narrow thing. That is a platform design decision, not a choice the developer made.

Which means the honest test of an app in this category is not whether it asks — they all must — but whether it works without it. Copying a history item to your clipboard so you can paste it yourself with ⌘V requires no permission at all. An app that refuses to function until you grant Accessibility, when the only thing that needs it is the auto-paste convenience, is asking for more than it is spending.

What to check before you grant it

Does the app tell you why, in specific terms? "Cyanote needs Accessibility permission to paste for you" is a specific claim about one feature. "This app requires Accessibility to function" is not, and vagueness at the moment of asking is the signal worth reacting to.

Is it signed and notarised? Notarisation means Apple scanned the binary and the developer is identifiable. It is not a guarantee of good behaviour, and it does raise the cost of shipping something malicious considerably. An unsigned app asking for this permission is a different proposition entirely.

Does it degrade rather than refuse? The good behaviour is: work without the permission, at reduced convenience, and explain what you would gain by granting it.

Can you check what it does with it? The connections an app makes are observable. An app with broad local permission and no network activity has a much smaller blast radius than one with both.

Do you need the feature? If you are content to press ⌘V yourself, do not grant it. That is a real option and most apps in this category will keep working.

The permission it should not be confused with

Two others come up and are genuinely different.

Input Monitoring lets an app see keystrokes going to other apps — that is keylogging capability, and it is a higher bar. A clipboard manager should not need it. Global hotkeys generally do not require it either. If something in this category asks for Input Monitoring, ask why, specifically.

Screen Recording lets an app capture what is on your display. Screenshot tools need it. A notes app does not.

Accessibility is broad but purposeful. If an app asks for all three, the questions get much harder.

The honest version

This permission is uncomfortable and the discomfort is appropriate — macOS made the dialog stern on purpose. The right response is not to refuse everything, which leaves you unable to use most Mac automation, and not to click through, which is how the dialog stops meaning anything. It is to know which feature you are enabling and be able to switch it off.

Cyanote asks for exactly one reason. Copies are captured without any permission at all; the clipboard history works and you can copy items from it freely. Pasting a history item straight back into the app you came from sends a ⌘V keystroke, and macOS gates synthesised keystrokes behind Accessibility. If you have not granted it, the app says so and offers to open the right settings pane rather than quietly doing nothing. It never asks for Input Monitoring or Screen Recording. And it makes three network requests in total, none of which carries anything you have written — which is the other half of what "broad local permission" should be weighed against.

So point at the file. It takes two minutes, it works for any app you use, and the answer changes what you can do — because a path you can find is a thing you can back up, copy to a new machine, and check the size of. A path you cannot find is a promise.

The three places a Mac app can put your data

Nearly everything lives in one of these.

Application Support. ~/Library/Application Support/<some identifier>/. This is the correct home for an app's own database, and it is where most well-behaved apps put it. The folder is hidden by default, which is why most people have never seen theirs.

A folder you chose. Some apps write plain files — Markdown, text, whatever — into a directory you pick. This is the most transparent arrangement there is: the notes are files, visible in Finder, greppable from a terminal, and the app is only ever a viewer.

A container. ~/Library/Containers/<bundle id>/Data/..., used by apps sandboxed for the App Store. Same idea as Application Support, one layer further in, and more awkward to reach by hand.

There is a fourth answer, which is "on a server, with a cache here". That is not a criticism — plenty of good software works that way — but it is a different arrangement, and the tell is that the local file is much smaller than the amount you have written.

How to find yours, in any app

Two routes. Try them in order.

Look in the app's settings. Well-made apps show you. Look for a data or storage section, often with a "reveal in Finder" button next to a path. If an app tells you where its database is without being asked, that is a good sign about the rest of it.

Otherwise, look yourself. In Finder, press ⇧⌘G and type ~/Library/Application Support/ — that shortcut is the whole trick, since the Library folder is hidden. Sort by date modified and the folder that changed while you were writing is the one. If it is not there, try ~/Library/Containers/.

Once you have it: open the folder and look at the sizes. A single file of a few megabytes named something like .sqlite or .db is the normal, healthy shape for an app that stores structured content. Thousands of small text files is the other normal shape. Almost nothing there is the shape that should make you ask what the app is actually a client for.

What to do with the path once you have it

This is why it was worth two minutes.

Point your backup at it. Time Machine already covers your home folder, so if it is running, this is done — but knowing the path is what lets you verify that, by browsing a Time Machine snapshot and finding the file. An untested backup is a hypothesis. I have written about the wider version of this, and it starts here.

Copy it before you do anything drastic. New Mac, major OS upgrade, app version you are unsure about: copy the folder somewhere first. It costs seconds and it is the difference between a bad afternoon and a lost year.

Check its size occasionally. A database that is 40 MB and stops growing while you keep writing is telling you something. A database that has doubled in a month is also telling you something — usually that you have been pasting images.

Know it for when the app is gone. If the developer disappears, the file is what you have. Whether that is a recovery or a dead end depends entirely on the format, which is the next question.

The format matters more than the path

A file you can find is not the same as a file you can read.

Plain files — Markdown or text in a folder — are the maximum-portability answer. Any editor opens them, grep searches them, and the app is genuinely optional. The cost is that things which are not text (links between notes, tick-box state, images, tables) have to be encoded in conventions each app invents, so a folder of Markdown is portable prose plus a proprietary sprinkling.

SQLite is one file containing structured data, and it is the most common answer for anything richer than prose. It is not a lock-in format: it is an open, documented, extremely long-lived format, readable by the sqlite3 command that ships with macOS and by free tools on every platform. Your notes are in there as rows, and you can get them out with a query even if the app that wrote them no longer exists.

A proprietary binary blob is the one to be wary of. If the file has an extension you have never seen and the app offers no export, then finding the path has told you where the data is and not much else.

The practical test is not "which format is purest". It is: can I get everything out, today, into something readable, without the app's cooperation being permanent? An app storing SQLite with a working full export passes. An app storing Markdown files passes trivially. Anything that fails both is a risk you are carrying whether or not you have noticed.

Two things people get wrong

Putting the database in a sync folder. It is tempting: move the app's data into iCloud Drive or Dropbox and you have invented sync. Sometimes this works. What it also does is let two machines write to one database file, and file-sync services resolve that by picking a winner or leaving you a conflicted copy — neither of which is what a database needs. If an app supports moving its storage, moving it to an external disk or a different folder is fine; moving it into a live sync folder used by two Macs at once is how corruption happens.

Assuming iCloud Drive is a backup. It is a sync service. Delete something and the deletion syncs, promptly and everywhere. A backup is a copy that does not change when the original does — that is the entire definition, and it is the reason a restore should replace rather than merge.

The honest version

Knowing the path does not make you safer by itself. What it does is convert a marketing claim into something you can check, and give you the one piece of information every recovery starts with.

If you use an app whose settings do not tell you where your writing is, go and find out today. Not because the app is untrustworthy — most are fine — but because the day you need to know is never a calm day.

Cyanote keeps everything in one SQLite file at ~/Library/Application Support/app.cyanote.desktop/, and Settings shows you that path and lets you move it wherever you want. Notes, tasks, calendar, habits, routines and the clipboard history are all in that one file, so backing it up is one copy. On top of that there is a readable JSON export of everything, and automatic daily backups keeping the last seven — because a path you can find is the floor, not the whole answer.

It is free. It is already installed. It launches instantly, syncs to your phone without you configuring anything, locks individual notes behind Touch ID, scans documents through the camera, and has quietly grown folders, tags, smart folders, tables, checklists and note-to-note linking over the last few years. For the enormous number of people whose requirement is "somewhere to put things", it is the answer, and switching to something else because a blog told you to is how you end up with two half-populated notes apps.

So this post is about the specific cases where leaving is justified — and I am going to be strict about it, because most reasons people give are not.

The reason that is not good enough

"I want a better writing experience."

You do not, usually. What you want is to have written, and a nicer editor is the most pleasant available substitute for doing it. Switching apps for aesthetics produces a genuine two-week productivity boost, followed by exactly the same output as before, in a different typeface.

If your notes are fine and you are just bored of looking at them, changing the app is an expensive way to fix that. Changing the theme is a cheap one, and worth trying first.

Now the four that hold up.

One: you need it to leave

This is the strongest reason, and it is structural rather than aesthetic.

As of August 2026, Notes on macOS can export a single note to PDF or Markdown from the File menu. There is still no built-in way to take the whole collection out at once — bulk export means a third-party tool, AppleScript, or clicking through a few hundred notes one at a time.

For most people that is a non-issue right up until the day it is the only issue: moving to a Windows machine, handing a project archive to a client, or simply wanting your own words in files you can grep. The cost is not visible while you are inside the system, which is exactly what makes it worth counting in advance. It is the same question as what happens when your notes app shuts down, asked of an app that is not going anywhere — Apple will still be here, and your notes will still be inside a format that only leaves one at a time.

If you are two hundred notes in and thinking about a move, that is the moment it is cheapest. It never gets cheaper again.

Two: your notes contain things iCloud should not

Notes syncs through iCloud by default, and iCloud is well-run infrastructure. Advanced Data Protection makes it end-to-end encrypted if you turn it on, and locked notes are encrypted regardless. This is a better privacy story than most of the industry offers.

It is still a copy on somebody else's servers, tied to an identity, subject to an account that can be locked, and reachable by a legal process directed at Apple rather than at you. For a large share of note-taking, none of that matters. For a therapist's session notes, a lawyer's case notes, a journalist's sources, an HR investigation, or a diary you would genuinely rather not have restored to a future device — it matters, and no amount of "they are a good company" changes the shape of the arrangement.

The alternative is not "trust a different company more". It is not involving one: a database on your own disk, where the recovery story is a backup you control and the legal story is a warrant served on you. Whether that trade is worth it depends entirely on what is in the notes.

Three: what you write does not fit the editor

Notes is built for prose, lists and pictures, and it is genuinely good at those. It is not built for a few specific shapes.

Code. No code blocks with syntax highlighting. Paste a shell command into Notes and smart quotes and autocorrect are actively working against you. This is the single most common reason developers leave, and it is a real one — I have written separately about keeping notes and code in one app.

Deeply nested structure. Folders and one level of sub-folders is not the same as notes that nest into sub-pages arbitrarily. If you think in outlines, you will feel the ceiling.

Typography you control. Font, size and line spacing are largely Apple's decision. If you read for hours and have opinions about measure and leading, that ceiling is low.

If none of these describes what you write, this reason does not apply to you, and it is fine to say so.

Four: the notes are only one of five things

This is the honest reason most people switch, and it has nothing to do with Notes being deficient at notes.

Your week is not made of notes. It is made of notes, a to-do list, a calendar, a couple of habits you are trying to keep, and a clipboard full of things you copied. Notes covers one of those, plus checklists. The rest live in Reminders, Calendar, some habit app, and whatever clipboard manager you installed in 2021 — five icons, five windows, five places to look for the thing you wrote down.

Apple's apps are individually good and deliberately separate, which is the right call for a platform vendor and the wrong shape for some people's day. If you keep losing things in the gaps between five apps, that is not a notes problem and no notes app will fix it. It is the argument for one window instead of five.

What you give up by leaving

Being straight about the cost, since it is substantial.

Your phone. Notes on iPhone is excellent and syncs for free with nothing to set up. Almost any alternative is worse at this, and several — including mine — do not have a phone app at all. If you write notes on your phone daily, this is close to disqualifying, and you should weigh it above everything above.

Free. Notes costs nothing, forever, with no licence to keep track of.

Integration. Share sheets, Siri, Quick Note from the corner of the screen, scanning with the camera, handwriting on an iPad. Third-party apps get some of this; none get all of it.

Collaboration. Sharing a note with a family member and both editing it. Local-first apps categorically cannot do this, and pretending otherwise would be dishonest.

If more than one of those matters to you, stay. That is not a consolation prize; it is the right decision.

How to leave, if you are leaving

Do it in a way that does not depend on the new app working out.

Get the text out first, on its own. Export to Markdown or PDF into a folder before importing anywhere. If the new app disappoints you in a month, you still have your notes in a format nothing owns.

Do not migrate everything. Move the last six months and the twenty notes you actually reference. The rest is an archive; leave it in Notes, which is not going anywhere, and search it there on the rare occasion you need it. Wholesale migration is how people spend a weekend and end up with two apps and no system.

Keep Notes installed. For the phone, for scanning, for shared notes. Leaving an app does not have to mean deleting it, and the shared-with-family grocery list is genuinely better where it is.

Run the four-second test on the new one before you commit: turn the wifi off and see what still works.

The honest version

Most people reading this should stay on Apple Notes, and I would rather say that than sell you something. The four reasons above are narrow on purpose: exit cost, the sensitivity of what you write, editors that do not fit the shape of it, and a week that is more than notes.

Cyanote answers the last three and the first: a block editor with code blocks and syntax highlighting, notes that nest into sub-pages, typography set per note, tasks and a board and a calendar and habits and a clipboard history in the same window, everything in one SQLite database on your own Mac with no account — and a one-file JSON export of the whole collection whenever you want it. It has no iPhone app, no collaboration and no share sheet, and it costs $10 once where Notes costs nothing. Those are the actual terms of the trade.

The cost is not disk space. It is that your search results fill up with things you do not want, that browsing shows you a decade of abandoned starts, and that a collection you cannot face opening stops being a system.

Deletion is maintenance, and it is the only part of note-keeping nobody does.

The four things safe to delete

Duplicates of things that exist elsewhere. Recipes copied from a site, documentation pasted from a manual, an article you saved wholesale. If it is public and still online, you have not saved it, you have cached it — and badly, without the updates. Keep a line saying what it was and why it mattered to you. That line is the part that was yours.

Notes from tools you no longer use. Configuration for a service you left, a workflow for software you have replaced, meeting notes from a job three roles ago. There is a real emotional weight to deleting the record of a job you cared about, and it is worth being honest that the value is sentimental rather than practical. If it is sentimental, keep it deliberately — that is a fine reason. Just do not pretend you will consult it.

Abandoned starts. Twelve notes that are a title and two lines, from projects that never happened. These are the most cluttering category by count and the easiest to delete, because there is genuinely nothing in them. If one had an idea in it, move the idea to the idea bank and delete the note.

Anything superseded. The old version of a document, the outdated process, the plan you replaced. Superseded material is worse than absent material, because it will be found by search and read as current. This is the category where deletion is not tidying but correctness.

The four things to keep forever

Anything you wrote in your own words. Summaries, arguments, explanations, reading notes, journal entries. This is the whole product of note-keeping and it does not become obsolete — a reading note from 2019 is exactly as good as it was.

Decisions and their reasons. Why you chose this, what you thought at the time. These become more valuable with age, not less, and they are irreplaceable — nobody can reconstruct their own past reasoning.

Anything about people. What they told you, what you agreed, what they were working on. Contact history is cheap to keep and impossible to rebuild.

Records with numbers in them. What things cost, how long they took, what the reference was. Your own historical figures are the basis of every future estimate you make.

The pattern: delete what is reproducible, keep what is not. A pasted article is reproducible. Your reaction to it is not.

The two-pass method

Once a year, an hour, and it is much easier if you go in two passes.

Pass one: sort by date, oldest first, and skim titles only. Do not open anything. You can tell from a title that a note is an abandoned start or a stale config. This pass deletes a surprising proportion in about twenty minutes, and it works because you are not reading — reading is what makes every note feel worth keeping.

Pass two: search for the things you know are duplicated. The tools you left, the projects that ended, the things you pasted. Targeted rather than exhaustive.

Then stop. An hour, once a year, and do not attempt to be thorough — a collection that is 80% pruned is entirely fine, and attempting completeness is why the annual prune becomes a thing that never happens.

Archive rather than delete, if it helps

For anyone who finds deletion genuinely difficult — and plenty of people do — there is a middle path that gets most of the benefit.

Export the material you are unsure about to a file, put it somewhere out of the way, and remove it from the live collection. It still exists. It is no longer in your search results, and search results are the thing you were actually fixing.

The honest caveat: an archive you never open is functionally deleted, just with extra steps and a small ongoing cost in backup size. That is not an argument against it — the psychological difference is real and worth something. Just be aware that "archived" and "deleted" converge after about a year.

What deletion is not for

Not for privacy. If a note should not exist, deleting it from the app is not sufficient — it is in your backups, in your daily automatic backups, possibly in a Time Machine snapshot, and possibly in an export. Deleting something properly means dealing with the copies, which is a different task requiring a different amount of care.

Not to make an app faster. Modern software handles tens of thousands of notes without difficulty, and if yours is slow at 2,000 the problem is the app, not the count.

Not for tidiness alone. A note that is doing no harm and takes no attention can stay. This is only worth doing where the clutter has a cost — in what search returns and in whether you can face opening the collection.

The honest version

Most people will never do this, and the world will not end. A cluttered notes collection is a mild inefficiency, not a crisis, and the annual prune is the most skippable habit in this whole area.

The version that is genuinely worth it is much narrower: delete superseded documents when you supersede them. That one is not tidying, it is accuracy — the old process being findable is how someone follows it next year, and the someone is usually you.

Cyanote makes both halves plain. Everything is in one SQLite database on your own Mac, so you can see the size of what you are carrying, and it exports to one readable JSON file, which is the archive route for anything you would rather not delete outright. Full-text search is what makes pruning worth doing at all: the reason to remove the stale material is that ⇧⌘F should return the note you meant, and every superseded document is a result competing with it.

You find out three things immediately. Whether it opens at all. Whether your notes are there. And whether the app tells you honestly that it is offline, or just quietly stops saving.

I would run that test on a Tuesday afternoon rather than at thirty thousand feet.

"Offline support" means at least three different things

They are sold with the same word and they behave nothing alike.

Offline-tolerant. The app needs the network but degrades politely. It caches what you looked at recently, lets you read it, and queues edits. Works fine on a train with patchy signal. Falls apart on a two-week trip, or the moment the cache expires, or when you want something you have not opened in a month.

Offline-capable with sync. There is a real local copy of your data and a real local database. You can work fully offline for as long as you like, and changes reconcile when you reconnect. This is the good version of cloud software, and it is expensive to build, which is why it is rarer than the marketing suggests.

Local-first. There is no server in the loop at all. The database on your disk is not a cache of the truth; it is the truth. Offline is not a supported mode, because there is no other mode — the network was never involved.

The difference only shows up under pressure. All three feel identical on a good connection, which is precisely why people find out which one they bought at the worst possible moment.

The four-second test, done properly

Turn off wifi. Then, in order:

Open the app cold. Quit it first — an app that is already running may be showing you memory, not disk. If the launch hangs on a spinner, you have learned the most important thing there is to learn about it.

Open something you have not touched in months. This is the real test, and the one people skip. Recent notes are cached almost everywhere; the note from March is what separates a local copy from a local cache.

Search for a word inside a note, not in its title. Full-text search is often the first thing to go, because in a lot of apps the index lives on the server. An app that can show you a note but cannot find it offline has given you a filing cabinet with the drawers welded shut.

Write something, then quit and reopen. Did it survive? Some apps accept typing while offline and lose it on relaunch, which is worse than refusing the edit, because you were told nothing.

Check the small things. Search, attachments, images in notes, the calendar, the clipboard history, whatever else you rely on. Attachments are the usual casualty: the text is local, the image is a URL.

Five minutes, once. It tells you more about an app than a fortnight of using it well-connected.

Why this is not really about planes

Everybody frames offline as a travel feature and that undersells it badly. Flights are the least common case.

The common cases are ordinary. A hotel captive portal that wants a room number you do not have. A conference wifi that authenticates for eleven minutes at a time. A train through a valley. The morning your home connection is out and you need the note with the account number in it, on the machine in front of you, to make the call about the connection being out. A café network so bad that the app is technically connected and therefore refuses to admit it is offline — which is the worst state of all, because a connected-but-useless app usually has no offline mode to fall into.

There is also the version with no network involved at all: a company that goes under, an account locked by an automated system, a service that decides your region is no longer supported. Those look nothing like a flight and produce exactly the same screen. I have written about what happens when the app itself shuts down — offline capability is the same property, tested by a different failure.

What working offline should feel like

Not "a limited mode". Nothing at all.

If offline is genuinely handled, turning the wifi off changes nothing you can see. No banner, no reduced feature set, no read-only state, no queue counter. You do not find out the connection dropped, because the app was never asking.

That is the actual bar. Any visible offline experience — however well designed — is telling you that the app's normal state involves a server, and that you are currently in the fallback. Sometimes that is a fine trade for sync and sharing, and an account genuinely buys you things. But it should be a trade you made knowingly, not one you discover in an airport.

The trade you are making

Being honest about the other side, since a page arguing for local-first has an obvious incentive not to be.

No network means no sync. Your notes are on this machine, and if you want them on your phone you need to do something deliberate about it — an export, a file in a folder you sync yourself, or accepting that the phone is not part of the system. It means no collaboration: nobody else can see or edit anything. And it means backups are entirely your job, because there is no server quietly keeping a copy of everything for you. That last one is the real cost, and it is why backups deserve their own five minutes.

If your life genuinely runs across three devices and two other people, offline-capable-with-sync is the shape you want, and paying for it is reasonable. The mistake is paying for offline-tolerant while believing you bought one of the other two.

The honest version

Run the test. Whatever you use, and especially if it is something you have trusted for years without checking. It costs five minutes, and the answer is a fact about your own setup rather than a claim from a marketing page.

Cyanote is the third kind. Everything — notes, tasks, the board, the calendar, habits, routines, the clipboard history — lives in one SQLite database on your own disk, and the app draws every screen from it. Exactly three requests ever leave the machine: a one-time licence check when you first install, an anonymous update check, and a calendar feed if you subscribe to one. None of them carries a word you have written, and none of them is needed to open the app, search it, or write in it. With the wifi off, nothing changes and nothing tells you it has.

If your notes are encrypted, on your own machine, with no account and no password written down anywhere, then when you are gone they are gone. That is not a bug — it is precisely the guarantee you were buying. It just has a second consequence that nobody mentions on the marketing page.

Two things people usually want, and they conflict

Some of it should survive. Not the diary. The practical layer: where the accounts are, what the passwords protect, the family history you were the only one who knew, the instructions for the boiler, the letter you meant to leave, the work someone else needs to continue.

Some of it should not. The journal. The half-formed opinions about people. The things you wrote to think rather than to communicate. Most people, asked directly, do not want everything they ever privately wrote read by their family in a difficult week.

Those pull in opposite directions, which is why "just give someone the password" is not a complete answer, and why the whole question tends to get dropped.

The three arrangements

Cloud accounts have a mechanism, of a sort. Apple has a Legacy Contact, Google has Inactive Account Manager. Both let you nominate someone who can gain access after a process. They are genuinely useful and worth setting up if your material is there. They are also all-or-nothing at the account level, they take time, and the process is a bureaucratic one at the worst possible moment.

Local and unencrypted is the accidental default, and it mostly works. If your notes are a database or a folder of files on a machine at home, whoever has the machine and its password has the notes. That is a real answer, if imperfect — it depends on someone knowing the machine matters, and on the disk password being available.

Local and encrypted is the one that needs a decision. Full-disk encryption, an encrypted database, or locked individual notes. Without the key, the data is unrecoverable by anyone, including you, including a specialist. That is the guarantee. It also means the practical layer above dies with you unless you did something deliberate.

What to actually do

Twenty minutes, once, and it is mostly not about notes software.

Use a password manager with an emergency access feature. This is the single most effective step, and it solves the general problem rather than the notes-specific one. Most of the serious password managers offer a recovery contact who can request access, with a waiting period during which you can decline — which handles both the "someone needs in" and "not right now" cases. Your disk password and your notes password go in there.

Write a one-page "where things are" document, and print it. Not encrypted, not in the system it describes. Where the machine is, that there is a password manager, who has emergency access, where the backups are, which accounts matter. It should contain no passwords — it is a map, not a key. Put it with your will, or wherever your important papers live.

Decide, explicitly, what you want read. If there is a journal you would rather nobody read, say so in that document, in a sentence. People overwhelmingly respect a stated wish and are left guessing without one. If you want it destroyed, say that too.

Keep the practical layer separate from the private layer. This is the notes-specific part and it is easy: the household information, the account map, the family history — the things you would want to survive — should be in an unlocked note, or an export, or on paper. The journal can be locked. Encryption is a per-note decision in a lot of software, which means the split costs nothing.

Tell one person the machine matters. A surprising amount of digital material is lost simply because nobody knew to look. "There is stuff on the Mac and there is a note in the file with the will" is enough.

The part specific to local-first software

If you have chosen local software for privacy reasons, you have made a real trade and it is worth completing.

There is no company to write to. No support process, no legal request, no account recovery. Nobody can be persuaded to help, because there is no one in a position to. Every route runs through the machine, the disk password, and whatever you wrote down.

The compensating advantage is that it is entirely in your hands and requires nobody's cooperation. An export sitting on an external drive in a drawer, or printed, is readable forever by whoever finds it — no account, no service, no login. That is a genuinely better inheritance than a subscription somebody has to argue their way into, and it is the same property that protects you when a company disappears, applied to the other kind of ending.

The version for people who will not do any of this

Realistically, most people will not do the twenty minutes. So, the one thing:

Set up emergency access in your password manager. That is it. If your disk password is in there, everything else follows — the machine opens, the notes are readable, whoever needs to get in can. Ten minutes, and it covers the general case and not only your notes.

If you do a second thing, print the one-page map.

The honest version

There is a version of this post that is a sales argument, and it should not be, so plainly: no notes app solves this. It is a password manager question and a piece-of-paper question, and the software you write in is nearly irrelevant to it.

What the software determines is only how many routes exist. Cloud accounts have a slow official route. Local and unencrypted has an informal one. Local and encrypted has exactly one route, and it is the one you set up in advance.

Cyanote is the third kind: one SQLite database on your own Mac, and any note can be locked with a password and is encrypted where it sits. There is no account to recover, no legacy contact, and nobody here who could help — which is the guarantee working as intended. What it does give you is a readable JSON export of everything, which is the thing to put on an external drive in a drawer, and per-note locking, so the practical layer can stay open while the private one does not.

The useful version is much smaller. In practice, four shortcuts carry nearly all the value in any app of this kind, and everything past those four is a rounding error you can pick up over years or never.

Why the mouse costs more than it looks

Not because moving your hand is slow. It is about a second, and a second is nothing.

The cost is that reaching for the mouse breaks the sentence. You were mid-thought, the thought needed a new note, and getting there involved leaving the keyboard, finding a target, clicking it, and coming back. The thought survives that about two thirds of the time.

Which is the same argument as an app that opens instantly: the loss is not measured in seconds, it is measured in the things that did not get written down because the route to writing them involved a detour.

The four that matter

A command palette. One shortcut, type a few letters, go anywhere — a note by name, a page, a setting. This is the single highest-value key in any modern app, because it collapses the entire navigation surface into one thing you already know how to use: typing. Almost universally ⌘K.

Search across everything. Distinct from the palette, and worth its own key. The palette finds things by name; search finds them by what is inside them. Usually ⇧⌘F. Both matter for different questions, and having one bound to the other's job is a common small frustration.

New thing, immediately. ⌘N. The distance between "I should write that down" and a cursor blinking in an empty note is the most important measurement in the app, and this key is most of it.

A slash menu inside the editor. Type / and reach every block type — heading, list, table, code, callout, toggle, image — without a toolbar. This is the one that makes formatting keyboard-native rather than keyboard-adjacent, and it is the difference between writing a structured note without lifting your hands and writing a plain one because the alternative was a mouse trip to a toolbar.

Those four, and you are effectively keyboard-driven. Anything else you learn is optimisation.

The ones worth adding later

Once the four are automatic, these earn their place — and not before, because learning them alongside the first four is how people end up learning none.

Today's note. A key that opens or creates today's daily note removes the last decision from capture: there is always somewhere to put a thing, and no thought about where.

Focus mode. Hide the sidebar and the chrome. Small, and it changes how the app feels to write in for long stretches.

Back and forward. Once notes link to each other, navigation becomes browsing, and browsing without back is miserable.

Find within the note. ⌘F, distinct from searching everything. Obvious in retrospect, frequently overlooked.

Global hotkeys are a different category

A shortcut inside an app only works when the app is in front. A global one works from anywhere, and that difference is bigger than it sounds — a global key means the app can do something for you without you going to it.

The clearest example is clipboard history: a key that opens a small window over whatever you are in, lets you pick, pastes into that app and gives the foreground back. You never visited the notes app; it visited you. That is the whole design requirement for anything meant to be used mid-task.

Two cautions. Global hotkeys are a scarce shared resource — every app on your Mac is competing for the same combinations, and a conflict presents as one of them silently not working, which is a genuinely annoying thing to debug. And any app that can paste into another app needs macOS Accessibility permission to do it, which is a real permission you should understand before granting.

Anything global should be rebindable. If it is not, one conflict is unfixable.

How to actually learn four keys

Not by reading the list. By having a rule.

Pick one, use it for a week, ignore the rest. One key per week means four weeks to keyboard-driven, which is a slower schedule than anyone wants and the only one that works.

When you catch yourself reaching for the mouse, stop and look up the key for that one action. Once. Immediate, specific, in context — this is how nearly every shortcut anyone actually knows was learned.

Bind the ones you have to think about. If a default combination is awkward on your keyboard or your layout, change it. A shortcut you have to contort your hand for is a shortcut you will not use, and there is no prize for keeping the defaults.

Do not learn a shortcut for something you do monthly. Genuinely. The mouse is fine for rare things, and cluttering your memory with rare bindings is what makes people give up on shortcuts altogether.

The honest version

Keyboard-driven is not a virtue in itself, and there is a strain of this that tips into performance — people who have memorised sixty bindings and are not writing more than anyone else.

The reason it matters at all is narrow: the gap between having a thought and having somewhere to put it. Four keys close that gap. Sixty do not close it any further.

Cyanote is built for those four: ⌘K for the command palette, ⇧⌘F for full-text search across every note, ⌘N for a new one, and / inside the editor for every block type — headings, lists, quotes, tables, tick boxes, images, callouts, toggles, code with syntax highlighting. Then ⇧⌘D for today's daily note, ⌘\ for focus mode, ⌥← and ⌥→ for back and forward. Three hotkeys work from any app on the Mac: ⌥⇧V for clipboard history, ⌥⇧B for pinned snippets, ⌥⇧C to bring the window to the front. All of them are rebindable in Settings, because a shortcut you cannot change is a shortcut somebody else chose.

Something occurs to you. You have about four seconds of willingness before the thought is gone and you are doing something else. In those four seconds a good app takes a sentence. A bad one takes a sentence, a date picker, a dropdown for priority, a project selector and a save button.

The four seconds are not negotiable. Everything else in the design has to fit inside them.

What natural-language entry actually is

You type pay rent tomorrow 9am !high into one field. The app reads the words, pulls out the date, the time and the priority, and creates a task called "Pay rent" due at nine tomorrow morning, marked high.

That is the entire feature, and it sounds like a convenience. It is not. It is the difference between a to-do list that gets used and one that gets abandoned, because it collapses five interactions into one and lands the whole thing inside the four seconds.

The alternative is not "slightly slower". The alternative is that you skip the date, because the date is another two clicks, and a task with no date is a task that does not appear on any day, which means the list becomes a graveyard of undated intentions and you stop trusting it. Undated tasks are how to-do lists die.

Why it also breaks things

Every parser is a guess, and the guesses fail in a specific, annoying way.

You type call Mark about the May figures and the app helpfully schedules it for 1 May. You type read the March report and it does the same. The word was part of the thing, not part of the schedule, and the app cannot tell — English does not mark the difference.

This is the failure that makes people turn natural-language entry off, and the fix is not a better parser. It is visible, reversible parsing. The app shows you what it extracted, as something you can see and dismiss — a chip, a highlight, a token in the field — before or right after the task is created. Then a wrong guess costs one click to undo instead of a task that silently shows up on the wrong day in six weeks.

Compare that with the invisible version, which quietly rewrites the title and tells you nothing. That app is not faster. It is faster and occasionally wrong in a way you will find out about later, which is worse than slow.

The grammar worth learning

There is a small vocabulary that most apps agree on, and it is worth ten minutes because it covers nearly everything.

Two habits make the difference in practice. Put the schedule at the end — parsers are most reliable on trailing date phrases, and it keeps the words at the start as the actual title. And write the title as a verb phrase: "Pay rent", not "Rent". A list of nouns is a list of topics; a list of verbs is a list of things you can start.

Where the task goes afterwards matters as much

Fast capture into a bad list is just a faster way to build a pile.

What makes the pile navigable is grouping by when, not by project. Overdue, today, this week, later. That ordering answers the only question you have when you open a to-do list on a Tuesday morning, which is "what is actually mine today". Project grouping answers a question you ask once a week, at most, and it is the wrong default for the other six days.

The same tasks seen a different way is a separate and legitimate need — that is what a board is for, and I have written about running a personal kanban board without turning it into project management. The point is that both views should be the same tasks, not two lists you maintain.

What to check before you commit

• Does it show you what it parsed? The single most important question. Invisible parsing is a slow-motion trust problem.
• Can you dismiss one part and keep the rest? Wrong date, right priority, should be one click — not "clear and retype".
• What happens with no schedule at all? Typing a bare sentence and pressing return should produce a plain undated task, not an error and not a form.
• Does the reminder follow the task, or is it separate? In some apps a due date and a reminder are two different fields, which means every genuinely time-sensitive task takes two passes.
• Is capture reachable from anywhere? A capture box that requires the app to be in front of you is capture that will not happen during the four seconds.

The honest version

If you run serious project management — dependencies, delegation, cross-project rollups, other people's tasks — a general app's to-do list is not the tool, and pretending otherwise wastes your month. Things and OmniFocus have spent well over a decade on exactly this on Apple platforms, and their parsers, their review flows and their project models are deeper than anything bundled into a notes app will be.

What the bundled version is for is the far more common case: a few dozen personal tasks, most of them small, most of them attached to something you were already writing down. In that case the deciding feature is not the project model. It is whether typing one sentence produces a task on the right day.

Cyanote parses the sentence as you type it — date, time and priority lifted out of the words and shown as chips you can dismiss — and drops the task into a list grouped by when things are due, with the same tasks available as cards on a board. Reminders sit on the task rather than beside it. It all lives in one SQLite database on your own Mac, with no account, which means the four seconds never include waiting for a server.

A second Mac is different. You write on both, you think on both, and a note started on one and needed on the other is not an edge case, it is Tuesday. The workarounds that cover a phone do not cover this, and pretending otherwise wastes your time.

First, the question that decides it

Do you use both machines in the same week, or in different weeks?

Same week — desktop at the desk, laptop on the sofa, both most days — and you genuinely need sync. Nothing below is adequate, and buying software that syncs is the right decision. Say so early rather than fighting it for a month.

Different weeks — the desktop is where work happens and the laptop comes out when travelling, or a work machine and a personal machine with a hard line between them — and you do not have a sync problem. You have a handover problem, which is much easier, and the arrangements below solve it.

Most two-Mac setups are the second kind and are treated as the first, which is where the frustration comes from.

The four arrangements

One machine is the home, the other borrows. The desktop holds everything. Before a trip, export or copy across what you will need; when you get back, bring the new material over. Deliberate, unglamorous, and it fails exactly once — the time you forget, and need the note you did not bring.

Split by domain, not by device. Work on the work machine, personal on the personal one, and no attempt to unify. This is the arrangement most people who have solved it actually use, and its strength is that the split is real rather than administrative: your employment contract and your privacy both point the same way. The rule to hold is that nothing lives in two places, because two half-collections is the worst outcome available.

A file you carry. The whole collection exports to one file; the file lives on a USB stick, an external SSD, or your own server. Copy it over, work, copy it back. This is the arrangement everyone thinks is primitive and it is genuinely fine for handover — a single file, moved deliberately, with no ambiguity about which copy is current.

Actual sync, from something built for it. Obsidian syncs a folder of files. Apple Notes syncs through iCloud. Notion is a browser away. If you are in the same-week case, this is the answer and it is not a compromise.

The one thing not to do

Do not put a live app database in iCloud Drive or Dropbox and call it sync.

It is the obvious move and it is the one that corrupts data. A file-sync service copies whole files after they change; a database is written continuously, often in more than one file, with a journal that must stay consistent with the main file. Two machines writing to that arrangement produces either a conflicted copy or a silently chosen winner, and neither preserves a database's internal consistency.

The failure is not immediate, which is what makes it dangerous. It works for weeks. Then one day both machines were open, and you have two divergent versions and no way to merge them.

If an app lets you relocate its storage, moving it to an external disk is fine — one machine at a time, mounted deliberately. Moving it into a folder that two machines are actively syncing is a different thing entirely.

Making handover reliable

If you are in the handover case, three habits make it stop failing.

Have one direction at a time. Decide, out loud, which machine is authoritative right now. Ambiguity about which copy is current is the entire problem, and a rule as crude as "the laptop is authoritative while I am away" resolves it completely.

Do the copy at a fixed moment. Not when you remember — as part of packing, and as part of unpacking. Attaching it to something you already do is the difference between a habit that survives and one that does not, which is the same reason routines beat intentions.

Take the export anyway, on both machines, on a schedule. The handover copy is not a backup, and the moment you have two machines is the moment you will eventually overwrite the wrong one. A backup is a copy that does not change when the original does — the handover file changes constantly, which disqualifies it.

What you gain by not syncing

Worth stating, since this reads as a list of limitations.

There is no sync conflict, ever. Anyone who has used syncing notes software for years has a story about a note that became two notes, or a paragraph that vanished on one device, or a merge that ate an afternoon. That entire category of failure does not exist when there is one copy.

There is no account, no server holding your work, and no subscription tied to being able to open your own notes. And every machine opens instantly, because opening does not involve asking anything.

Those are real, and they are exactly what you are trading for the convenience of not thinking about which machine you are on. Whether the trade is good depends entirely on the answer to the question at the top.

The honest version

If you work on two Macs in the same week, buy software that syncs. That is the whole recommendation and no amount of discipline substitutes for it.

If your second machine is occasional — travel, a sofa, a job you keep separate — then handover is a smaller problem than sync, and treating it as a sync problem is what makes it feel unsolvable.

Cyanote is a single-machine app and does not pretend otherwise: one SQLite database on your own disk, no account, no sync service. What it gives you for handover is a JSON export of everything — notes, tasks, calendar, habits, routines, clipboard, images — that restores on another Mac, replacing what is there rather than merging into it, and writing a rescue copy of the old data first. Settings will also move the database wherever you want, including an external disk. That is a deliberate handover mechanism, and it is not a substitute for sync. The licence covers installing it on the computers you personally own, so the second Mac costs nothing extra.

You land. There is no data yet, or the eSIM has not activated, or you are in the one part of the airport with no signal. You need the address of where you are staying, which is in a confirmation email, in an app that wants to sync before it will show you anything. Or the booking reference, in a PDF you never downloaded. Or the code for the door, in a message thread you cannot load.

None of this is a hard problem. It is entirely a before you leave problem, and it takes twenty minutes.

The one-page note

Everything you might need at the moment you have no connection, in one note, on the device, in text.

Where you are staying. The full address, in the local language and script as well as your own — you may need to show it to a driver rather than read it. The check-in time, the door code, the host's phone number.

Every booking reference. Flight, train, hotel, car, tour. Just the strings. A reference number is twelve characters and it is what every desk actually asks for.

Departure details. Flight number, terminal, the time you need to leave. This is the one people assume they will remember and then do not, at 5am.

Two phone numbers. Whoever you are staying with, and whoever at home should know if something goes wrong.

Your insurance policy number and the claims line. The single most useful line in the note and the one most often missing. If you need it, you will need it under conditions where finding an email is not going to happen.

The embassy or consulate address. Thirty seconds to add, and it is the classic thing you cannot look up in the situation where you want it.

Anything with a code in it. Locker codes, entry codes, wifi passwords you were sent in advance.

One note, plain text, no images, no links to anything. Links are the failure — a note that says "see the confirmation email" is a note that does not work.

Why "it's in my email" fails

Three reasons, and they compound.

Mail apps sync on demand. The message is often not on the device until the app fetches it, and with no data, an old message may simply not be there.

Attachments especially. A PDF boarding pass or booking confirmation is frequently not downloaded until you tap it. That tap needs a connection.

Search is the wrong interface at that moment. You are standing up, holding a bag, in a queue. Scrolling a mail app for a confirmation from three weeks ago is not something you want to be doing then.

The same applies to any app that says it works offline. Offline-tolerant and offline-capable are different things, and the difference presents at exactly this moment.

The twenty minutes before you go

Write the note. Fifteen minutes, from the confirmations, once.

Screenshot the things that must be images. Boarding passes, QR codes, tickets. A screenshot lives in the photo library on the device and needs nothing. Do not rely on a wallet app you have not tested offline.

Download the offline map. Both Google Maps and Apple Maps can hold a region on the device. This is the highest-value single item on the list and it takes two minutes.

Turn off wifi and read your own note. The test. If anything is a link, a preview, or a "tap to load", fix it now. Five minutes, and it is the step that turns preparation into something you have verified.

Send the note to whoever is travelling with you, or to whoever at home should have it. Redundancy across people is worth more than redundancy across devices.

What goes in the calendar instead

The note is for lookups. The calendar is for anything with a time on it, and the distinction is worth keeping.

Flights, trains, check-in and check-out, anything booked for a specific hour. With the reference number in the event's notes, so the calendar entry is self-sufficient.

Two things worth knowing about calendars abroad:

Time zones. An event created at home for a local time abroad will shift if it was stored in your home zone. Check the day before you fly, not on the morning.

Subscribed calendars do not update offline. If your travel plans arrive in a subscribed feed, the events are only there if it refreshed before you lost signal. Anything critical should be an event you created, not one you are borrowing.

While you are there

The note is also where the trip gets recorded, which is a second use nobody plans for and everyone wants afterwards.

The address of the place you liked. You will not remember the name of the restaurant. Write it down at the table, in four words, while you are paying.

What you spent, roughly. Not accounting — a rough daily figure. It is the only way to know what a trip actually costs, and it makes the next one much easier to plan.

The name of the person who helped you. For the thank-you, or the review, or the next visit.

What went wrong. Read on the way home, before the next trip, this is worth more than any packing list on the internet, because it is about your mistakes rather than a stranger's.

All of that wants to be in the same note or a note next to it, in an app that works with the radios off and does not need you to log into anything.

The honest version

If you are travelling with data everywhere, roaming that works and a phone you trust, most of this is redundant and you will be fine. The advice is for the gap between landing and having a connection, and for the countries and situations where that gap is longer than an hour.

The version for people who will do one thing: write the address of where you are staying and the flight home in a plain note on the phone, and download the offline map. Those two cover most of what actually goes wrong.

Cyanote is the desk half of this — write the note, hold the trip's details, keep the record afterwards, all in a local database that works with the wifi off because nothing about it ever needed a connection. Events carry a time, a place and notes, and repeat if the trip does. There is no phone app, so the note itself has to travel: send it to yourself or export it before you go, which is the same handover question that applies to any single-machine setup — and worth doing deliberately, since a travel note is precisely the kind you need somewhere other than your desk.

Some have been open for weeks. At least one is a thing you were going to buy in March. You have started opening new windows because the old one is full, and there are now three windows in the same condition.

This is not a browser problem. Open tabs are a to-do list — with no dates, no priorities, no search, and a permanent memory cost — and treating them as a browser problem is why every solution so far has failed.

The four reasons a tab is open

Every tab is one of these, and the fix is different for each. Naming which one is most of the work.

It is a task. "Cancel this", "reply to this", "buy this". You kept it open because closing it would lose the intention.

It is reference for something you are doing right now. Documentation, a spec, a page you are working from. Genuinely in use, genuinely temporary.

It is something you want to read. An article, a long post, a thing someone linked. You will not read it today and you both know it.

It is a fact you might need. A booking, a code, a piece of information you will want to look up once.

The reason tab managers fail is that they treat all four as one kind of object — a saved link — when three of the four are not links at all. A task is a task. A fact is a note. Only the reading list is genuinely a list of links.

The fix for each

Tasks become tasks. With a date. "Cancel the gym membership, Friday." One sentence, thirty seconds, and the tab closes. This is usually a third of your tabs, and it is the category where the browser is doing the worst job — a task with no date and no list is not tracked, it is just visible, and visibility is not tracking.

Reference stays open, and closes when the work does. This is the legitimate use and it needs no system. The rule that helps: when you finish the piece of work, close its tabs, deliberately. It is the same reason a shutdown routine works — a closing ritual is what stops today's context becoming tomorrow's clutter.

Reading goes on one list, and the list gets pruned. Not bookmarks, which is where links go to die alphabetically. One note, or a read-later service, and — this is the part everyone skips — an eviction rule. Anything on it for six months that you have not read, delete. You are not going to read it. The list works only if it is short enough to look at, which is the same lesson as a someday list.

Facts become notes, in text. Copy the booking reference, the code, the address into a note. Do not keep the tab. A tab is a pointer to a page that may need a login, may change, may go away, and definitely needs a connection. Four words of text is more durable than the page they came from.

Why bookmarks did not solve this

Everyone has tried. Bookmarks fail for three specific reasons and it is worth knowing them, because they apply to any "save it for later" mechanism.

They are write-only. Things go in and nobody looks. A bookmark folder from 2021 is not a resource, it is sediment.

They preserve the link, not the reason. Six months later you have a URL and no idea why you saved it. The reason was the valuable part and it was never recorded.

They are not in the flow of anything. You do not open your bookmarks while working. You open your notes and your task list, which is exactly why the four categories should go there instead.

The fix for all three is the same: save the reason, not the link. One line of what it was and why, with the URL underneath. That is a note, and it is searchable, and it makes sense in a year.

The one-pass method

Twenty minutes, once. Not tab by tab — that is where people stall, because deciding forty times is exhausting.

Go through and sort into the four buckets, without acting. Fast. Task, reference, reading, fact.

Then act by bucket. All the tasks at once — a dated task each, close them. All the facts at once — one note, close them. Reading goes on one list. Reference stays.

Then close the window. Genuinely. The remaining tabs after this exercise are usually four or five.

Batching by category is the trick. Sorting is fast; deciding what to do is slow, and doing it once per category rather than once per tab is the difference between twenty minutes and never.

The memory question

Briefly, since it is the practical cost people notice.

Modern browsers suspend background tabs and reclaim most of the memory, so forty idle tabs cost far less than they used to — the "each tab is 300 MB" folklore is largely out of date. Where it still bites is on a machine with 8 GB running several other things, where the browser's share is competing with everything else.

The real cost is not memory anyway. It is that a window with forty tabs is unnavigable, so you open new windows, and now your working context is scattered across three of them. The friction is cognitive and it shows up as never quite knowing where anything is.

The honest version

You will do this and be back to thirty tabs within a fortnight. That is not failure — tabs accumulate because working generates them, and a browser with four tabs is a browser belonging to someone who is not doing much.

What changes permanently is the habit at the moment of opening: noticing that this tab is a task, and writing it as a task rather than leaving it open as a reminder. That one substitution keeps the count from becoming forty, and it takes thirty seconds each time.

Cyanote covers three of the four buckets in one window: tasks with a date lifted out of a typed sentence, notes for the facts and the reasons, and a list for the reading with everything searchable a year later by any word in it. The fourth bucket — the tabs you are genuinely working from — should stay open, and closing them when the work is done is the one part no software can do for you.

None of it is hard to type. That is exactly why it never gets fixed — each instance costs fifteen seconds, and fifteen seconds never feels like it justifies solving anything.

Why this is not the same as clipboard history

They look like one feature. They are opposites, and conflating them is why people install a clipboard manager and still retype their address.

Clipboard history is a record of the past. Everything you copied, newest first, mostly noise, occasionally the thing you copied twenty minutes ago and then overwrote. It answers "what did I copy earlier". Its defining property is that it fills up and scrolls away — that is the design working, since the whole point is recency.

Snippets are a chosen library. A small number of items you decided to keep, which do not scroll away, because they are not from anywhere. They answer "give me the thing I always need". Their defining property is stability.

Put them in the same list and each ruins the other: your address sinks under four hundred URLs within a day, and the history gets cluttered with pinned items that are not part of the story it is telling. The apps that get this right keep two lists with two shortcuts. The apps that get it wrong offer one list with a star icon, and nobody's address survives the month.

What actually belongs in a snippet library

The test is simple: would you be annoyed to lose it, and do you produce it from memory more than once a month?

That usually comes out as:

• Identity boilerplate. Address, phone number, company registration, VAT or tax number, bank details, the exact spelling of your own job title.
• Commands with flags. The ssh line, the ffmpeg incantation, the rsync with the trailing slash that matters. Anything you once spent an afternoon getting right.
• Replies you send often. Declining politely. Chasing an invoice. The onboarding paragraph every new client gets.
• Structural text. A meeting agenda skeleton, a commit message format, the standard header for a document.
• Things that are hard to type correctly. An em dash. A character your keyboard does not have. A long ID you would transpose two digits of.

Twelve to twenty items covers almost everyone. If your library reaches sixty, it has quietly become a notes app with worse search, and the items past twenty are ones you will never find in time to use.

What does not belong

Anything secret. Passwords, API keys, recovery codes. A snippet library is a convenience feature with a keyboard shortcut, usually stored in plain text, and reachable by anything running as you. Those belong in a password manager, which is built for exactly this and encrypts at rest. The convenience is not worth it, and the failure mode is not recoverable.

Worth knowing on the same subject: well-behaved clipboard managers on macOS honour the flag password managers set to mark a copy as private, so a copied password is not recorded in the history. That is the correct behaviour, and it is worth verifying in whatever you use — copy a password, then open the history and check it is not there.

Things that change. A snippet with last quarter's figures in it is a trap: it works perfectly, silently, with the wrong number.

Anything you would need to read before pasting. If you have to check the snippet is the right one, it is a note, not a snippet. Snippets are for text you trust without reading.

Snippets versus text expansion

Two mechanisms, and it is worth knowing which you want.

Text expansion replaces an abbreviation as you type: you type ;addr and your address appears. macOS has this built in under Keyboard settings, and dedicated tools go much further with variables, dates and fill-in fields. It is the fastest possible route — zero interruption, no window, no picking.

The cost is that you have to remember the abbreviation. For five items you use daily, you will. For twenty items you use monthly, you will not, and an expansion you cannot remember is an expansion that does not exist. There is also the occasional indignity of an abbreviation firing inside a real word.

A picker — a shortcut that opens a small window of your snippets, and you choose — costs one extra second and requires remembering nothing. That makes it the right shape for the long tail, and it degrades gracefully: if you cannot remember which snippet you want, you can look.

Most people who use both end up with expansion for the daily five and a picker for the rest.

The detail that decides whether you use it

Where the pasted text lands.

A snippet tool is used while you are in another app — the email, the terminal, the form. If picking a snippet means switching to the snippet app, copying, switching back, and pasting, you have replaced fifteen seconds of typing with fifteen seconds of window management and you will stop within a week.

The version that works: a global shortcut opens a small window over whatever you are in, you pick, it pastes into the app you were in, and that app is in front again with focus where you left it. No visible switch. It is the same design requirement as a clipboard history that comes to you rather than making you go to it — and it is the single thing worth testing before you commit to any tool in this category.

The honest version

If you want serious snippet management — variables, cursor positions, date maths, per-app rules, shared team libraries — a dedicated tool is the answer. TextExpander and Alfred have spent many years on this, and Raycast has a well-liked free tier that covers snippets and clipboard history together. None of that is being out-featured by a panel bundled into a notes app.

What the bundled version is for is the ordinary case: fifteen items, no variables, reachable without leaving what you were doing. That case is most people, and the deciding factor is not depth of features — it is whether the thing appears over your email and puts you back where you were.

Cyanote keeps the two lists separate and gives each its own shortcut: ⌥⇧V opens the clipboard history over whatever app you are in, ⌥⇧B opens pinned snippets, and both paste into that app and hand the foreground back. Copies your password manager marks as private are never recorded at all. Everything lives in the same local database as the notes, which means the snippet library is on your disk and in your backup rather than in a service.

The temptation is enormous and it is always the same: spend the afternoon setting it up properly. Build the folder structure. Decide the tag taxonomy. Make templates for everything. Import the old notes. Choose a theme, then a different theme.

That afternoon is the single most reliable predictor of abandoning the app by March, and the reason is not obvious.

Why the setup weekend kills it

You are designing for a collection that does not exist. Every structural decision made on day one is a guess about material you have not written yet. The guesses are usually wrong, and wrong structure is worse than none — it makes every subsequent capture a filing decision, and filing decisions are where systems die.

It front-loads all the pleasure. Setting up is genuinely enjoyable, and it produces the feeling of having done something. That feeling is spent before you have written anything, and what remains is the ordinary, unremarkable business of using the thing.

It creates sunk cost, which distorts judgement. Having spent six hours, you will persist with an arrangement that is not working, and then quit all at once rather than adjusting.

Importing everything makes it stale on day one. You now have a new app that already feels like the cluttered one you left. The archive can stay where it is; the working set is what needs to move, and it is a few hundred notes at most.

The ten-minute setup

Genuinely all of it.

Turn on the two things that affect comfort. Text size and theme, if the defaults are wrong for you. Two minutes, and it is the only settings work that pays back immediately because you will be looking at it for hours.

Learn one shortcut: new note. Not four. One. The others come later, one a week.

Make no folders and no tags. None. You do not yet know what the categories are, and search will cover you until you do.

Write one real note. Not a test note — an actual thing you needed to write down today. The first note being real rather than "Hello" matters more than it sounds; it makes the app a place where your work is rather than a thing you are evaluating.

Stop. That is the setup.

The first week

Use it for capture only, and refuse to organise.

Every time something needs writing down, write it. No folder, no tag, no decision about where. Let it pile up flat. This feels wrong to organised people and it is the whole point — you are collecting evidence about what you actually write, which is the only sound basis for any structure.

Notice two things while you do it:

What you write most. Almost everyone is surprised. People who thought they needed a project hierarchy discover that 80% of their notes are daily scratch. People who planned for daily notes find they mostly write reference material.

Where the friction is. The moment you thought "I should write this down" and did not. That specific friction is the thing worth fixing, and it is usually not what you expected — it is rarely a missing feature, and usually the app not being open, or capture requiring a decision.

Week two: add exactly one thing

Whatever the past week actually demanded. One.

If you kept losing things in the flat pile, add the minimum structure that fixes the specific loss — probably three or four groupings, not eleven. If you kept writing the same shape of note, make one template. If capture friction was the issue, fix that and nothing else.

One change, then another week of use. This is slower than a setup weekend and it produces a structure that fits, because every element of it was added in response to an actual failure rather than an imagined one.

The rule to hold for the first month: never add structure in anticipation. Only in response.

What to migrate, and when

Not in week one. Around week three, once you know the app is going to stick.

The last six months, and the notes you actually reference. Usually a few hundred at most, and often far fewer.

Not the archive. Leave it in the old app, or export it to a folder on disk where Spotlight will index it. It is still searchable; it just is not in the way. This is the single biggest difference between a new system that feels clean and one that feels like the old one with a new logo.

Take a full export of the old app regardless, whether or not you migrate. It costs an hour and it means the decision stays reversible, which is true of every move between apps.

The three-month test

The honest evaluation point. Not week two, when everything is new and you are enthusiastic; not week six, when the novelty has gone and everything feels slightly worse than it is.

At three months, ask:

Is everything in one place, or have second locations appeared? Second locations are the diagnostic. If things are also landing in phone notes, text files and messages to yourself, the app is failing at capture — and that will not be fixed by another app unless you can say specifically why.

Do you search, or do you browse? Searching means you trust that things are in there. Browsing usually means you do not.

Would you be annoyed to lose it? If yes, it has become your system. If not, three months of use has told you something.

The honest version

Everything above is really one instruction: use it before you design it. The structure that survives is discovered, not planned, and every hour spent planning is an hour spent guessing about material that does not exist.

If you have abandoned several apps, this is the change most likely to break the pattern — more than the choice of app itself, which is usually not what went wrong.

Cyanote is built to make the ten-minute version viable. There is nothing you have to set up: ⌘N for a new note, ⇧⌘D for today's, / inside the editor for any block type, and ⇧⌘F to search everything you have written, which is what lets you go without folders for as long as you like. Notes nest into sub-pages when you eventually want structure, and [[ links things without filing them. It opens in under a second from one local database on your own Mac — which matters most in exactly the first week, when the habit is either forming or not.

Nobody replaces a tool that is working. So the interesting question is not which app to try next. It is what keeps happening at around month three.

The cycle, and where it breaks

It is the same shape every time.

Weeks one and two: the honeymoon. Everything goes in. You migrate old material, build the structure, tune the settings. This is genuinely productive-feeling and it is mostly not work — it is setup, which is the most pleasant substitute for work ever invented.

Weeks three to six: real use. The novelty is gone and the app is now just where your things are. This is the only phase that matters, and it is the one nobody talks about, because there is nothing to say.

Week seven or so: the first gap. Something does not fit. A capture that is awkward, a view you want that does not exist, a small daily friction. You work around it.

Weeks eight to twelve: the drift. The workaround becomes a second place things live. Then a third. The system is now partially true, which is worse than not having one, because you cannot trust it — and an untrustworthy system is one you stop consulting.

Then: the search. Not a decision to quit. A comparison post, read casually. Then a trial. Then a weekend.

The break is always at the same place: the small friction that turned into a second location. Not a missing feature — a moment where the system stopped being the only place.

The three real causes

Capture friction. The thing that has to be cheap is putting something in. If capture costs more than a few seconds — a form, a decision about where it goes, an app that has to load — you will occasionally skip it, and every skip creates a second location. This is the cause in most cases, and it is why apps with elaborate structure lose to plain ones over a year.

A structure that outgrew the content. Eleven categories, four databases, a tagging taxonomy, all designed in week one for a collection that did not exist yet. Every new item now requires a filing decision, and filing decisions are the second most common reason people quietly stop.

Genuine misfit. Sometimes the app really is wrong: you write code and it mangles code, you need it on a phone and there is no phone app, you need collaboration and it is single-player. This is the honest reason to switch, and it is the rarest of the three.

The first two are not fixed by switching. They travel with you, get rebuilt in the new app during the honeymoon, and produce the same collapse at month three.

How to tell which one you have

Before the next migration, one afternoon of diagnosis. Cheaper than a weekend of setup.

Where are your things right now, actually? List every place something you wrote down currently lives. Notes app, phone notes, three text files on the desktop, a Slack DM to yourself, a notebook, an email draft. The length of that list is the real diagnostic — a person with five locations does not have an app problem.

What was the last thing you failed to write down? And why. "I was on a call and it would have taken too long" is capture friction. "I did not know which project it went under" is structure. "The app was not there" is misfit.

When did you last search rather than browse? If you never search, you may be maintaining a filing system whose only user does not use it.

What have you rebuilt in every app so far? That is your actual system, and it is portable. Everything else was decoration you can stop rebuilding.

What to do instead of switching

Cut the structure to nothing and see what you miss. One flat collection. Search instead of folders. Add structure back only where the absence genuinely hurt. Almost everyone ends up with far less than they had — the argument in folders, tags, or search, reached the empirical way.

Fix capture first, before anything else. Whatever the cheapest possible route into your system is, make it cheaper: a shortcut, a default place, a daily note that already exists so there is no decision about where. Capture is the load-bearing part.

Give up on it being complete. The pursuit of one place for everything is what generates the churn, because completeness is unachievable and every gap reads as failure. A system holding the 80% that matters, consistently, beats a system that held everything for six weeks.

Then wait. Do not evaluate a system in its honeymoon. Three months is the shortest interval that tells you anything.

When switching genuinely is right

To be clear, because "the problem is you" is a lazy answer and sometimes wrong.

Switch when the misfit is structural and specific: the app cannot hold what you write (code, long documents, images), it is not on a device you genuinely need, it costs money you would rather not spend on a subscription, it is slow enough that you avoid opening it, or the company is in trouble and your data needs to be somewhere it can leave.

Those are reasons. "I saw a video of someone's beautiful setup" is not a reason; it is the beginning of week one.

The honest version

The uncomfortable part is that most of the value in any of these apps is available in almost all of them, and the difference between the one you left and the one you are considering is smaller than the cost of moving. What varies is not capability but friction — how cheap capture is, how fast it opens, how little it asks of you before it accepts a sentence.

If you have abandoned four systems, the fifth is unlikely to be different unless something other than the logo changes.

Cyanote is built around exactly that diagnosis, which is why it is one window rather than five apps and why it opens in under a second: the two failure points are capture cost and things living in more than one place. It holds notes, tasks, a board, a calendar, habits, routines and clipboard history in a single local database with no account. It will not fix a structure problem you bring with you — nothing will — and if what you have been missing is a phone app or collaboration, it does not have those either. But if what keeps breaking is that writing something down was too expensive at the moment it occurred to you, that is the part it is designed around.

This is the common case, and it is not a discipline failure. Highlighting is a genuinely poor note-taking technique wearing the costume of a good one: it produces visible output, it feels like engagement, and it requires no thought at the moment it happens — which is precisely the problem, because the thinking is the part that makes a note worth having later.

Why highlights do not work

They record attention, not understanding. A highlight means "this seemed important for four seconds". Four seconds is not enough to know whether it is important, and by the time you find out, you have lost the context that would tell you.

They are the author's words. Which is why they read as inert later: you are looking at a sentence somebody else wrote, with none of the reason you cared about it. The thing you actually wanted to keep — what it connected to, what you disagreed with, what it changed — was never written down.

They scale badly in the wrong direction. A well-read year produces thousands of highlights, and a pile of thousands is not a resource. It is a second library, with worse search than the first one.

The export is the trap. Getting all your highlights into a notes app feels like completing the system. It is completing the collection, which was never the hard part. Nobody has ever been short of material.

The only reading note that works

One question, asked after you finish something: what would I tell someone about this?

Then write the answer, in your own words, in a few sentences. That is the whole method.

It works because it forces the two things highlighting skips. You have to have understood it, since you cannot summarise what you did not follow. And you have to compress it, which is where the actual thinking happens — deciding what mattered is the intellectual work, and a highlighter lets you skip it entirely.

The output is small. A book becomes a paragraph or two, maybe a page for something genuinely dense. That feels like too little to people who are used to fifty highlights per book, and it is worth more, because you will actually read it again.

What to write down while reading

Not nothing — but much less than the highlighting instinct wants.

The page number and one word. Enough to find your way back to something you want to think about, without stopping to think about it now. Reading and note-taking are different modes and doing both at once damages the reading.

Anything you disagreed with. Disagreement is the highest-value thing to capture, because it is where your existing model met a different one. It is also the thing that evaporates fastest — you will not remember, tomorrow, that you thought chapter four was wrong.

Anything that connected to something else you know. "This is the same argument as X." Those connections are the entire reason to read widely, and they are ephemeral.

Quotes, rarely. Save the exact words when the exact words matter — a definition, a formulation you could not improve. That is a handful per book, not fifty.

Cornell, and where the old methods still hold

The formats that survived from an era before software mostly survived for a reason.

Cornell notes split the page into a wide column for notes taken during, a narrow column for questions written after, and a summary at the bottom. The reason it works is the second pass: the cue column forces you to reread and ask what each part was for, which is retrieval practice rather than transcription. It was designed for lectures and it is equally good for a dense chapter.

A summary at the bottom is the part to keep even if you skip everything else. It is the same "what would I tell someone" question, given a fixed place to live.

The mistake people make importing these into software is reproducing the visual layout — two columns, a box — and dropping the discipline, which was never about layout. A plain note with your summary at the top does the same job. Layout is the least transferable part of any method.

Where reading notes should live

Not in their own app, and this is the practical part.

A reading note is only valuable when it turns up next to something else — when you are writing about a topic and the thing you read in March is right there. That happens if the notes are in the same collection as everything else you write, and it does not happen if they are in a dedicated reading app you open when you are being a Reader.

Two mechanics make the difference:

They have to be findable by content. You will not remember which book said the thing. You will remember a word from it. That is a full-text search question, and it is the whole retrieval story for reading notes.

They should link to the things they relate to. A reading note that mentions [[a project you are working on]] shows up on that project's page without you having filed it there. This is the one place the linking habit pays off fastest, because reading notes are exactly the material you cannot predict the future use of.

The honest version

If you are doing academic work — citations, page-accurate references, a bibliography that has to be correct — you want a reference manager, and Zotero is free, open-source and very good at exactly this. Nothing in a general notes app replaces it, and trying to run a dissertation out of a folder of paragraphs is a bad idea.

If you read to think rather than to cite, the method above is most of what there is, and it is unusually low-tech: one question, a few sentences, somewhere searchable.

Cyanote has Cornell and reading-note templates in the / menu, and both are meant as starting shapes rather than a system to adopt. Reading notes sit in the same collection as everything else, searchable by any word in them with ⇧⌘F, linkable with [[ so they surface next to whatever they relate to. It is all one database on your own disk, so a decade of reading notes stays yours regardless of what happens to any app — including this one.

Most people can produce almost nothing, from several hours of reading. Not because the material was worthless, but because reading without writing produces a sensation of being informed and very little retention, and the sensation is convincing enough that nobody investigates it.

The problem is not volume, and reading less does not by itself fix it. Reading four hours and retaining nothing and reading one hour and retaining nothing differ only in the hours.

The three failure modes

The scroll. Continuous partial reading, mostly headlines and openings, producing a general awareness that things are happening and no specific knowledge of any of it. The most common by a wide margin.

The saved pile. Read-later services and a folder of tabs. Saving feels like reading and it is a substitute for it — the pile grows, occasionally gets declared bankrupt, and produces roughly nothing over its lifetime. The same failure as an unpruned someday list.

Following without accumulating. You genuinely read about a topic, regularly, over years, and cannot say what your view is — because each piece was consumed in isolation and nothing ever built.

All three are the same missing step. Nothing is written down, so nothing accumulates.

One note per topic, not per article

The change that fixes it.

Do not save articles. Keep a note per thing you care about — three or four of them, not thirty — and add to it when you read something worth adding.

Two or three lines: what this piece claimed, whether it changed your view, and the source. Over a year that note is a genuinely informed position, assembled from a hundred small readings, in your own words. It is the thing you wanted when you started reading about the subject, and no reading list ever produces it.

The reason it works is that adding to a topic note forces the step reading skips: deciding what this piece actually said and whether you believe it. That decision is the whole of the value, and it takes about forty seconds.

What is worth writing down

Not summaries of the article — the article summarises itself and you can find it again.

Anything that changed your mind. The most valuable and the rarest. Note what you thought before, which is the part that evaporates.

A number worth remembering, with its source and date. Numbers without sources are how people end up confidently wrong.

A claim you want to check. Rather than accepting it or dismissing it, park it. This is the single best defence against absorbing something because it was stated confidently.

A connection to something else you know. Where understanding actually comes from — the same material an idea bank collects.

What you now think. One line, occasionally. Your view, dated. Rereading your own view from two years ago is unusually informative, and unavailable any other way.

The three-day rule

Practical filter for anything that is news rather than knowledge.

If it is genuinely important, it will still be there in three days, better reported, with the corrections already made. The first version of a breaking story is routinely wrong in details and sometimes in substance, and reading it costs attention and then costs it again when the accurate version appears.

Deliberately waiting produces a strictly better version of the same information at lower cost. It also removes most of the emotional weight, which is largely a function of immediacy rather than importance.

This is the single change with the biggest effect on how much reading feels like drowning.

Sources, briefly

Two observations, both unfashionable.

A small number of good sources beats a large number of any. Three or four things you actually read beats forty subscriptions you skim. The marginal source adds volume, not information, because sources overlap enormously.

Pull beats push, here as elsewhere. A feed reader you open is better than notifications that arrive, for the same reason it is true of reminders: pushed information arrives when you cannot think about it, and gets processed with the reflex rather than the attention.

The quarterly read-back

Fifteen minutes, and it is what turns notes into knowledge.

Read your topic notes. Three things happen: you find you know more than you thought, which is genuinely encouraging; you find predictions you made that were wrong, which is instructive and slightly uncomfortable; and you find the topics you have stopped adding to, which is a signal you have stopped caring about them and can stop reading about them.

That last one is how the list of things you follow stays small. Topics you no longer add to are topics you can drop, and dropping them is what makes room.

The honest version

Some reading is for pleasure and should not be processed at all. A novel, a good essay, something interesting for its own sake — writing notes about that is a way of turning enjoyment into homework, and it is why some people ruin reading for themselves.

This applies to the reading you do because you want to know something, and the test is simple: if you would be annoyed to have retained nothing, write something down. If you would not, do not.

Cyanote holds the topic notes: one per thing you follow, growing over months, searchable by any word in them years later with ⇧⌘F, and [[ links tying a topic to whatever else it turns out to touch. It has no reader, no feed and no clipper — the article stays where it is, and what you write about it is the part worth keeping. One local database on your own Mac, so a decade of your own views on things you cared about stays yours.

What changed is the software. Apps that shipped in 2018 assuming 8 GB was normal now assume 16, browsers hold more, Electron apps have multiplied on your dock, and macOS itself has grown. The result is a laptop that boots fine and feels terrible by 4pm, and an upgrade suggestion from everyone you ask.

Often the upgrade is not the answer. Sometimes it is. It is worth knowing which.

What is actually happening

Almost always memory pressure, which presents as everything being slow rather than one thing being slow — which is why it is hard to attribute and easy to blame the hardware.

When physical memory runs out, macOS compresses what it can and then swaps pages to the SSD. Compression is fast and mostly invisible. Swapping is not: a page fault that has to hit disk costs orders of magnitude more than one served from RAM, and when several apps are competing, you get the characteristic pattern where every click has a small delay attached.

Check it before diagnosing anything. Open Activity Monitor, go to the Memory tab, and look at the Memory Pressure graph at the bottom, not the numbers above it. Green means you are fine, whatever the figures say — high memory usage is healthy, since unused RAM is wasted RAM. Yellow means the system is working to keep up. Red means it is swapping, and red is your actual problem.

Then sort by Memory and read the list. It is usually four or five entries doing nearly all of it, and they are usually the same four or five on everyone's machine.

Where the memory goes

Browser tabs. Almost always first, by a wide margin, and the fix is free. Tab-suspension is built into Safari and Chrome to varying degrees, and closing forty tabs you have not read is more effective than any other change on this page.

Electron apps. Every app built on Electron ships its own copy of Chromium, so five such apps means five browsers resident. This is the single biggest lever most people have, because the same job can often be done by an app built on the system webview — which is what Tauri does, using WebKit that macOS is already running. Not a moral point about a framework: a point about how many copies of a rendering engine are in memory at once.

Things at login you forgot about. System Settings → General → Login Items. Most people find two or three they do not recognise and one they installed for a single task in 2022.

Photo and media libraries doing background work. Indexing, syncing, analysing. Usually finishes eventually. Usually.

What to look for in software for an older machine

Native or system-webview, not a bundled browser. The clearest single indicator. You can check: an app around 10–30 MB on disk is not shipping Chromium; one at 200 MB+ probably is.

No server on the critical path. Software that waits for a network response before drawing is slow on a fast machine and worse on a slow one, because the delays compound. An app that reads its own disk is fast on any hardware.

Reads what it needs, not everything. Apps that load an entire library into memory at launch get worse as your collection grows — the opposite of what you want on constrained hardware.

Stated minimum OS version. An app requiring the very newest macOS is one you will lose the moment your Mac stops getting updates. An app supporting a few versions back is one that has thought about machines like yours.

A real download rather than a store-only release. The Mac App Store enforces the current OS more aggressively; direct downloads more often keep older builds available.

What to do first, in order

Cheapest and most effective first.

Restart. Genuinely. Weeks of uptime with heavy apps leaves memory fragmented and swap full, and a restart is the fastest possible fix for a machine that has become sluggish over a fortnight.

Close tabs and quit what you are not using. Free, immediate, and usually enough.

Remove the login items you do not recognise. Every one is memory and startup time you are paying for continuously.

Replace your two heaviest Electron apps. Look at the Activity Monitor list, take the top two that are not the browser, and see whether a lighter equivalent exists. This is often the difference between yellow and green.

Check free disk space. Below roughly 10% free, swapping gets slower and the whole system suffers. This is a surprisingly common cause of "the Mac got slow" with no other explanation.

Then, and only then, consider RAM or a new machine. On any Mac with Apple Silicon and on most recent Intel models, memory is soldered and cannot be upgraded — so this step means a new machine, which is why it belongs last.

When it genuinely is the hardware

Being honest about the boundary, because "just optimise" is not always the answer.

No more security updates. Apple supports roughly the current and two previous macOS versions with security fixes. A Mac that cannot run any of those is a real risk if you use it online, and that is the one reason on this list that is not negotiable.

A spinning hard disk. Any Mac still on a mechanical drive is transformed by an SSD, and if it is a model where that is user-replaceable it is by far the cheapest upgrade available.

8 GB with a workload that genuinely needs more. Video, large photo libraries, virtual machines, containers, several IDEs. No amount of app selection fixes a real requirement.

A battery that is done. Cheap to replace, and it is worth knowing this is a battery problem rather than a speed one before you buy anything.

Short of those, a 2018 machine running deliberately chosen software is a perfectly good computer, and the pressure to replace it is coming mostly from other people's engineering decisions.

The honest version

Software bloat is a real transfer of cost: it moves the price of shipping quickly from the developer to whoever has to run it, and the people who feel that most are the ones who cannot casually replace a laptop. That is worth naming rather than treating as the natural order of things.

Cyanote is built with Tauri, so it draws through the WebView macOS already has rather than shipping its own browser, and it reads from one SQLite file on your disk rather than waiting on a server. It runs on macOS 12 Monterey and newer, as a universal binary covering both Apple Silicon and Intel — which is a deliberate floor rather than an accident, since a fair number of perfectly good Intel Macs are still doing daily work and there is no good reason to shut them out.

Search is the feature that quietly becomes the app. It is also, in most apps, the least designed part of it — a text field bolted to whatever the database happened to make easy.

Three different things get called "search"

They feel similar for the first hundred notes and diverge completely after that.

Title matching. You type "invo" and it shows every note with "invo" in its name. Fast, cheap to build, and useless the moment the thing you want was written inside a note called "Tuesday".

Substring matching. It scans the body text for the letters you typed. Better — it finds things — but it has no idea which result matters. Type "api" and you get sixty notes in the order they were created, including every one that happens to contain "rapidly" or "capital".

Ranked full-text search. The app has built an index of the words in every note, so it knows which notes contain your term, how often, and where. Results come back ordered by how well they match rather than by when you happened to write them. This is the one that still works at a thousand notes, and it is the one that costs real engineering to build.

The tell is what happens with two words. Type deploy staging into title matching and you get nothing. Into substring matching and you get everything containing that exact phrase, which is usually also nothing. Into a real full-text index and you get the notes containing both words, best first.

Why local search feels different from cloud search

This is not about which is technically superior. It is about latency, and latency changes behaviour.

When search runs on your own machine, the results can update between keystrokes, because there is nothing to wait for — no request, no round trip, no server deciding whether your session is still valid. You type three letters, glance, type a fourth, glance again. Search becomes something you do while thinking, and a search you can do while thinking gets used for questions you would never bother submitting a query for.

When the index lives on a server, every keystroke either costs a network round trip or the app waits for you to stop typing and press return. Neither is slow in the sense of being broken. Both make search a deliberate act — you have to decide it is worth it before you start. And a search you have to decide about is a search you often skip in favour of scrolling, or of just writing the thing down again.

That is the actual cost of a slow search box: not the seconds, but the notes you rewrite because finding the old one felt like more work than retyping it.

What you should be able to find

Worth checking before you commit two years of writing to something. In a lot of apps the answer to several of these is no, and you will not discover which ones until you need them.

• Words inside code blocks. Plenty of editors exclude them from the index, which is precisely backwards — a command with flags is the single most searchable-for thing anyone writes down.
• Text inside tick boxes and list items. Structured content sometimes lives outside the searchable body.
• Text in tables. Same problem, more often.
• Notes nested inside other notes. If sub-pages are their own documents, do they show up, and can you tell where they live?
• Notes you have locked. An encrypted note cannot be indexed in plain text without defeating the point. Most apps take the honest route — the content is not searchable while it is locked — but you should know that before you lock the note with the thing you will need to find.

The command palette is a different tool, and you want both

They get confused because they are both a text field that appears over the app.

A command palette — usually ⌘K — is for going somewhere you already know exists. You know the note is called "Rent", you press the shortcut, you type ren, you press return. It is navigation, and it should be judged on how few keystrokes get you there.

Search — usually ⇧⌘F — is for finding something whose location you have forgotten, using words that were in it. It is retrieval, and it should be judged on whether the right note is in the top three.

Apps that only ship one of these end up bending it into the other job, and it is always the palette that gets bent — you start typing half-remembered content into a box designed for names, and it politely returns nothing. If you are evaluating an app, try both questions: "take me to the note called X" and "find the note that mentioned X". Different questions. They want different boxes.

When search fails, it is usually not the search

The uncomfortable half of this. Once an app has real ranked full-text search, most remaining failures are notes that were written in a way nothing could find.

A note titled "Notes" containing "sorted it out, was the config thing" is unfindable by any technology, because it contains no word you will ever think to search for. The fix is not a better index. It is writing down the noun — the service name, the person, the error string, the invoice number — somewhere in the note, once. That is the whole discipline, and it takes about four extra words per note.

This is the same argument as folders, tags, or search: the structure you spend an afternoon building is worth less than the specific word you spend four seconds typing. Search rewards concrete nouns. Filing rewards nothing much.

What search still cannot do

Search matches words. It does not know what you meant.

If you are looking for "that thing about the thing" — you remember the shape of an idea but not one word that was in it — search will not save you. Neither will tags, honestly. What actually works is a different move: go to the date, or go to the note you know linked to it. Which is one of the better arguments for linking notes to each other rather than only filing them, and for keeping any kind of daily note at all.

Semantic search — where the app finds notes about the same idea in different words — solves some of this, and it is genuinely useful. It also, in every implementation I know of, involves sending your notes somewhere to be turned into embeddings, or running a model locally that adds a few hundred megabytes to the app. That is a real trade, not a free feature, and it is worth knowing which side of it an app has chosen before you assume the clever search is local.

The honest version

If your notes number in the low hundreds and you write them into folders you remember, title matching will not fail you and none of this matters. Apps with weak search are not badly made; they are made for a size of collection you may never exceed.

The moment it starts to matter is the moment you cannot remember whether you wrote something down at all. That is the question search is for, and it is the one that separates the three implementations above.

Cyanote indexes every note with SQLite's full-text engine, so ⇧⌘F searches the body of everything — prose, code blocks, tables, tick boxes, sub-pages — and ranks the results rather than listing them by date. ⌘K is the other box: it jumps to any page or note by name. Both run against a database on your own disk, which is why the results move while you are still typing, and why they still do it with the wifi off.

Two years later you open that note and there is a grey box with a broken-image icon, or the picture is there but the database is 40 MB and you cannot work out why the app got slow. Both outcomes come from the same decision, made by the app on your behalf on the day you pasted, which almost no app tells you about.

The three things an app can do with a pasted image

Store it in the database. The bytes go into the app's own storage, alongside the note. The image is now part of your collection: it backs up when the collection backs up, exports when it exports, and works with the wifi off forever. The cost is size — your database grows by the size of every image, and screenshots are not small.

Store it as a file, referenced by path. The image goes into a folder and the note points at it. Efficient, transparent, and fragile in one specific way: move or rename the folder and every reference breaks. Some apps handle this well with a managed attachments directory. Some just write the path you dragged from, which means your notes now depend on a Downloads folder you clear monthly.

Upload it and store a URL. Common in anything cloud-backed. The picture is on somebody's CDN and your note holds a link. The note is tiny. The picture is not yours, it needs a connection, it is gone if the account lapses, and any export you take is an export of links.

The tell for the third is the export: export a note with an image and open the result somewhere else. If the picture is there, you have one of the first two. If you get a URL or a broken box, you have the third, and every screenshot you have ever pasted is a tenancy rather than a possession.

Why this matters more than it sounds

Images in notes are disproportionately the evidence. The error message. The receipt. The whiteboard at the end of the meeting. The before-and-after. The screenshot of the thing somebody said before they said they had not said it.

Text you can usually reconstruct. Evidence you cannot — that whiteboard is wiped, that error was transient, that receipt is in a bin in another country. Which means the images in your notes are, item for item, often the least replaceable content you have, and they are the part most likely to be stored as a link to somebody else's server.

What to do about screenshot bloat

The real cost of the good options is size, and it is manageable.

Screenshot the region, not the screen. ⇧⌘4 and drag beats ⇧⌘3 by a large margin in file size, and produces a more useful picture — a screenshot of a whole 5K display, viewed later in a note, is a picture in which nothing is legible anyway.

Crop before pasting, not after. Most apps store what you pasted regardless of how you have cropped it in the editor afterwards. The display shrinks; the bytes do not.

Do not paste the picture when you want the text. An enormous share of stored screenshots are screenshots of text — an error, a config, a message. macOS can select text directly out of an image in Preview and Quick Look, so lifting the text out and pasting that gives you something far smaller and, more importantly, something search can find. A screenshot of an error message is invisible to search. The error message as text is findable forever.

Check the database size occasionally. Knowing where your data lives is what makes this a two-second check rather than a mystery. If it has doubled in a month, it is images, and it is almost always five or six enormous ones rather than a hundred small ones.

Alt text, briefly

Write a line describing the picture, in the note, next to it.

Not primarily for accessibility, though that matters if you ever share the note. For yourself: an image is unsearchable, so the only way a screenshot turns up in a search two years from now is if there are words near it. "Screenshot of the deploy failing on the cert renewal, 14 March" costs eight seconds and is the difference between an archive and a shoebox.

It is the same discipline as writing the noun down in the first place. Nothing can find what you did not write.

The one to be careful about

Screenshots contain more than you meant to capture.

A screenshot of an error also contains the browser tabs, the notification that arrived, the name of the customer in the sidebar, the internal URL, and your own name in the corner. Pasted into a personal note on your own machine, that is fine. Pasted into a note that later gets shared, exported to a client, or synced into a workspace with other people in it, it is a small disclosure you never made deliberately.

The habit worth having: crop to the thing, before pasting. It solves the size problem and this one at once.

The honest version

If your work is genuinely visual — design references, a research corpus of images, screenshots by the thousand — a notes app is not your image library and you want something built for it. Managing tens of gigabytes of pictures inside a notes database is a bad plan regardless of how well the app handles it.

For the ordinary case of a few images a week as evidence and context, the only thing that really matters is which of the three storage choices your app made, and you can find out in two minutes by exporting one note.

Cyanote stores images in the same local SQLite database as everything else. They are in the backup because the backup is the database, they are in the JSON export because the export includes them, and they render with the wifi off because nothing about them was ever a URL. Notes hold images inline alongside headings, tables, callouts and code, and the clipboard history keeps copied images as well as text — so a screenshot you took an hour ago and lost is still recoverable from ⌥⇧V.

That is the trap of the whole category. The tool is fine; the activity around the tool is the substitute.

The two things that work

Decades of research on learning converge on a short list, and two items on it account for most of the effect.

Retrieval practice. Trying to recall something, from an empty page, without looking. This is not a way of checking what you know — the act of retrieval is itself what strengthens the memory. Rereading feels much better and does much less, because recognition is easy and produces the sensation of knowing without the work.

Spacing. Reviewing at increasing intervals rather than in one sitting. A given amount of study time spread across a week beats the same time in one evening, reliably and by a wide margin. Cramming works for tomorrow and is close to worthless for the month after.

Everything else — highlighting, rereading, summarising while looking at the source, colour-coding, rewriting notes neatly — is either weak or is producing artefacts rather than learning. That includes making cards, which is preparation, not practice.

The version that needs no software

The blank page. Close the book. Write everything you can remember about the topic. Then open the book and mark what you missed.

That is retrieval practice, complete, and it is more effective than almost anything you can do with an app — because it forces recall of structure as well as facts, which is what an exam actually asks for and what a card-by-card deck never tests.

The gaps are the output. What you could not produce is exactly what to study, and it is a far better guide than your sense of which parts feel shaky, which is systematically wrong: things feel familiar because you have read them recently, not because you know them.

The three-question note. After a lecture or a chapter, write three questions the material answers — questions, not summaries — and answer them from memory a few days later. Ten minutes, and it is retrieval plus spacing with no system to maintain.

The teaching test. Explain it out loud, to a person or to the wall, without notes. The place where you get vague is the place you do not understand, and it is startlingly obvious when you hear yourself do it.

The spacing, without an algorithm

Spaced repetition software computes an optimal interval per card. That is genuinely clever and, for most people revising for one exam, more machinery than the problem needs.

The crude version captures nearly all of the benefit: review at one day, three days, a week, three weeks.

Write those four dates in when you first study a topic. Four dated entries, and the schedule is done — no algorithm, no daily queue, no deck to maintain, and no risk of the backlog that kills most SRS attempts. What that costs you is optimality per item. What it saves you is the entire apparatus, which is what people actually abandon.

The daily queue is the real failure mode of flashcard apps. Miss four days, come back to 300 due cards, feel the dread, and stop. A fixed schedule of four sessions has no backlog to accumulate.

Where flashcards genuinely are the right tool

Not never — for a specific shape of material.

Discrete pairs. Vocabulary in a new language. Anatomy. Drug names and doses. Kanji. Chemical symbols. Where the unit of knowledge really is one item mapped to one answer, cards are the correct representation and spaced repetition software is excellent.

Very large volumes over years. Medical school, a language you are learning indefinitely. When the collection is thousands of items and the horizon is years, the algorithm earns its complexity, and Anki is free, open source and has been the serious answer for a long time.

When you did not make the cards. A shared deck removes the card-making time, which was the part that was not learning anyway.

Where cards are the wrong tool is anything requiring understanding rather than recall: a proof, an argument, a system, why something happened. Chopping an explanation into forty question-answer pairs destroys the structure, and the structure was the thing worth learning.

Marking your own work honestly

The one discipline that decides whether any of this works.

When you recall something almost right, the temptation is to count it. Do not. "Nearly" is the state in which everything feels fine and nothing is retained. The value of retrieval practice comes from the difficulty, and grading yourself generously removes exactly the signal you were generating.

The same applies to the blank page. Mark it strictly, in a different colour, and keep the marked version. Three of those a week apart are a genuine record of progress — and unlike hours studied, they measure the thing you care about.

What notes are actually for here

Not for the revision itself, which happens on a blank page. For two other jobs.

The questions. Your list of "things this material answers", built as you go, is the source you test yourself from. It is the most reusable artefact of a course and it takes almost no time to accumulate.

The gap log. What you could not recall, each time. After three sessions, the items that appear all three times are your actual problem, and they are almost never the ones you would have guessed. This is the same pattern-across-entries effect: one session tells you little, five tell you exactly where to spend the last week.

Both want to be searchable and in the same place as the rest of your notes, because you will come back to them the following term, or the following year, in a state of having forgotten that you wrote them.

The honest version

If you are learning vocabulary or thousands of discrete facts, use Anki. It is free, it is very good, and nothing here is a substitute for it.

For everything else — understanding a subject, preparing for an exam that asks you to explain things, learning a field — the blank page plus four spaced sessions beats a deck you spent nine hours building, and it beats it on a fraction of the setup.

Cyanote holds the parts that are notes: a question list per topic, the gap log, the marked blank pages, all searchable with ⇧⌘F a year later. Habits give you a grid of the days you actually did a session rather than hours you meant to, and tasks take the four review dates out of a typed sentence. There is no spaced-repetition algorithm and no card system, because the four-date version is what the app is for — if you want an algorithm, Anki is a better answer and always will be.

Not ignored it deliberately. Read the shape of the banner, recognised the category, dismissed it — all before the words registered. Your hand did it. And once your hand can do it, the reminder is no longer a reminder. It is a small ambient tax you pay several times a day for nothing.

Nothing broke. It fired exactly as configured. That is the problem.

Why the decay is structural

Every notification you receive teaches you something about the next one. If the last twenty were things you already knew, did not need, or could not act on where you were standing, the twenty-first arrives pre-discounted.

The trap is that the systems decay in the direction of more. When something gets missed, the obvious fix is another reminder — earlier, or louder, or repeated. That works for about a week, and then the new reminders join the baseline and get discounted too. Now you have twice the volume and the same hit rate, and the only remaining move is another escalation.

Meanwhile every alert has a cost that does not show up anywhere. It arrives while you are doing something, and the interruption is paid whether or not the reminder was useful. A banner you dismiss in half a second costs considerably more than half a second of attention, and the ones for things you were never going to act on cost the same as the ones that matter.

The three questions that kill most of them

For every recurring alert you get, in order:

Could I act on this, here, when it arrives? If a reminder fires while you are on a train and the action requires a laptop, it is not a reminder. It is an anxiety generator with a schedule. Either move it to a time when you are at the laptop, or delete it — those are the only two honest options.

Did I already know? The reminder for the thing you think about every day is pure noise. It fires, you think "yes, I know", you dismiss. That loop is where the swipe reflex gets trained, and it is trained by the harmless ones.

What happens if this one never fires? Sometimes the answer is genuinely nothing. A habit you have kept for eight months does not need a nudge; it has become the thing the nudge was for. Reminders for established habits are the most-swiped category there is.

Most people's setups lose half their alerts to those three questions and get more reliable, because the survivors stop arriving in a crowd.

Push and pull are different tools

This is the distinction that fixes most of it, and almost no app makes it for you.

Push — a banner, a sound, a badge — is for things where the moment is the point. A call at four. A train at 18:12. Something in the oven. The defining feature is that being told later is worthless, which is what justifies the interruption.

Pull — a list you go and look at — is for everything else. What is due today. What is left this week. The three things you said you would do. None of that needs to interrupt you, because you will look at the list at a natural boundary anyway: starting the day, finishing a task, coming back from lunch.

The mistake nearly everyone makes is pushing pull-shaped information. "You have 6 tasks due today" as a banner at 9am does not help; you were going to open the list at 9am regardless. All it does is add one more thing to the pile your hand has learned to swipe.

Move everything that is not time-critical from push to pull and the remaining pushes start getting read again. That is the whole mechanism.

The lead time nobody tunes

Default reminder timing is usually fifteen minutes before, and fifteen minutes is wrong for almost everything.

The right lead time is however long it takes to do the thing that makes the event possible. For a video call, that is two minutes: open the link. For a meeting across town, it is however long the journey takes plus a margin. For something you need to have prepared for, the useful reminder is the night before, when you can still prepare — the one fifteen minutes beforehand only tells you it is too late.

Apps offer 5, 10, 30 minutes, an hour, a day. Those exist because they are the actual useful shapes: two of them are "get to the thing", two are "wrap up what you are doing first", and the day-ahead is "you need to prepare". Picking deliberately instead of accepting the default is a two-second decision that decides whether the alert is worth anything.

And for repeating events, check that the reminder repeats with it. A weekly meeting whose reminder only fired for the first occurrence is a specific and very common disappointment.

What to do with the ones you cannot act on

There is a category left over: reminders that fire at the right time about a real thing, which you nonetheless cannot do anything about right now.

The answer is not snooze. Snooze is how a task becomes a thing you dismiss six times, and by the sixth the app has taught you the item is optional.

The answer is a place to put it that you trust — one list, checked at a known moment. That is what makes the difference between deferring something and losing it, and it is the entire reason a weekly review is worth twenty minutes. If you have a reliable moment where everything deferred gets looked at again, you can dismiss an alert honestly rather than snoozing it dishonestly.

What a good setup looks like

Small enough to describe in five lines.

• Push, only for the clock. Events with a time, with a lead that matches what the event needs.
• Pull, for everything else. One view of today: what is scheduled, what is due, what is outstanding. You go to it.
• No reminders for established habits. If it is holding, the alert is noise. If it is not holding, the alert is not what was missing.
• No badges you have stopped reading. A number you have not acted on in a fortnight is decoration with anxiety attached.
• One place deferred things land, looked at on a schedule you actually keep.

That is a system that stays credible, and credibility is the only property that matters. A reminder is worth exactly as much as your willingness to read the next one.

The honest version

If your work genuinely is time-critical — on-call, clinical, operational, anything where the cost of missing something is high — you want more alerting, not less, and you want it escalating and redundant. This post is not for that. Escalation exists because sometimes the cost of interruption is the cheap side of the trade.

For an ordinary week, the failure is almost never a reminder that did not fire. It is thirty that did, of which four mattered.

Cyanote's version leans toward pull. Today shows the day's schedule, what is due, the habits still outstanding and the routines not yet run, with the next event counting down beside it — one place you look rather than a stream that arrives. Events remind at 5, 10 or 30 minutes, an hour or a day ahead, and a repeating event carries its reminder to every occurrence. Tasks take a due date and a reminder in the same sentence you type them in. All of it runs from a local database on your own Mac, which means the notifications come from your machine and nothing about your schedule is sitting on a server to be alerted from.

The claim is shakier than the consensus suggests. What research there is on polarity mostly points the other way for long-form reading — dark text on a light background tends to be read slightly faster and more accurately by people with typical vision, because a bright background contracts the pupil, which increases depth of field and sharpens what you are looking at. Light text on a dark background does the opposite, and it is why white-on-black text can look faintly bloomed or haloed, especially for anyone slightly short-sighted.

None of which means you should stop using dark mode. It means the reason to use it is not the one on the tin, and the settings that actually reduce evening eye strain are elsewhere.

What is actually tiring your eyes

Three things, in roughly this order.

Brightness mismatch with the room. A display at daytime brightness in a dark room is the single largest source of evening discomfort, and it is true in dark mode too — a "dark" interface with bright white text in a black room is still a small light in your face. Matching the screen to the ambient light does more than any colour scheme.

Not blinking. People blink dramatically less while reading a screen, which dries the eye surface and produces most of what gets called eye strain. No software setting fixes this. Looking away periodically does, which is what the twenty-twenty-twenty guidance is about — every twenty minutes, look at something about twenty feet away for twenty seconds. Unglamorous and more effective than any theme.

Contrast that is too high, or too low. Pure white on pure black is maximum contrast, and maximum is not optimal. Neither is grey-on-grey, which is the fashionable failure — text at 40% opacity looks elegant in a screenshot and is genuinely hard to read for a lot of people, particularly over 40.

Blue light, notably, is not on this list. A Cochrane review of 17 randomised trials covering 619 people across six countries, published in 2023, concluded that blue-light filtering spectacle lenses probably make no difference to eye strain from computer use or to sleep quality, and found no evidence they protect the retina. Lenses are not a screen filter, so that does not transfer directly — but it is the strongest evidence available on the underlying claim, and it does not support treating a warm-shifted display at night as anything more than a preference.

The settings that actually help

Text size, larger than you think. The most effective anti-strain setting there is, and the one people resist because larger text feels like an admission. Bumping the editor a point or two removes more strain than any palette change, and your eyes are not the same as they were at 25.

Line height, around 1.5. Tightly-leaded body text makes your eye lose its place returning to the start of the next line, and that reacquisition is fatiguing in a way that does not announce itself.

Line length, 60 to 80 characters. Text running the full width of a 27-inch display is the most common readability mistake in software, and it is severe. Every return sweep becomes a long journey across the screen with an opportunity to land on the wrong line. If an app offers a reading width or focus mode, this is what it is for.

Screen brightness matched to the room. Adjust it when the light changes rather than once a year. If you find yourself squinting, that is the setting, not the theme.

Those four cost nothing, apply in any app, and between them do most of the available work.

When dark mode genuinely is the answer

Not never — just for different reasons than advertised.

On OLED, true black is off. A pixel displaying pure black on an OLED emits no light at all. In a dark room that is a real, visible difference and not a subtle one, and it is the strongest argument for a true-black theme rather than a dark-grey one. Note that this only holds for actual #000000 — a "dark" theme using very dark grey lights every pixel.

For anything that is not long-form prose. Code, dashboards, terminals, image editing. Dark interfaces work well where you are scanning structure rather than reading paragraphs, and where a bright surround would compete with the content.

Because the room is dark. A large bright rectangle in a dark room is unpleasant regardless of the science, and reducing the lit area genuinely helps. This is a legitimate reason and probably the real one for most people.

Because you prefer it. Which is fine and needs no justification. Preference is a valid reason for a colour scheme; it just is not a health claim.

The middle options nobody uses

Light and dark are not the only two settings, and the in-between ones are often better for reading.

Sepia or cream. A warm off-white background at reduced luminance. Easier than pure white in a dim room, and it keeps dark-on-light polarity, which is where the readability advantage sits. This is what e-readers have offered for years and it remains underused on desktops.

Newsprint or paper tones. Slightly grey, slightly warm, low-glare. Good for long daytime reading on a bright display.

Reduced-contrast dark. Light grey text on dark grey rather than white on black. Keeps the dark-room benefit while removing the haloing that makes white-on-black uncomfortable.

If an app only offers light and dark, you are choosing between two extremes of a range where the useful settings are usually in the middle.

Per-document settings, briefly

Worth mentioning because almost nothing offers it and it is genuinely useful: the right typography for a page of prose is not the right typography for a code note. Prose wants a serif or a humanist sans, generous leading, a narrow measure. Code wants a monospace, tighter leading, and the full width.

Being able to set those per note rather than globally means you stop compromising between two things you do differently — the same argument as two modes for writing and code, applied to the type rather than the interface.

The honest version

If you have persistent eye strain, this is a question for an optometrist rather than a settings panel. Uncorrected astigmatism and an out-of-date prescription produce exactly the symptoms people attribute to their screens, and no theme fixes either.

For ordinary evening discomfort: turn the brightness down, make the text bigger, narrow the column, and pick whatever colours you like. That is genuinely the order of importance, and the colour scheme comes last.

Cyanote ships fifteen themes, each with a full light and dark palette checked for contrast — including Newsprint and Sepia for the middle ground, and Midnight in true black for OLED. Or you can set the seven colours the whole app is drawn from and build your own. Typeface, size and line spacing are settable for the editor and for the app around it, globally or per note, and ⌘\ hides the sidebar when you want the column and nothing else.

The method is not the problem. Time blocking works; people who do it get more of the important thing done. What fails is the specific plan, and it fails for reasons that are predictable enough to design around.

Why the plan dies

It was written with no information. At 8:45 you do not know what today contains. You know what is scheduled, which is a subset. The plan is a forecast made by someone who has not read the weather.

It is full to the edges. A day planned at 100% capacity has no room for the thing that arrives, and something always arrives. The first interruption does not cost you thirty minutes; it costs you the plan, because every subsequent block is now wrong and re-planning mid-morning is a thing nobody does.

It ignores what your energy actually does. Almost everyone plans as though attention is flat across eight hours. Yours is not. Putting the hardest thing at 3pm because that is where the gap was is planning against yourself.

It confuses a plan with a promise. Miss two blocks and the day reads as a failure, which makes tomorrow's plan feel pointless. A plan that can only be kept perfectly is a plan you will stop making.

The version that survives

Smaller than you want it to be.

Three things, not twelve. Name the three that would make today worth having. Everything else is whatever else happens. Three is achievable on a bad day and leaves room on a good one, and — crucially — you can hold three in your head without consulting anything.

One block, not a full grid. Protect one stretch for the hardest of the three. Not the whole day: one. A single defended ninety minutes beats a fully-blocked day that collapses at the second interruption, because it is small enough to reschedule rather than abandon.

Put the hard thing where your attention actually is. For most people that is earlier than they schedule it. You already know your own answer to this; the plan just needs to stop ignoring it.

Leave half the day unassigned. This feels like under-planning and it is the single change that makes plans survive. The unassigned half is not slack — it is where the meeting that got moved, the thing that took twice as long, and the request that arrived at 11 all go. Without it, they take a block instead.

The two-minute version

Long enough to be useful, short enough that you will keep doing it.

Look at what is already fixed. Meetings, appointments, anything with a time on it. Not from memory — from the calendar, because the whole failure mode is planning around a day you have half-remembered.

Look at what is due. Tasks with a date on them today, plus anything overdue. Again, not from memory.

Pick three. Written down, in the same place, so they are still there at 2pm when the morning has gone sideways and you have forgotten what today was supposed to be about.

Protect one block for the hardest one. In the calendar, as an actual event, so the hour is visibly gone when someone looks for a slot.

Two minutes. The reason it works is not the planning — it is that steps one and two replace guessing with looking.

What to do when it goes wrong by 11

It will. The question is only what happens next.

Do not re-plan the whole day. That is a twenty-minute job you will not do, and skipping it is what makes people declare the plan dead.

Ask one question: is the one block still possible today? If yes, move it and carry on. If no, decide now which of the three is being dropped, deliberately, rather than discovering at 6pm that it was all three.

Let the other two go without ceremony. A day where one of three important things happened is a normal good day. Treating that as failure is the thing that stops people planning at all, and it is a scoring error rather than a productivity one.

Where the plan should live

In the same place as the day it is planning.

If your calendar is in one app, your tasks in another, and your plan written in a third, then the plan was necessarily written from memory — you would have had to open three windows to write it accurately, and at 8:45 nobody does. That is the mechanical reason day plans are so often wrong about what the day contains, and it has nothing to do with willpower.

One view with the schedule, what is due and what is outstanding is not a nicer interface. It is the difference between a plan based on today and a plan based on your recollection of today, which is the same argument as keeping notes, tasks and the calendar in one window.

The honest version

If your days are genuinely dictated by other people — clinical shifts, back-to-back client work, anything where the calendar is not yours — planning is not the lever and this post will not help. The lever there is defending one block a week, not planning a day.

And if you have tried time blocking repeatedly and it keeps failing, the diagnosis is usually not that you need a better system. It is that the plans were too full. Try three things and one block for a fortnight before concluding anything about yourself.

Cyanote's Today view is the two-minute version made concrete: the day's schedule, what is due, the habits still outstanding and the routines not yet run, with the next event counting down beside it. Tasks take a date and a priority from the sentence you type them in, and a calendar block is an event you drag into place. All of it in one window and one local database on your own Mac — so the two minutes are two minutes of looking, rather than two minutes of opening things.

Wedding planning software exists and mostly consists of a checklist somebody else wrote, a budget spreadsheet, and a guest list. Two of those three you can do better yourself, and the third is not where things go wrong.

The three failures

A deadline nobody was tracking. Final numbers to the caterer. The deposit that secures the date. The point after which the deposit is non-refundable. Every supplier has one and they are stated once, early, in an email or on a call.

A detail agreed and not recorded. What the price includes. Whether they set up. What time they arrive. Whether the corkage was waived. These are agreed verbally, in a friendly conversation, and remembered differently by both parties four months later.

Everything landing in the last two weeks. Because most of the work genuinely can only be done then — final numbers, seating, timings, confirmations — and if the earlier work slipped, it lands there too, on top of a fortnight that was already full.

None of these is a budget problem. Budgets go over, and everyone survives that.

One note per supplier

Venue, caterer, photographer, music, flowers, transport, cake, hire company. One note each.

At the top: contact name and direct number, the reference, what has been paid and what remains, what is included, and their deadline — the date they need something from you. That last one is the most important line in the note and it is the thing suppliers state once and assume you have absorbed.

Below: dated entries after every conversation. What was discussed, what was agreed, what they committed to.

Same shape as a client note, because an event is a project with a dozen suppliers and one immovable date.

Write up every call, in four lines

The one discipline that carries the whole thing.

"Spoke to Anna, 14 August: confirmed 6pm arrival, setup included, final numbers by the 2nd, corkage waived for our own wine."

That sentence is worth more than the rest of your planning, because it converts a friendly verbal understanding into a dated record. Almost every event dispute is an honest difference in recollection between two people who both remember the conversation and remember it differently. A dated note settles it in ten seconds and without any unpleasantness — you are not producing evidence, you are checking your own memory out loud.

Email confirmation of anything significant is the belt to that braces: "just to confirm what we agreed". Suppliers are used to it and it costs one line.

Every supplier deadline in the calendar

The moment you learn it, as an event, with a reminder two weeks ahead.

Final numbers. Deposit dates. Balance-due dates. The point where the cancellation terms change. Anything the supplier needs from you, with their name on it.

Two weeks rather than a few days, because the response to most of these is not instant — final numbers need chasing the last four people, and the balance needs money to be moved. Notice you cannot act on is not notice.

The board, three columns

Waiting on me, waiting on them, done.

The point is the middle column. Events stall because a supplier has not come back and nobody is counting the days — the photographer was going to send the contract, three weeks ago. A board makes that visible in ten seconds, and a polite chase at day seven costs nothing and moves everything.

Keep everything on it, including the small things. The small things are what land in the last fortnight.

The timeline document

The single most useful artefact for the event itself, and the one people write last or not at all.

A minute-by-minute schedule for the day: who arrives when, who sets up what, when things start, who is responsible for each transition. Written in advance, sent to every supplier and to the two or three people helping.

The reason it matters is what it does to you. On the day, you cannot be the coordinator — you will be occupied, or getting married, or hosting. The timeline is what lets someone else answer questions without finding you, and the difference between an event where the host is repeatedly pulled aside and one where they are not is entirely this document.

Include phone numbers for every supplier on it. Whoever is holding it will need them and will not have them.

The last fortnight

Since this is where it concentrates, plan for it deliberately.

Write the final-fortnight list in advance, when you are calm, around the two-month mark. What has to happen in those two weeks, in order. Following a list you wrote calmly is much better than generating one under pressure — a routine rather than a memory task.

Confirm everything, in writing, ten days out. Every supplier, a short message restating date, time, place and what they are bringing. This is where you find the one who has you down for the wrong Saturday, and finding it at ten days is entirely recoverable.

Decide who is answering questions on the day, and tell the suppliers that name.

Afterwards

Twenty minutes, within the week, while it is fresh.

Who was good and who was not, with specifics. Friends will ask, and you will have forgotten by the time they do.

What it actually cost, all in. Nobody writes this down and everyone wishes they had.

What you would do differently. Vivid for about a fortnight and gone by the second month.

The honest version

Event-planning software is not bad, and if a checklist somebody else wrote reduces your anxiety, use one — that is a real benefit and worth something on its own.

What it does not do is hold the specific facts about your specific suppliers, which is where things go wrong. That is notes, a calendar and one board.

Cyanote covers those three in one window: a note per supplier with references and their deadlines at the top, a calendar with reminders a day or a week ahead for every deposit and cut-off, tasks that take their date out of a typed sentence, and a board with three columns for the chasing. Full-text search finds "what did the caterer say about corkage" in four seconds, six months later. It is one local database on your own Mac, which for a project involving your contracts, your payments and your guest list is where it should be.

I have done this a thousand times. Almost all of those times it was fine. The problem is that "almost all" is doing real work in that sentence, and the paste is never the thing you were paying attention to — you were debugging, the object was in the way, and the tool was a means of getting past it in four seconds.

What you are actually pasting

Take an honest inventory of what tends to end up in those boxes.

A JSON response with a customer's email, address and order history in it. A JWT — which is to say, a live credential, decoded on a page whose only claim is that it does it in the browser. A stack trace containing internal hostnames and file paths. A config file with the connection string still in it. A CSV a colleague sent you. Someone's phone number, because you were checking a regex against real data rather than making one up.

Nobody sets out to paste a customer record into a stranger's website. It happens because the tool is a text box and the thing in your clipboard is what you happen to be debugging.

"It all happens in your browser" — and the three ways that fails

Most of these sites say the processing is client-side, and most of them are telling the truth. It is a real and meaningful protection. It is also a promise you cannot verify at paste time, and it does not cover several things people assume it covers.

You cannot check it, and it can change. You could open the network tab and read the source — once, today. The site can ship different JavaScript tomorrow, to you specifically, and nothing about the page will look different. You are trusting a claim about code you are not reading, on every visit.

The page is not one party. A tool page pulling in analytics, an ad network, a tag manager and a font is running four other companies' code in the same document as your paste. Client-side processing says the tool does not send your data anywhere. It does not say the ad script in the same page cannot read the DOM, because it can.

Autosave and history. Plenty of these tools save your last input to local storage so it is there when you come back. Convenient, and it means the JWT is still sitting in the browser profile on a laptop that gets shared, imaged, or resold. Some have "share this" buttons that upload on click, one misclick away from a paste becoming a URL.

None of this makes the sites malicious. It makes the arrangement unverifiable, which for anything under an NDA or a data-protection policy is the same practical answer.

The part your employer's policy already says

Worth checking your own rules before assuming this is paranoia. Most organisations that handle personal data have a written line about not putting it into third-party services that have not been reviewed. A JSON formatter is a third-party service. It just does not feel like one, because it has no logo, no login and no invoice.

The same policy that would stop you emailing a customer export to a personal address is the one that covers pasting it into a page you found in a search result. The intent is identical. The friction is not, which is exactly why one happens constantly and the other does not.

The fix is boring

Do the operation on your own machine.

For a lot of these there is a command already installed. jq . formats and validates JSON. base64 -d decodes. pbpaste | ... reads the clipboard directly. If you live in a terminal, that is the whole answer and you can stop reading.

The reason people use websites anyway is not ignorance of jq. It is that the terminal version requires remembering the flag, and the website requires remembering nothing. For a four-second task, "remembering nothing" wins every time — which is a UI problem, not a security problem, and it is why telling people to just use the CLI has been failing for fifteen years.

The version that actually sticks is a local tool with a text box in it. Same shape as the website, same four seconds, same nothing-to-remember — but the text never leaves the machine, so there is no claim to verify.

The list worth having locally

The tools that come up over and over, in roughly the order people reach for them:

• JSON format and validate. The single most-pasted thing on the internet.
• Base64 encode and decode. Often on something that came out of a header.
• JWT decode. The one that should worry you most, because a JWT is a bearer credential and pasting it is handing over the credential, not a description of it.
• URL encode and decode, and a URL inspector for pulling a query string apart.
• A regex tester. Where real data gets pasted more than anywhere else, because made-up test data never has the edge case in it.
• Text compare. Two versions of a config, side by side.
• Case and line operations — sort, dedupe, join, split, trim.
• Invisible-character stripping. The fix for text copied out of a PDF or a chat client that looks identical and breaks a comparison.
• A timestamp converter. Because nobody reads epoch seconds on sight.

That is nine things. None of them is hard. Collectively they account for a startling share of what gets typed into a search bar during a workday.

The honest version

If you are formatting a JSON blob you generated yourself with no real data in it, a website is fine and the risk is genuinely zero. This is not an argument that those sites are dangerous; it is an argument that the habit is indiscriminate, and the habit does not check what is in the clipboard before it fires.

There are good local answers at every price. DevUtils and Boop are both well-liked Mac apps built for exactly this. If a dedicated one fits how you work, use it — this is a category where several people have done the job properly.

Cyanote has these on a Tools page, next to the notes: case and line operations, invisible-character stripping, text compare, Base64, URL and JWT encode and decode, JSON format and validate, a regex tester, a URL inspector and a timestamp converter. They are there because the paste usually happens two seconds after something got copied — which is also why the clipboard history sits in the same window. Nothing you type into them is sent anywhere, because the app has no server to send it to.

You can ask anything. Nobody expects you to know what the acronym means, why the deploy works that way, or who actually decides. That licence lasts about six weeks and then quietly expires, after which asking becomes a small admission.

And you can see the place clearly. You notice what is confusing, what is duplicated, what everybody works around. Within three months you will have stopped noticing, because you will have adapted — that is what adaptation is. The observations are not preserved by memory; they are overwritten by competence.

Both of those are worth capturing while they are available.

The four notes to start on day one

The glossary. Every acronym, product name, internal term, system name and shorthand, with what it means and who to ask. This will be the most-used note of your first two months and by far the highest return on effort. Nobody hands you this document because everybody already knows the words.

The map of people. Who does what, who reports where, who actually decides as opposed to who is nominally responsible, who to ask about which system, and one personal detail so you remember them as a person. Update it after every meeting where you learn something. The org chart is not this note.

The confusion log. Every time something does not make sense, one line. Not to complain — to preserve. This is the note with the expiry date on it, and it is the source of nearly everything useful you will contribute in month four, because by then you will understand the system well enough to fix the things you can no longer see.

The work log. Start on day one. Your first review will cover this period, and the early weeks are the hardest to reconstruct because everything was undifferentiated. Two lines a week, starting now.

How to take notes in the first weeks

You will be shown a great deal very fast, and most of it will not stick.

Write during, tidy after. During a walkthrough, capture terms, names and things you did not follow. Do not try to structure it; you do not yet know what the structure is. Ten minutes afterwards, move things into the four notes.

Write down what you did not understand, specifically. "I did not follow why the staging deploy needs the manual step" is a question you can ask later. "Deploy: confusing" is not.

Ask for the reason, and record it. The most valuable thing you can learn in the first month is not how something works but why it is that way. Systems have history, and the history explains the parts that look wrong. Write down the answer with the name of who gave it — you will need to cite it later, and people misremember.

Record what you were told, not what you concluded. Early conclusions are usually wrong, because you are missing context. What someone actually said is durable; your interpretation of it at week two is not.

The thing to write in week six

Sit down for twenty minutes and write everything you found confusing, before you stop finding it confusing.

This document is genuinely valuable and almost nobody produces it. It is the onboarding feedback the company cannot generate internally, because everyone who could write it has forgotten. It is also the seed of your first real contribution: the fixes that make you look observant in month four all come from this list.

Write it for yourself first. Whether you share it is a separate decision — and if you do, share it as observations rather than criticism, from someone who wants the place to be easier rather than someone auditing it.

What not to write

Some restraint is warranted, because notes about work are notes about people.

Not judgements about people, in anything shared. "X seems disorganised" at week three is an opinion formed from almost no information, and it can outlive both the impression and your reason for forming it. Keep the map factual: what they do, what they know, how to reach them.

Not confidential material you have no reason to hold. Salary information you saw by accident, personal details from an HR conversation, anything covered by a policy you have just agreed to. If you would not want to explain why you have it, do not keep a copy.

Not on a machine you do not control, if it is personal. Your work log, your confusion log and your career notes are yours. The glossary and the systems documentation belong in the company's wiki, where they help everyone and where you are not the only copy.

That split matters, and it is worth deciding deliberately in week one rather than discovering at the exit interview: shared knowledge goes in the shared place; your own record of your own work goes somewhere that leaves with you.

Month three: the review

Reread all four notes.

The glossary tells you how much you have learned, which is a genuine and underrated morale boost around the point where the initial adrenaline has worn off and you feel slower than you expected.

The people map is now accurate enough to be useful and should be kept updated indefinitely — it is the note you will still be using in year three.

The confusion log is the one to act on. Go through it and sort into three: things that confused you and now make sense, things that are genuinely broken and fixable, and things that are broken and not yours to fix. The middle column is your first real project.

The work log you keep forever.

The honest version

This is more writing than most people do when starting a job, and the case for it rests on one asymmetry: the first six weeks generate information you can never get back, at a moment when you have more spare attention than you will have again.

If you only do one of the four, do the glossary. It pays for itself within a fortnight and it is the one you will actually maintain.

Cyanote suits this well because the personal half stays personal: one local database on your own Mac, no account, nothing on a company server, and it leaves with you when the laptop does not. Notes nest into sub-pages so the people map can hold a page each, [[ links connect a meeting note to the person it was with, and full-text search finds the acronym you wrote down in week two and have not thought about since. There are meeting, standup and 1:1 templates in the / menu for the parts that recur.

Both parties feel this is a waste, both are too polite to say so, and it continues for a year.

The fix is not a better agenda template. It is that a one-to-one is the only recurring meeting whose entire value comes from continuity, and continuity is a note.

Why it decays

Neither person prepared. Preparation for a 1:1 means five minutes with a note. Nobody does five minutes, so the meeting begins with "so, how's it going", which has exactly one natural answer: a list of what you are working on. Which your manager can already see.

Nothing carries over. The thing raised three weeks ago that neither of you has thought about since. The commitment made in June. Without a record, each meeting starts from nothing, and a meeting that starts from nothing can only cover the present — which is what makes it a status update.

The important things are not urgent. Career, growth, whether you are in the right role, the thing that has been quietly bothering you for two months. None of it presents itself, so it never comes up, so the meeting is permanently about this fortnight.

Nobody says the awkward thing. Which is often the whole reason the meeting exists, and it is much easier to raise something you wrote down calmly on Tuesday than something you have to summon on Thursday.

One note per person, forever

Not a note per meeting. One note per person, growing downward, exactly like a client note — and if you manage people, this is the single most useful document you have.

At the top: what they are working on, what they said they want next, how they like feedback, their working pattern, anything about their life you should remember to ask about. Below: dated entries, newest first.

The reason this shape wins is the moment it is used. You have five minutes before the meeting. One note, read the top and the last two entries, and you arrive knowing what was raised last time and what you owe. Any arrangement spread across a calendar of separate meeting notes means reconstructing that from three places, which is why nobody does it and why the meeting starts from nothing.

The four lines, before each meeting

Written by both people, ideally, and by at least one.

What has changed since last time. Not everything you did — what is different. One or two things.

What I am stuck on, or need a decision about. The most useful line in the meeting. It converts a status update into a conversation with a purpose, and it is the one your manager can actually act on.

Anything from last time that is still open. Requires reading the previous entry, which is the point.

One thing that is not about this fortnight. Career, a frustration, an idea, something about how the team is working. This is the line that stops the meeting collapsing into the near term, and it is worth having a standing slot for even when the answer is "nothing this time".

Four lines, five minutes. That is it.

What to write during and after

Ten minutes afterwards, while it is fresh.

What was decided, plainly, and by whom.

What each of you owes, with a date. These become actual dated tasks immediately — one sentence with the date in it — because a commitment made in a 1:1 and recorded only as prose is a commitment that will be quietly dropped, and dropped commitments are what destroy trust in this meeting specifically.

What they said about what they want. Career direction, interests, frustrations, the thing they mentioned twice. Six months of these is the material for a promotion case or a difficult conversation, and it is completely unreconstructable from memory.

What you noticed and did not say. For managers: the observation you were not sure about yet. Two or three of these across a couple of months either becomes a pattern worth raising or dissolves, and both outcomes are better than acting on a single impression.

Both sides should keep one

If you are the report, keep your own. It is not duplication.

Your note contains what you asked for and when — which is what you need when a promise made in March has not materialised by October, and which nobody else is recording from your side. It contains what you were told about your progress, in their words, dated, which is the raw material for your own review case. And it contains the things you raised, so a pattern of raising something four times is visible rather than a vague sense of not being heard.

It should be in your notes, on your machine, not in a company document. The reason is the same as for a work log: the day you most need the record of what you were promised is often the day you lose access to the company's systems.

What not to write

For managers, some care, because a note about a person is a record about a person.

Not conclusions about character. "Seems unmotivated" is an interpretation from partial information that will outlive both the impression and the situation that produced it. Write the observation — "missed two commitments this month, mentioned being stretched" — which is factual, actionable and fair.

Not anything you could not defend if read aloud. These notes can be subject to disclosure in a dispute, and more to the point: a note you would not want them to see is usually a note you should have turned into a conversation.

Not personal information they shared in confidence, beyond what you need to be a decent manager about it. "Back on the 14th" rather than the medical detail.

The test is whether the note would embarrass you if the person read it. If it would, the problem is generally not the note.

The honest version

None of this makes a bad one-to-one good. If the relationship is broken, or the meeting exists to perform management rather than to do it, better notes will produce a better-documented waste of thirty minutes.

What it fixes is the common case: two people who both want the meeting to be useful and neither of whom has spent five minutes preparing it. That is a genuinely large share of all 1:1s, and five minutes with one note is the whole intervention.

Cyanote has a 1:1 template in the / menu, and notes that nest into sub-pages so each person can be a page with entries under it. [[ links connect a person to the projects and meetings they appear in, so their page assembles context you never filed there. Tasks take an owner and a date out of a typed sentence, and everything is searchable a year later with ⇧⌘F. It is one local database on your own Mac — which for your own side of these conversations is the point, since it leaves with you when the laptop does not.

Three weeks later you are in the same place, tracing the same path, having the same small realisation. You have done this before. You remember doing it. You do not remember the answer.

This is the defining experience of learning a large codebase, and it is not a memory problem. It is that the understanding you built was never written down, and understanding that is not written down decays at roughly the rate of a phone number.

What is worth writing, and what is not

The instinct is to document the code. Resist it — the code documents itself better than you can, it changes underneath your notes, and a note describing what a function does is stale within a month and misleading thereafter.

What decays badly and is not in the repository is different.

Call paths. "A request to /export goes through the controller, the serialiser, and the job queue, and the timeout is set in the middleware, not the job." Four lines, and it saves you the twenty minutes it took to establish. This is the single highest-value kind of note there is.

Why, when why is not obvious. Every codebase has a section that looks wrong and is not. Somebody explained it to you, or you worked it out from the history. That explanation exists nowhere in the code, and it is what will stop you or someone else from "fixing" it later.

Where things live. Not the directory structure — the answers to "where does X happen". Where is auth actually enforced. Where do the emails come from. Where is the thing that runs at midnight. A dozen of these is an enormous head start.

The gap between how it looks and how it behaves. The naming that lies, the config that is overridden somewhere else, the abstraction that has one real implementation. Every codebase has a handful and they are the source of most wasted afternoons.

The environment incantations. The commands with the flags. How to run one test. How to reset the local database when it wedges. These are trivial, they are looked up constantly, and they belong somewhere you can find them in two seconds.

The rule that makes it work

Write it down the moment you have understood it, before you fix the thing.

The window is narrow. While you are tracing, you are holding the whole path in your head and writing it costs almost nothing. Once you have made the fix, the understanding has done its job and starts unloading immediately — and half an hour later, writing the same note means reconstructing it.

The second half of the rule: stop before you write documentation. Four lines about a call path is a note. Two pages about the architecture is a document, and a document is a commitment to maintain something that will drift. The value is in the small, specific, expensive-to-rederive facts.

Where these notes should live

Split by lifespan, and this is the practical decision.

In the repo: anything true about the code that the team should share and that should change when the code changes. Setup instructions, architecture decision records, the reasons behind a design. If it lives next to the code, it moves with it and gets reviewed with it.

In your own notes: your working understanding. Half-formed, occasionally wrong, containing "I think this is because" and "ask someone about this". That is exactly the material that should not go into shared documentation — nobody wants a wiki full of somebody's provisional guesses — and it is also the material that makes you effective in month two.

The mistake is trying to put the second category in the first. It makes you slow, because you edit yourself, and it degrades the shared docs with uncertainty.

The one-page map

After a fortnight, write one page and keep it updated.

Not the architecture — the territory. Six or eight lines: what the main pieces are called, roughly what each does, and where the seams are. Where does a request enter. Where does data get written. What is the one part everybody is afraid of.

Every codebase has an implicit version of this that the long-serving people hold in their heads, and none of them have ever written it down because it is too obvious to them to be worth stating. It is the single most useful document for the next person, and you can only write it during the window where you have just learned it and have not yet forgotten what it was like not to know.

Code, prose and the same window

A practical note, because this is the friction that stops people.

These notes are inherently mixed: a paragraph of explanation, a command with flags, a stack trace, a path, a snippet. If your notes app mangles code — smart quotes, autocorrect, no monospace, no syntax highlighting — you will not paste the command, and the command was the useful part. If your code lives in a scratch file and the explanation lives in a notes app, you will keep one and lose the other.

That is the whole argument for keeping notes and code in one app: not elegance, but that a mixed note is the natural shape of this material and splitting it in half loses whichever half is more inconvenient.

The other mechanic that matters is search. You will not remember which note has the thing; you will remember a word from it — a function name, an error string, a flag. That means search has to reach inside code blocks, which is not universal and is worth checking before you rely on it.

A month in

Reread what you wrote in week one. Two things happen.

Some of it is wrong. Fix it — the wrongness is informative, because it shows you what the codebase misleads people about, which is exactly what the one-page map should warn about.

Some of it is now obvious and you cannot remember needing it. Leave it alone. It is not for you any more; it is for the next person, and the fact that it looks trivial to you is precisely why nobody else was ever going to write it.

The honest version

Nobody is going to keep this up for years, and they should not. The intensity of note-taking should fall off as the codebase becomes familiar, and by month six you will be writing almost nothing, which is correct.

The window that matters is the first six to eight weeks — the period where everything is expensive to establish and cheap to record. After that the value drops sharply, and continuing to document out of discipline is just a slower way to work.

Cyanote handles the mixed shape: prose notes with syntax-highlighted code blocks inline, and separate code notes with language detection that can be saved straight back to a file on disk. ⇧⌘F searches the body of everything including code blocks, [[ links a note to the one it relates to, and notes nest into sub-pages so a codebase can have a page with children rather than fourteen loose notes. One local database, so the map you built of a system you were paid to understand stays yours.

What no app catches is the thing that happens in a real conversation: you wanted to say something and could not. That gap is the single most valuable piece of information your week produces, and it disappears within about four hours.

The gap log

One line, as soon as possible after the conversation.

What I wanted to say, in English. Exactly. "I would have picked it up but I was already late."

What I said instead, if anything. Usually something clumsy that worked.

What I actually needed — filled in later, when you look it up or ask someone.

That is it. Two lines in the moment, one filled in afterwards.

It works because it is your gap. A textbook chapter on the conditional is somebody's guess at what learners need. A list of eleven sentences you personally tried to say and could not is a curriculum built exactly to the shape of your life, in your register, about the things you actually talk about. Nothing bought can match it, and it costs a line a day.

What else is worth writing down

Corrections, verbatim. When someone corrects you — a teacher, a friend, a stranger — write down what you said and what they said, in their words. Do not paraphrase into the rule; the rule you infer is often wrong, and the raw correction stays useful.

Things you heard that surprised you. A phrasing that was not what you would have constructed. An idiom. The word that turned out not to mean what you assumed. These are the entries you will reread with most benefit.

Your own mistakes, with the pattern. Everyone has three or four errors they make constantly. Written down over a month, they become visible and therefore fixable; unwritten, they are simply how you speak.

The word you looked up twice. Looking something up twice means it did not stick and it recurs, which is precisely the definition of something worth learning deliberately. Mark it the second time.

Sentences, not words

The single most useful change most learners can make to what they write down.

A word in isolation is close to unusable. You learn a noun and still cannot deploy it, because you do not know its gender, which preposition it takes, what register it belongs to, or which verb goes with it. All of that is carried by a sentence and none of it by a dictionary entry.

So record the whole sentence you heard or needed, and mark the part you were learning. Three sentences with a word in context beat twenty isolated definitions, and if you do run flashcards, sentence cards outperform word cards for exactly this reason.

The grid, for the one thing that matters

Consistency is the only variable in language learning that is not in dispute. Twenty minutes daily beats three hours on Sunday, reliably, and everyone knows this and does it anyway.

A grid of the last four weeks — did I do something in the language today, yes or no — is the right shape for that one question, and it is worth keeping separate from everything else. Not hours, not words learned, not app streaks. Did I turn up.

The reason a grid works better than a streak counter: a streak resets to zero and teaches you to stop looking after a missed day. A grid shows one gap on the 3rd and five ticks around it, which is an accurate picture of a good fortnight rather than a failure.

Reading it back

The part that turns a log into learning.

The gap log, weekly. Look up the three or four you have not filled in, and use them deliberately in the next conversation. That is the loop, and it closes in a week.

The mistakes, monthly. Patterns appear across entries that are invisible within one. Two months in, most people find one grammatical thing they get wrong constantly, and fixing that one thing produces more improvement than a month of vocabulary.

Everything, at six months. Read what you were struggling with in month one. This is the single best antidote to the plateau feeling, which is the main reason adults quit — progress in a language is genuinely invisible from inside, and the only reliable measure is your own record of what used to be hard.

Where it should live

Somewhere it survives the app you are currently using.

Language learning happens over years and across tools — an app, then a class, then a tutor, then a period of just reading. Notes kept inside any one of those are notes you lose at the transition, and the transitions are frequent. A general notes collection that exports to a readable file is the thing still standing in year three, when the gap log from year one is genuinely interesting.

The practical requirements are small: it has to handle the script and any accented characters without fighting you, and search has to find them. Both are worth checking for a language that is not written in the alphabet you type in daily.

The honest version

Notes are not how you learn a language. Talking to people is, and everything here is a support structure for that.

But the gap log specifically is worth more than its size suggests, because it is the only artefact that records what you personally cannot yet do — and every other resource in the field is built around what learners in general cannot do. If you keep one thing, keep that.

Cyanote holds the parts that are notes and the part that is a grid: habits show the last four weeks as rows and columns, so a missed Tuesday is one click and a gap is visible straight down the page; notes hold the gap log and the corrections, searchable years later by any word in them, including in whatever script you write in. It is one local database on your own Mac with a readable export — which for a record you want to still have when you are finally fluent is the part that matters.

That third explanation is the valuable one. It took two failures to find, it is genuinely better than the one in the documentation, and by Friday it is gone. Next time you will start from the first explanation again, because that is the one that comes to mind.

Nobody writes these down, and they are among the cheapest and most reusable things anyone produces.

What to capture

Not the explanation — the third explanation, plus the two that failed.

The version that worked. In the words you used, not tidied up. The rough spoken version is the one that works; the written-up version is usually the documentation you already had.

What they misunderstood first. This is more valuable than the explanation itself, because it is a fact about how people encounter the topic. If three people make the same wrong assumption, the assumption is predictable and your explanation should start there.

The question they asked that you had not anticipated. Every subject has a small set of questions that arise reliably and appear in no documentation, because whoever wrote it had forgotten the question was askable.

The analogy, if there was one. Analogies are expensive to invent and cheap to reuse, and a good one is often the entire explanation.

The curse you are trying to work around

There is a specific reason this is hard, and knowing it helps.

Once you understand something, you lose reliable access to what it was like not to. The gap that needed bridging becomes invisible; the explanation that seems natural to you is one that only works for someone who already has most of the picture. This is why experts routinely explain things badly and are surprised by it.

You cannot fix that by trying harder to remember what confusion felt like. You can fix it by writing down, at the moment you observe it, what a specific person actually misunderstood. That record survives your own forgetting, and it is the only thing that does.

Which means the notes are most valuable when written by someone who has just learned it — the same window that makes the first ninety days at a job worth documenting, for exactly the same reason.

One note per thing you explain

Growing over time. Not a document you write, a note you add to.

Each time you explain the topic, add a line: who, what they misunderstood, what worked. After six or seven, the note contains something no first-draft document ever does — a map of how people actually get lost, ordered by frequency.

That is the point at which it is worth turning into real documentation, and the resulting document is dramatically better than one written from scratch, because it is organised around the misunderstandings rather than around the structure of the subject. Most bad documentation is bad because it is organised the second way.

Where teaching and onboarding are the same job

The pattern is identical whether you are teaching a class, onboarding a colleague, supporting customers, or answering the same question in a forum for the fourth time.

Something recurs. The same topic, the same confusion, more than twice.

The explanation improves with iteration, and the improvement is lost without a record.

The audience does not know what they do not know, so their questions are the only reliable signal about where the gaps are.

If you support people, the support queue is the best documentation backlog in existence and almost nobody treats it as one. The questions asked most often are the topics your documentation covers worst, in exactly that order, and that ranking is free.

Note the wrong answers too

An under-used move: write down the plausible-but-wrong understanding.

If everyone assumes the setting applies globally when it applies per-document, that specific wrong belief is worth recording, because your explanation should address it directly rather than describing the correct behaviour and hoping the contradiction is noticed. "It looks like it applies to everything — it does not, it is per document" corrects an existing model. "It applies per document" gets read straight past by someone who already believes otherwise.

Correcting a wrong model is a different job from describing a right one, and only the notes tell you which model people arrive with.

The reuse is the payoff

Where this pays back, concretely.

The written version. When you finally write the documentation, the note is the outline and the hard part is done.

The next person. Onboarding someone means re-explaining everything you explained last year, and the note is the difference between doing it well and doing it from scratch.

Your own understanding. Teaching something is the standard test of whether you understand it, and the record of your explanations is a record of your understanding improving — visible in a way that is otherwise entirely internal.

A talk, a post, a course. Almost all good explanatory writing is downstream of having explained the thing out loud several times to people who did not get it. The notes are the raw material and they accumulate whether or not you ever use them.

The honest version

This is a habit with no payoff for months. The first three notes feel pointless because there is no pattern yet, and the value is entirely in the sixth reading, which is a long way off.

If you explain the same things repeatedly — teaching, support, onboarding, management — it is one of the highest-return notes available, and it costs a line after a conversation you were having anyway.

Cyanote suits it because the note grows rather than being written: one note per topic, appended to each time, nesting into sub-pages when a topic gets big, [[ links tying an explanation to the system it is about, and ⇧⌘F finding "what was the analogy I used for this" a year later. It is one local database on your own Mac — which for explanations you developed and will take to the next job is where they should be, rather than in a wiki you lose access to.

The packing is the part everyone dreads and the part that always gets done, because it is physical and it has a deadline. The failures are elsewhere, and they are the same three every time.

The three failures

A date passed and nobody knew. The notice period on your current place. The date the mortgage offer expires. The last day to cancel the broadband without a fee. Every one of these is a date somebody told you once, in passing, three months before it mattered.

Nobody could find the fact. The reference number, the meter reading, the name of the person who said the thing, the exact wording of what the agent promised about the fridge. Somewhere in an email, or a call you did not write up.

Nobody knows who is waiting on whom. The solicitor is waiting on the survey, you think, or possibly on you. Chains stall for weeks because nobody is tracking whose move it is, and the person best placed to notice is you.

None of the three is a packing problem, and none of them is fixed by a checklist from the internet.

One note per organisation

Not one note called "Moving". Eleven notes, one per party: the estate agent, the solicitor, the mortgage lender, the surveyor, the removal company, each utility, the council, the broadband provider.

At the top of each: who they are, the reference number, the named contact and their direct line, and what they are responsible for. Below: dated entries, after every call.

The reason for the split is the moment it is used. You are on hold, they have asked for your reference, and someone is about to tell you something. You need one note open, containing that organisation's reference and what they said last time. A single "Moving" note means scrolling through four months of everything to find the utility bit while somebody waits on the line.

It is the same shape as a client note, and a move is genuinely a project with eleven suppliers.

Write up every call, immediately

The one discipline, and it is worth more than everything else here combined.

Four lines within two minutes of hanging up: who you spoke to, what they said, what they committed to, and by when. Especially the name. "I spoke to someone last week who said it was fine" carries no weight; "I spoke to Daniel on the 14th, who confirmed the completion date was still the 30th" carries a great deal.

Property transactions run on verbal assurances that nobody records, and the person with a dated note of who said what has a substantial advantage in every subsequent disagreement. This is not adversarial — most of the time it just resolves an honest confusion in ten seconds instead of a fortnight.

Every date with money on it, in the calendar

The moment you learn it, as an event, with a reminder well ahead.

Notice period on your current place. Mortgage offer expiry. Fixed-rate end date. Insurance start — buildings insurance normally needs to be live from exchange rather than completion, and that is the classic expensive gap. Cancellation deadlines for services. Council tax notification. The final meter readings.

A month's notice for anything with a fee attached, because a week's notice is notice that it is happening, and a month is enough to do something about it. Same principle as life admin generally, compressed into four months where the consequences are larger.

A board for the chain

The third failure — nobody knows who is waiting on whom — is what a board is for.

Three columns: waiting on me, waiting on them, done. Every outstanding item as a card. Ten seconds, once a day, and you know whether it has been eleven days since anyone touched the searches.

This matters more than it sounds because chains stall silently. Nobody tells you nothing is happening; things simply do not move, and by the time it is obvious you have lost three weeks. A board makes stalling visible, and the polite chase on day four costs nothing and moves things.

The specific things people forget

Collected from the way these go wrong.

Photograph every meter, on the day, with the whole meter and the serial number in frame. Both properties. Disputed readings are the single most common post-move billing problem and a photograph settles them instantly.

Photograph the condition of things on the day, if you rent. Both ends. It is the deposit.

Write down what is included in the sale, in the exact words used. Fixtures, appliances, curtains, the shed. This is where the small bitter arguments happen, and they are entirely preventable with one dated line.

Keep the completion statement and the paperwork. Some of it is needed years later for tax.

Write down where you put the important box. Genuinely. The one with the documents, the chargers and the kettle.

The week after

Ten minutes, once you have moved, while it is fresh.

What went wrong, and what you would do differently. Not for this move — for the next one, or for the friend who asks. It is remarkable how completely this evaporates within a month.

What it actually cost, in total, including the things nobody counts: the removal, the fees, the two weeks of eating out, the things that had to be replaced. This is the number you will want the next time you are deciding whether to move, and it is not recoverable later.

Anything still outstanding. There is always something — a refund, a final bill, a thing the seller was supposed to send. It goes on the task list with a date, because the relief of having moved is exactly when unfinished things get dropped.

The honest version

A move is four months of admin and there is no system that makes it enjoyable. What notes do is remove the specific failures that turn an expensive stressful process into a more expensive one — a missed cancellation, an assurance nobody recorded, three weeks lost to a stalled chain.

If you do one thing: write up every phone call, with the name and the date, within two minutes. That single habit prevents most of what goes wrong.

Cyanote holds all three parts in one window: a note per organisation with the references at the top, a calendar with reminders a day, an hour or thirty minutes ahead for every date with money attached, tasks that take their date out of the sentence you type, and a board for the chain. Photographs of meters and paperwork go in the notes rather than in a URL somewhere. It is one local database on your own Mac — which for a file containing your reference numbers, your solicitor's correspondence and photographs of your documents is where it should be.

You will use it four times.

I have done this more than once, and the failure is not laziness. Templates fail for structural reasons, and the reasons are consistent enough to design around.

Why the elaborate ones die

They ask for information at the wrong moment. A meeting template with a "decisions made" section is asking you to have already sorted the meeting into categories while the meeting is still happening. What actually happens in a meeting is that things arrive in the order people say them. Any template that requires sorting-while-capturing loses to a blank page, because the blank page lets you keep up.

They have more sections than the average instance needs. If two thirds of your meetings have no action items, an Action items heading appears empty in two thirds of your notes. Empty headings are worse than no headings: they read as something forgotten rather than something absent, and after a while you start deleting them, which is friction you invented for yourself.

They encode a workflow you were hoping to have rather than the one you have. This is the big one. The template is aspirational — it describes the version of you who reviews the previous meeting's actions before writing the new note. That person does not attend the meeting. The person who attends is late and typing.

What the ones that survive have in common

They are shorter than you think is respectable, and every line in them does one of two jobs.

A prompt you would otherwise forget. Not a section header — an actual question sitting there in the note. "What did we decide?" pulls something out of you at the end of a meeting. "Decisions" does not; it is a filing label, and you will file nothing under it.

A field that makes the note findable later. The date, the people, the project name. Four words that cost nothing at capture time and are the entire reason you will find this note in November. If you link names, this is also where the link goes, which is where a backlink list quietly builds itself out of meetings nobody filed.

Everything else — status fields, tags, energy ratings, a summary section you fill in afterwards — is optional at best and a tax at worst. Cut it, use the template for a month, and add back only the thing you genuinely missed.

The four templates that earn their place

Almost everyone converges on some version of these.

A daily note. One note per day, created without asking you anything. Its real function is not journalling; it is having a default place to put things so that capture never involves a decision about where. Whatever ends up in it can be sorted later or never.

Meeting notes. Date, who was there, a blank space, and one prompt at the bottom — "what did we agree, and who has it". The blank space in the middle is deliberate. It is where the meeting goes.

A one-to-one. The one template where structure genuinely helps, because the value is in continuity: what we discussed last time, what has changed, what they raised, what I owe them. It is the same four things every fortnight, and having them written down is what stops a 1:1 becoming a status update.

A weekly review. The one place a longer template is justified, because you are sitting down on purpose with time set aside — which is exactly the condition the other templates cannot assume. I have written about the twenty-minute version separately; the template for it is mostly a list of questions in a fixed order, so you do not have to remember what reviewing consists of.

For a lot of people the list stops there. If yours includes a decision journal, reading notes, retros or incident reviews, those are real and well-established formats — but they are the second wave, added after the first four have proved they get used.

Where the template should come from

Two schools, and they fail differently.

Write your own. Correct in principle: your meetings are not mine. In practice, writing your own is when the Sunday-afternoon problem happens, because a blank template editor invites completeness. If you write your own, write it during the third meeting where you wished you had one, not in advance.

Start from a stock one and delete. Faster, and the deleting is the useful part. A stock template gives you a shape to react to, and reacting to a shape is much easier than inventing one. Whatever you delete in the first fortnight was never yours.

The failure mode worth naming: a template gallery with sixty entries. Sixty options is not sixty times as useful as four; it is a browsing session, and browsing is not writing. Ten or twelve good ones covering the common formats is about the size where you can hold them all in your head.

What to check in the app

Small mechanics, disproportionate effect on whether templates survive.

• How many keystrokes to start a note from one? If it is more than about three, the template loses to a blank note and always will.
• Can you edit the template, or only use it? A stock template you cannot cut down is a stock template you will stop using in week two.
• Does the daily note create itself, or do you create it? These are very different products. "It is already there" removes a decision; "make today's note" adds one.
• Is it a template or a database? Some apps make templates the front end to a structured database with required properties. That is powerful and genuinely useful for tracking things — and it is also the thing that turns a two-second capture into a small form-filling exercise. Know which you are buying.

The honest version

If your notes are mostly one kind of thing — a research log, a book manuscript, a set of client files — you may need one template and nothing else, and a gallery is dead weight. If your work has no repeating shapes at all, templates are solving a problem you do not have, and the honest recommendation is a blank page and a good search box.

Templates pay off exactly when the same kind of note recurs and you keep re-deciding what should be in it. That is the whole condition.

Cyanote ships a set of them — daily notes, meeting and standup notes, 1:1s, project briefs, Cornell and reading notes, decision journals, weekly reviews, retros and incident reviews — reachable from the / menu without leaving the keyboard. They are meant as starting shapes to cut down, not a system to adopt. Every note lives in a single database on your own disk, so a template is a local convenience rather than a schema on somebody's server.

Two wrong readings follow. Some people conclude the app has a virus and delete it. Others conclude macOS is being annoying and reach for the bypass. Neither is right, and the actual meaning is narrow enough to state precisely.

What Gatekeeper checked

macOS looked for two things, and the warning tells you which one failed.

A Developer ID signature. The developer enrolled in Apple's programme, has a real identity on file with Apple, and used their certificate to sign the app. The signature also proves the app has not been altered since. If this is missing, macOS calls it an unidentified developer — meaning literally that: nobody's name is attached.

Notarisation. The developer uploaded the finished build to Apple, which scanned it automatically for known malicious content and issued a ticket. This is not a review of quality or behaviour. It is an automated malware scan plus a record that a specific, identifiable developer shipped this specific binary.

Neither check says the app is good, safe, or well made. Together they say: a real identity is attached, and an automated scan found nothing known. That is a lower bar than people assume, and a meaningfully higher one than nothing — mainly because accountability raises the cost of shipping something bad.

What changed, and why the old advice fails

For years the standard workaround was Control-click the app, choose Open, and confirm. Half the internet still says this.

Apple removed that path in macOS Sequoia. The developer note announcing it is explicit: users can no longer Control-click to override Gatekeeper for software that is not signed correctly or notarised, and must go to System Settings → Privacy & Security to review the security information before allowing it to run.

So the current route, if you have decided to trust something:

1. Try to open it once. It will be refused.
2. Open System Settings → Privacy & Security.
3. Scroll down. There is a message naming the app that was blocked, with an Open Anyway button.
4. Confirm, and authenticate.

The extra friction is deliberate. It makes the decision explicit, in a settings pane, rather than something you can be talked through on a phone call by someone claiming to be support — which was the attack the old shortcut enabled.

What you should never do

Do not run xattr -d com.apple.quarantine because a forum told you to. That command strips the flag macOS uses to know the file came from the internet, and it makes the warning disappear for any file, including one that should have triggered it. It is the single most commonly pasted dangerous command in Mac support threads, and the people posting it are usually trying to help.

Do not disable Gatekeeper entirely. spctl --master-disable turns the whole system off for everything, permanently, to solve one download. If you have done this at some point in the past, it is worth checking whether it is still off.

The distinction that matters: allowing one specific app you have reasoned about is a decision. Removing the mechanism that would have asked you next time is not.

How to decide whether to trust it

The warning has told you what macOS does not know. The rest is yours, and these are the questions worth asking.

Where did the download come from? The developer's own site over HTTPS, or a link in a search ad, or a download-portal mirror? Mirrors are where re-bundled installers live, and the app can be legitimate while the copy you got is not.

Does the developer have a name and a history? A site, a changelog, a support address, a track record, people discussing it publicly. Software with no findable author asking you to override a security warning is a bad combination regardless of what it does.

Is it open source, and are you getting it from the actual project? A great deal of good Mac software is unsigned simply because the developer will not pay Apple annually to give it away. That is a legitimate reason and a common one — but it makes provenance everything, since the project's release page and a random mirror carry very different risk.

Is the warning proportionate to what you are installing? A small utility that draws a window is one thing. Something that wants Accessibility permission, a kernel extension or admin rights is another, and an unsigned app that immediately asks for broad system permissions deserves considerably more scepticism.

The version of this you should walk away from

Some cases are not judgement calls.

• The download arrived by email or a message, and you did not go looking for it.
• A web page told you your Mac has a problem and offered a fix.
• Someone on a call is asking you to open Privacy & Security and click Open Anyway.
• The app is a "cracked" or "patched" build of paid software. Repackaged installers are one of the most reliable malware vectors on macOS, and the whole point of the repackaging was to modify a binary somebody else signed.

In all four, the warning is doing precisely the job it was designed for.

The other side: what it costs developers

Worth knowing, because it explains why so much decent software trips it.

Signing requires a paid Apple Developer membership, renewed annually. Notarisation requires uploading each build to Apple and waiting for a result, which adds a step to every release. For a hobbyist giving software away, that is a recurring cost and a recurring chore in exchange for no warning dialog — and plenty of them reasonably decline.

Which means the warning is not a quality signal. Some of the best Mac utilities ever written are unsigned, and plenty of mediocre commercial software is signed and notarised. It is an accountability signal, and only that.

The honest version

The warning means: nobody is on the hook for this, or nobody checked it. Decide with provenance, not with the dialog.

Cyanote's Mac build is a universal binary — Apple Silicon and Intel — signed with a Developer ID certificate and notarised by Apple, so it opens normally and none of the above applies to it. The Windows build is a different story and it is stated plainly on the site: it is not Authenticode-signed yet, Windows shows an unknown publisher on first run, and it is not on sale for exactly that kind of reason. Being able to say which of your builds trips a security warning, and why, seems like the least a download page owes you.

What grew on top of it is the reason most people bounce off. Somewhere in the last decade, linking notes stopped being a text feature and became a practice, with a vocabulary — atomic notes, evergreen notes, maps of content, zettelkasten, second brain — and a genre of YouTube video about the graph view of somebody's vault, which is beautiful and tells you nothing.

You can have the feature without the practice. It is worth having.

What a link actually buys you

Search finds a note when you remember a word that was in it. Links find a note when you remember a different note that mentioned it.

That second case is more common than it sounds. You cannot remember what the contractor was called, but you know you wrote about the kitchen. You cannot remember the name of the library, but you know it came up when you were setting up the project. In both cases you have a handle on something adjacent, and a link turns that adjacency into a route.

Backlinks — the note showing you what points at it — are the same trick pointed the other way. Open the note about a person and you see every meeting they were in, without having filed a single one of those meetings under their name. That is a filing system that builds itself as a side effect of writing normally, which is the only kind anybody sustains.

The small version, in three rules

This is the entire method as I actually use it. It takes no setup and no vocabulary.

One, link a name the first time you write it in a note. People, projects, clients, recurring problems. Not concepts — names. [[Priya]], [[Kitchen rewire]], [[Invoicing]]. If the note does not exist yet, most apps create it empty when you follow the link, and an empty note that already has three things pointing at it is more useful than a full one nobody links to.

Two, do not link things you would never look up. A link to [[Tuesday]] or [[email]] is noise. The test is whether you can imagine opening that note on purpose. If you cannot, leave the words as words.

Three, never reorganise the links. They are not a structure you maintain. They are a residue of writing. The moment you start tidying them you have joined the practice, and the practice is where people stop.

That is the whole thing. Three rules, no software beyond an editor that supports [[.

What the graph view is for

Honest answer: mostly nothing.

The force-directed picture of every note connected to every other note is one of the most screenshotted features in this category and one of the least used after week two. It is genuinely lovely, and it will occasionally show you a cluster you did not know you had. But it does not answer questions. "Which notes mention this client" is a question. "What does the shape of my knowledge look like" is a screensaver.

If an app has a graph view, enjoy it. If choosing between apps comes down to whether one has it, choose on something else.

Where the methodology goes wrong

Not because the ideas are bad — several of them are good — but because of what they ask for up front.

The heavy note-linking systems ask you to decide, at the moment of writing, what a note is: whether it is atomic, whether it is permanent or fleeting, which index it belongs to, whether it has earned a place in the permanent collection. That is a lot of classification work applied to the thing you were doing to avoid work. The overhead lands entirely on capture, which is the exact point in the process that has to stay cheap or the system dies.

You can watch this happen in the wild. Someone sets up a beautiful vault in January, writes forty carefully processed notes, and by March is writing into the phone's default notes app because it does not ask any questions. The methodology did not fail on the merits. It failed on friction, at the only moment where friction is fatal.

The small version has no capture cost. You type two brackets in the middle of a sentence you were writing anyway.

What to check before you rely on it

Links are only worth building if they survive.

Do links break when you rename a note? Some apps rewrite every reference automatically. Some leave you with dead text. This matters more than it sounds, because notes get renamed constantly in the first month.

Are backlinks shown, or only forward links? Forward links alone are half the feature. The assembling-itself part is the backlink list.

What happens on export? If you leave, do the links come out as something a person or another app can follow, or as [[Priya]] sitting in a text file pointing at nothing? Ask this before you have two years of them. It is the same question as what happens when your notes app shuts down, applied to the one feature that is hardest to reconstruct by hand.

Can you link to a sub-page, not just a top-level note? If notes nest, links that only reach the top level will start failing you around the time the collection gets deep enough to need them.

The honest version of the choice

If you genuinely want the full practice — a system you tend, with indexes and structure notes and a defensible taxonomy — Obsidian is the app for it and has been for years. As of 17 August 2026 the core app is free for personal use, your notes are Markdown files in a folder you own, and the plugin ecosystem is where every idea in this space gets tried first. Nothing bundled into a general-purpose app will out-depth it, and I would not pretend otherwise.

What a general app can offer is the part most people actually use: [[ works, backlinks appear at the bottom, and nobody asks you to have a philosophy. If you have tried the full version twice and stopped twice, that is not a discipline problem. It is a sign you wanted the feature and were sold the practice.

Cyanote's version is deliberately the small one. Type [[ in any note to link to another, and the note you linked to lists what points at it. Notes nest into sub-pages, and the links reach them. Everything sits in a single SQLite database on your own disk, and the whole collection — links included — exports to a JSON file you can read. There is no graph view. There is also nothing to set up.

It is not enough work to justify software, which is exactly why it goes wrong. It sits below the threshold where anyone builds a system, and above the threshold where you can hold it in your head.

The three failures

Everything that goes wrong is one of these.

A date arrived and nobody knew. The renewal, the deadline, the expiry, the thing that auto-renewed at three times the price because the reminder was in an email you archived. This is the expensive one, and it is a pure calendar failure.

A fact existed and could not be found. The policy number, the model, the serial, the reference from the call, the name of the person who said it would be fine. It is in an email or a photo or a drawer, and it takes twenty minutes to locate at the exact moment you are on hold.

A thread got dropped. Something is half-resolved. You are waiting on them, or they are waiting on you, and neither of you is going to follow up, and in six weeks it will be worse and harder to explain.

Three failures, three fixes, and none of them requires anything clever.

The fix for dates

Every date with money attached goes in the calendar the moment you learn it, as a repeating event, with a reminder a month ahead.

A month, not a week, and this is the whole trick. A week's notice on an insurance renewal is notice that it is about to happen. A month is enough time to shop around, which is the only thing that makes knowing worth anything.

What belongs there: insurance renewals, subscriptions above whatever your annoyance threshold is, MOT and service dates, passport and licence expiry (six months ahead, not one — many countries want validity beyond your travel dates), warranty expiry for anything expensive, tax deadlines, and the end of any introductory rate.

That last one is the highest-value entry most people are missing. Introductory rates are designed around the assumption that you will not notice when they end, and a repeating calendar event defeats the entire business model.

The fix for facts

One note per thing, not per event.

The car. The flat. The washing machine. Each insurance policy. Each ongoing dispute. At the top of the note: the identifying numbers, the account, the model and serial, when it was bought and for how much, who to call. Below that, dated entries as things happen.

Why per thing rather than per event: because the question you ask is always "what do I know about the car", and never "what happened on 3 May". A note per thing answers the common question directly. A note per event means reconstructing the picture from fragments at the moment you least want to.

Photograph the serial number when the thing arrives, into the note. It is thirty seconds while the box is open, and it is otherwise a job involving a torch and moving furniture. The same applies to the model plate on an appliance and the receipt, which fades.

Do keep in mind that a note with a policy number, an account number and a photograph of a document in it is a sensitive note. It is one of the better arguments for keeping this material locally rather than in a workspace on somebody's server, and for locking the note if the app supports it.

The fix for threads

Every open thread is one task with a date on it, and the date is when you will chase.

Not "when it is due" — when you will follow up if nothing has happened. Those are different dates and the second is the useful one. A task saying "chase the insurer about the claim, 24th" is a thread that cannot be dropped, because it will surface on the 24th whether or not anyone else has done anything.

The wording matters more than it should. "Insurance" is a topic and will be ignored. "Ring the insurer, ref 44821, about the excess" is an action you can perform without first working out what it means, and that difference is whether it gets done on the day or deferred four times.

This is where typing the task as a sentence earns its place — the moment you have to record it is thirty seconds after a phone call, standing up, and any friction means it does not happen. One line, with the date in it, or it does not get written.

The twenty-minute setup

Do it once, on a Sunday. Not a system — a list.

Write down every recurring date you can think of. Insurance, subscriptions, services, expiries. You will get maybe seventy percent, and the rest arrive by email over the following year and get added then.

Make a note for each expensive thing you own. Model, serial, when bought, warranty length. Photograph the plate while you are at it.

Open your bank statement and look for annual charges. This is where the forgotten subscriptions are, and it is the highest-return twenty minutes in the whole exercise. Every one you find either gets a renewal reminder or gets cancelled.

Put a recurring event in for a yearly review of the above. Half an hour, once a year, to catch what changed.

That is genuinely the whole thing. It is not a productivity system; it is a small amount of writing down that prevents a specific and expensive category of annoyance.

Where it should live

In the same place as everything else you write down, and this is the practical point of the post.

Life admin loses to a dedicated app every time, because a dedicated app for boring things is an app you open when you are dealing with boring things, which is never voluntarily. The note about the boiler needs to be in the same search box as your work notes, and the renewal needs to be in the same calendar as your meetings — not because it is elegant, but because that is the box you actually type into.

The second reason is privacy. This material — account numbers, policy references, photographs of documents, the history of a dispute — is among the most sensitive text most people produce, and it usually ends up in whichever app was convenient. It is worth it being one you have thought about.

The honest version

None of this is a productivity method and it will not make you feel organised. It is a small amount of unglamorous writing that stops a specific set of expensive things from happening.

The single highest-return item, if you do nothing else: go through last year's bank statements for annual charges, and put a one-month-ahead reminder on every renewal you find. That one takes twenty minutes and pays for itself the first time an introductory rate ends.

Cyanote holds all three parts in one window: notes for the things, a calendar for the dates with reminders a day, an hour or thirty minutes ahead and repeats that carry between occurrences, and tasks that take a date out of the sentence you typed. Any note can be locked with a password and is encrypted where it sits. Everything is in one SQLite database on your own Mac with no account — which for a file containing your policy numbers, your serial numbers and photographs of your documents is not an abstract preference.

That is the actual situation, and it is why generic switching advice is useless here. Nobody is deciding between two note-taking apps. They are deciding what to do with an archive that has quietly become a second memory.

Why people are looking

The free tier is now a demonstration rather than a home. Evernote's own plan comparison, as of 17 August 2026, caps the free plan at 50 notes, one notebook, one device and 1 GB. Starter raises that to 1,000 notes, 20 notebooks and three devices; only the Advanced tier removes the note and notebook caps entirely.

If you have 4,000 notes, the free tier is not something you can fall back to. That is the structural fact behind most of these decisions — not a feature complaint, but the realisation that an archive you built over a decade now sits behind a recurring payment you must keep making to keep it accessible in the app that holds it.

Whatever you decide about staying, that is a good reason to hold an export.

Do the export first, and separately

Before choosing anything else. This is the part that makes every subsequent decision reversible.

Do it now, while your account is in good standing. Not when you are cancelling, not when the renewal has lapsed. The worst version of this is discovering the export limits of a downgraded account at the moment you need them.

Export in batches, by notebook. Large single exports are where things time out or fail halfway. Notebook by notebook is slower, verifiable and restartable.

Then open the result. Actually open it — a couple of files, at random, in something that is not Evernote. This is where people find out what did and did not travel. An export you have not opened is a hypothesis, and that is true of every backup, not just this one.

Keep the export even if you stay. It costs disk space and it converts your archive from something you rent access to into something you have.

What travels and what does not

Set expectations before you start, because some loss is unavoidable and it is better to know which.

Travels well: the text of your notes, titles, creation and modification dates, notebook structure as folders, most attachments, and tags in some form.

Travels imperfectly: rich formatting from web clippings, especially older ones. Tables. Nested lists past a level or two. Anything that relied on Evernote's own rendering rather than standard markup.

Often does not travel: internal note links, which point at Evernote URLs and become dead text somewhere else. Reminders. Saved searches. Anything to do with the account rather than the content.

The internal links are the one that stings, and there is no clean fix. If you have a heavily interlinked collection, budget for the fact that the connections are largely Evernote's, not yours — the same reason it is worth asking what happens to links on export before building a decade of them anywhere.

Then split the archive from the working set

The single most useful move, and the one most people skip in favour of migrating everything.

The archive is the fourteen years of material you refer to a few times a year. It does not need to be in your daily app. It needs to be readable and searchable, which a folder of exported files on your disk already is — macOS Spotlight will index it, and grep will find anything Spotlight misses.

The working set is the last six to twelve months plus the notes you genuinely reference. For most people that is a few hundred notes out of thousands. That is what goes into whatever you use next.

Migrating everything feels responsible and produces the classic outcome: a weekend spent, a new app full of fifteen years of clutter you never wanted to look at, and a system that feels stale on day one. The archive is not less valuable for sitting still. It is just not daily.

Choosing where to go

Briefly, since the honest answers depend entirely on what you were using Evernote for.

Web clipping was the point. Evernote's clipper is genuinely the best in the category and this is its strongest remaining argument. If most of your notes are saved articles, look at something built for that rather than a general notes app.

You need it everywhere. Apple Notes is free and syncs across Apple devices with nothing to configure. Obsidian keeps your notes as files in a folder and lets you sync them however you like. Notion is in any browser.

It is mostly text, and you mostly use one machine. This is the case where a local app makes sense: no account, no tier, no cap, and the archive is a file you own.

You never really used it as a notes app. A striking number of long-term Evernote accounts are actually document storage — receipts, warranties, scans. That is a filing problem, and a folder structure with good naming plus Spotlight is a better answer than any notes app.

The one thing not to do

Do not migrate into a new app before you have a working export sitting on your own disk.

The failure mode is specific and common: you import into something new, spend three weeks setting it up, decide it is wrong, and by then your Evernote subscription has lapsed and the new app's export is worse than the one you skipped. Two apps, no archive, and the way back closed while you were not looking.

The export first. Everything else after.

The honest version

If Evernote is working and you are content paying for it, staying is a perfectly good decision. Fifteen years of accumulated structure has real value, the search is good, the clipper is unmatched, and switching costs a weekend you may never get back in productivity.

The thing worth doing regardless — today, whether you leave or not — is holding an export you have actually opened. That is what turns your archive from a tenancy into a possession, and it costs an hour.

Cyanote is the local answer for the working-set case, and not the answer for the others. Notes in a block editor with headings, tables, code and images, tasks and a calendar and habits in the same window, full-text search across everything, one SQLite database on your own Mac, no account and no note limit at any price. There is no web clipper, no phone app and no sync — so if what you loved about Evernote was that it was everywhere and caught everything from the browser, this is not a replacement, and I would rather say so than let you find out in week three.

None of that is a failure of memory. Symptoms are noticed rather than recorded, they change gradually, and the version you present in a consulting room is heavily coloured by how you feel that morning.

A page of notes changes the appointment substantially, and it takes very little.

What to write, and why each part

When it started, with an actual date. The most useful single item. "Since around 4 June" is clinically different information from "a few months", and you will only have it if you wrote it down near the time.

Frequency and pattern, in numbers. Twice a week, worse in the mornings, three bad days in the last fortnight. Counting is unglamorous and it converts an impression into something someone can work with.

What makes it better or worse. Noticed over weeks, invisible in a single day.

What you have already tried, and what happened. Including things that did not work, with rough dates. This prevents the loop where you are prescribed something you tried in March.

Every medication and supplement, with doses. Written down, because reciting from memory under mild stress is where errors happen.

Your three questions, written before you go. This is the one that changes the appointment most. Ten minutes goes fast, the conversation follows whatever the clinician opens with, and the thing you most wanted to ask is regularly the thing you walk out without asking.

Afterwards, five lines

Immediately, before you have left the building or straight after the call.

What they said, in their words. Not your interpretation. You will re-interpret it three times over the following week and end up with something that was never said.

The name of anything they named — a condition, a test, a medication, a referral. Spelled as best you can. This is what makes the rest of it searchable later.

What happens next, and who is doing it. The referral, the test, the follow-up in six weeks.

What you are supposed to watch for. The "come back if" list, which is the single most safety-relevant thing said in most appointments and the most commonly forgotten.

What you did not ask. For next time.

Five lines. It is the same discipline as writing up a meeting immediately, applied where the stakes are higher and the recall is worse, because appointments are mildly stressful and stress degrades memory precisely when you most need it.

Why the record beats the impression

A pattern you have written down is a fact. A pattern you have noticed is a feeling, and feelings about your own body are systematically distorted in a specific direction: whatever is true today feels like what has been true generally.

That matters in both directions. Something that has quietly worsened over eight months feels normal, because each week resembled the last. And a bad week after four good ones feels like a relapse when the record shows it is the first bad week since April — which is genuinely reassuring, and unavailable without a record.

Neither of these is available from memory. Both are available from a dated line a week.

Where these notes should not go

This is the part worth being deliberate about, because health notes are among the most sensitive text most people ever write.

Not in a shared workspace. Not in a work account, a team tool, or anywhere your employer administers. This should be obvious and it happens constantly, because the work app is the one people have open.

Not in a health app whose business model you have not read. The consumer health app category has a poor record on data sharing, and "anonymised" is doing a great deal of work in most of those policies. This is your medical history; treat the choice of where it lives as a decision rather than a default.

Not where a shared device will show it. A family iPad with your account signed in is a shared device.

Somewhere encrypted, ideally. Full-disk encryption at minimum, and per-note locking if your app offers it — the same reasoning as locking any note that would matter, applied to the clearest case there is.

The arrangement that matches the material is a local file on a machine you control, encrypted, with no account and no service in the middle. Not because companies are malicious, but because the safest data is data that was never transmitted, and this is the category where that principle is least worth compromising.

What this is not

Not diagnosis. A record of symptoms is input to a clinician, not a substitute for one. Searching your own notes for a pattern and concluding what it is has a worse track record than almost any other use of writing things down.

Not a substitute for your medical record. Your clinicians hold that, it is authoritative, and in many countries you can request a copy. Your notes are a parallel record of what you experienced and what you were told, which is a different and complementary thing.

Not a project. Five lines around an appointment, and a dated line when something changes. Anything more elaborate becomes a way of paying more attention to symptoms, which is not always helpful and is occasionally the opposite.

For someone else

Worth mentioning, because it is where this matters most and where it is hardest.

If you are managing appointments for a parent, a child or a partner, the same notes are more valuable and more difficult — the person in the room is not the person who remembers, and you are frequently coordinating between clinicians who are not talking to each other. One note per person, dated entries, medication list at the top, questions written before.

The same privacy considerations apply and are sharper, because this is somebody else's medical information and they did not choose where you keep it.

The honest version

Most people will not keep a health log, and for most people, most of the time, that is fine.

The version that is worth doing regardless is much smaller: write the date when something starts, and write down what you were told straight after an appointment. Two habits, thirty seconds each, and between them they cover the two things that reliably go wrong.

Cyanote is a reasonable place for it for one structural reason: everything is in a single SQLite database on your own Mac, with no account and nothing transmitted, and any note can be locked with a password and is encrypted where it sits. There are no AI features reading your notes and no sync service holding a copy. For a record of your own health, "nobody else has this" is not a feature claim — it is the requirement.

Meanwhile you are doing this in the evenings, around a job you still have, in a state of low-grade stress that is not conducive to remembering anything.

The spreadsheet everyone starts with is the right instinct and the wrong shape. It handles the list well and the content badly, and the content is what you actually need at the moment it matters — sitting down before a call, trying to remember what this company does and what you said last time.

What a job search actually needs

Three things, and a spreadsheet only does the first.

A view of where everything is. Applied, screening, interviewing, offer, rejected. One glance, no scrolling. This is genuinely the thing a spreadsheet is worst at, because a spreadsheet shows you rows and you need columns of stages.

A place for everything you know about each company. What they do, who you spoke to, what they asked, what you said, what the salary conversation was, what you liked and did not. This is prose, and prose in a spreadsheet cell is unreadable.

A follow-up that will not be forgotten. Dated, surfacing on the day, not living in your head at 2am.

The board

Columns as stages, one card per application. That is the entire tracking system.

Applied → Screening → Interviewing → Offer, plus a Rejected column that you do not delete from, because the record is useful later and deleting rejections makes the board a monument to only the parts that went well.

The reason a board beats a list here is that the question is always "what stage is everything at" — the board answers it without you reading anything. A list makes you scan a status column and assemble the picture yourself, forty times.

Keep the cards short. The card is a pointer; the substance lives in the note.

One note per company

Not per application, and not per interview. Per company, growing downward, exactly like a client note.

At the top: what they do in your own words, the role, the link to the posting (copy the text of it too — postings disappear the moment they close, often right before your final round), the salary range if stated, which version of your CV you sent, and where you found it.

Below: dated entries. Every call, every email, every name, every thing they said about the team or the timeline. Written within ten minutes of hanging up.

The reason this beats a spreadsheet is one specific moment: it is 9:50, you have a call at 10, and you need to remember what this company does, who you are speaking to, and what you told them last time. Open one note, read for ninety seconds, done. Any other arrangement means assembling that from three places while the call is starting.

What to write after every conversation

Ten minutes, while it is fresh, and this is where the whole system pays.

Who you spoke to, name and role, spelled correctly. You will need it for the thank-you email and for the next round.

What they asked. Especially anything that caught you out. This is the single most useful thing in the note, because the same question will come up at the next company and you will have a better answer ready.

What you said about salary, notice period, and why you are leaving. You must be consistent across rounds, and after six conversations you genuinely will not remember which version you gave to whom.

What you learned about them that is not on the website. Team size, what the last person in the role did, what they said when you asked what goes wrong.

How it felt. One line. Job searches distort judgement — an offer in hand makes everything look better and a rejection makes everything look worse — and the contemporaneous note is the only record of what you thought before the outcome existed. It is a small decision journal and it is exactly what you want when comparing two offers in a fortnight.

Follow-ups

Every conversation produces one dated task, immediately.

"Email Priya at Northwind thanking her, ref the platform question, by Thursday." Not "follow up with Northwind", which is a topic. The action, the person, the reason, the date — written as one sentence in the thirty seconds after the call, because that is the only moment it will get written.

And a second task for the chase: if they said two weeks, put "chase Northwind" at two weeks and one day. Recruiters are busy, timelines slip, and a polite chase on the day is the difference between a process that stalls and one that moves. It also spares you the daily background cost of wondering whether today is the day to chase.

What this is also for

Something people realise afterwards: the notes are the raw material for the next search.

The questions you were asked, the answers that worked, the salary numbers that were actually on the table, the things you learned to ask about — that is a genuinely valuable body of information, and almost everybody deletes it in the relief of having finished. Keep it. In three years it will save you a fortnight of relearning.

Keep the rejections too, with what you thought the reason was. Patterns across ten rejections tell you something no individual rejection does.

The honest version

A spreadsheet works. If you have six applications and a good memory, use one and do not build a system.

The threshold where this pays off is somewhere around fifteen applications, or the first time you arrive at a call unable to remember which company you are speaking to. Past that point the bottleneck is not tracking, it is context, and context is prose.

Cyanote covers both halves in one window: a board for the stages, notes for the substance, tasks with dates lifted out of the sentence you typed, and full-text search across everything you wrote so "who was the one with the four-day week" is one query. It is a local database on your own Mac with no account and no sync — which for a job search you are conducting while still employed is the practical consideration, not a philosophical one.

It is the wrong tool, and not because it is bad. It is built to answer questions a team has — who owns this, what is blocked, what is the status — and those questions have trivial answers when the team is you. Who owns it: you. What is blocked: nothing, you just have not done it.

The questions a solo practice actually has are different, and smaller.

The four questions

Almost everything you need from a system is one of these.

What did I promise this client, and when? The commitment question. It is the one that damages relationships when it goes wrong, and it goes wrong through ordinary drift rather than negligence — a thing said on a call in week two that neither of you wrote down.

What did we agree it costs? Scope. The most expensive failure in freelancing, and almost always a documentation failure rather than a negotiation one.

Where did we leave it? The context question. Six clients means five stale contexts at any moment, and reconstructing one from memory before a call is where the time goes.

What am I owed? Invoices sent, invoices paid, invoices quietly not paid for eleven weeks.

None of those needs a Kanban board with swimlanes. They need writing things down in a place you can find again.

The shape that works

One note per client. Not a folder, not a project, not a database — a note, which grows.

At the top: the boilerplate. Rate, contact details, how they like to be invoiced, the thing they told you in the first call that explains everything about how they work. Under that, dated entries, newest first, each a few lines: what was discussed, what was agreed, what you owe them, what they owe you.

That is it. It looks too simple to be a system, which is why it survives — there is nothing to maintain, and adding to it costs four lines after a call.

Why one note and not one per meeting: because the question you ask is almost always "where are we with this client", not "what happened on 14 March". A single scrolling note answers the common question directly and the rare one via search. A file per meeting inverts that, and you spend your time in a list of files instead of in the content.

The one discipline

Write the entry immediately after the call. Not later that day.

This is the entire method and the only part that requires anything of you. Four lines, in the two minutes while you are still holding the conversation. What was decided, what changed, what you now owe. Later that day, you will remember perhaps half of it, and the half you lose is disproportionately the commitments, because those were said quickly at the end while both of you were wrapping up.

Everything else in this post is optional. This is not.

Where the tasks go

Promises become tasks, and they should leave the client note.

A commitment buried in a paragraph in a client note is not tracked — you will only see it if you happen to reread that note. The line you wrote goes in the note as a record; the task goes in the to-do list with a date on it, because that is the thing that will surface on the right day.

This is where the type-it-as-a-sentence capture matters more for freelancers than for most people, since the moment you have to write it down is thirty seconds after a call, and any friction there means it does not happen.

The board view earns its place too, but not as project management — as one glance across clients: what is waiting on me, what is waiting on them, what is done and unbilled. Three columns. Personal kanban, applied to a business.

What to write down that people do not

The scope conversation, verbatim-ish. "Agreed the redesign covers the marketing pages, not the app." One sentence, written the day it was said, has settled more disputes than any contract clause, because it is not a legal instrument — it is a shared memory that turns out to be one-sided otherwise.

Every "could you also". They are not scope creep individually; they are scope creep in aggregate, and you cannot make the case in month three without a list.

How long things actually took. Not for billing — for quoting. The single most valuable dataset a freelancer can have is what their own estimates are usually wrong by, and it takes one number per project to build.

When you sent the invoice. With a date. The chase conversation is much easier when you can say which day.

What still needs a real tool

Being straight about the boundaries.

Invoicing and accounts. Use proper software. This is not a notes problem; it is a legal and tax problem, and the tools are cheap.

Contracts. Also not this. A note recording what you agreed is a memory aid, not an agreement.

Time tracking, if you bill hourly. A dedicated timer is better than anything you will improvise, though a focus timer pointed at a task will give you a rough count of sessions if you mostly want the shape rather than the invoice line.

Anything involving a team. The moment a second person needs to see status, everything above stops working and shared software starts making sense.

The honest version

If you are running eight simultaneous projects with subcontractors and deliverable dependencies, that is a small agency and it needs agency software. The advice here is scoped to one person with a handful of clients, which is the majority of freelancing and the case most tools are not designed for.

For that case the system is: one note per client, four lines after every call, promises moved to a dated task list, and a board when you want the overview. It fits in any app that has notes and tasks in the same place, and it fails in any arrangement where writing the four lines means opening a second app.

Cyanote keeps them in one window: notes that nest and link, tasks that take a date out of a typed sentence, a board view of the same tasks, and full-text search across every client note you have ever written. One SQLite database on your own Mac, no account, and a readable JSON export — which for client work is not a philosophical point but a practical one, since the confidential notes of a working practice are exactly the material that should not require somebody else's server to remain readable.

There is an app for the numbers. There is rarely one for the part that matters.

What the tracking apps miss

Specialised apps are excellent at quantities. Sets, reps, distance, pace, minutes, watering schedules, streaks. That data is real and it is worth having.

What they do not hold is the sentence that explains it.

You had a bad run on Tuesday. The app records a slow pace. It does not record that you had slept badly, that it was unusually humid, that the shoes were new, or that your knee felt odd from about mile three. Six weeks later, when the knee is a problem, the app shows a graph with a dip in it and no information about what happened.

The number is the outcome. The note is the cause, and the cause is what you would want to know.

The four lines

After a session, four lines. Ninety seconds.

What I did. The quantities, if you are not already logging them elsewhere.

How it felt. One word is enough — heavy, easy, sharp, flat. This is the single most predictive line in any practice log and it is in none of the apps. Three "heavy" sessions in a row is information you will otherwise notice a month late.

What I noticed. The technical thing. The bar drifting forward, the passage where you always slow down, the third bed drying out faster than the others, the phrase you keep mispronouncing. This is the line that makes the log worth rereading, because it is what you were working on, in your words.

What to try next time. One thing. Which turns the log from a record into an instruction, and means the next session starts with a plan rather than with remembering what you were doing.

Four lines. Not a training diary, not a journal. Four lines.

What shows up over a year

The reason to keep it, and none of these are visible session by session.

The conditions that predict your good sessions. Almost everyone has two or three, and almost nobody knows what they are without a record. Sleep, time of day, what came before, whether you had eaten. When you can see it across fifty entries, it stops being folklore about yourself and becomes something you can arrange.

Injuries and problems have a prologue. Something almost always felt slightly off for weeks before it became a problem, and you almost always dismissed it. The log is the only place that early signal survives, and reading back from an injury to find three mentions of the same niggle is both useful and slightly chastening.

Plateaus are usually shorter than they feel. Being stuck is a feeling generated by comparison with last week. Reading what you wrote a year ago is the corrective, and it is frequently the difference between continuing and quitting.

What you keep trying and abandoning. The same "work on this next time" appearing eight times over a year means you are not actually working on it. That pattern is invisible without the record and obvious with it.

Numbers where they matter, prose where they matter

Worth being clear on the division, because logging everything is how logs get abandoned.

Numbers: the quantity, and anything you genuinely compare over time. Weight, distance, minutes, count. Use the specialised app if you have one — it will graph them better than any notes app.

Prose: everything that explains the numbers. It does not need to be structured, tagged or quantified. "Felt heavy, third set collapsed, probably the 5am start" is worth more than a mood rating out of ten, because the reason is in it.

A grid for whether you turned up. A habit tracker's grid of days is the right shape for one specific question — consistency — and it is the one thing a prose log answers badly. Four weeks of squares shows a gap on the 3rd immediately.

Three formats, three jobs, and the mistake is asking one of them to do all three.

Where it should live

Somewhere you will still have in five years, which rules out most specialised apps.

This is the practical argument. A practice log is only valuable at a horizon of years — a year of running notes or three years of a garden is where the patterns are — and specialised tracking apps have an unusually high failure rate over that period. They get acquired, they move to subscriptions, they discontinue, they lose your history in a migration. Every long-term hobbyist has lost a log this way.

Prose in a general notes app that exports to a readable file is the arrangement most likely to survive to the point where it is worth something. The portability question is usually discussed for work notes, and it applies at least as strongly to a decade of training entries.

The honest version

Nobody keeps this up perfectly, and it does not need to be perfect. A log with gaps is still a log — the patterns come from volume, not from completeness, and a missed fortnight costs almost nothing.

If four lines is too many, keep one: how it felt, in a word. That single word, logged for a year, is more useful than most people's complete training data, because it is the variable everything else correlates with and the one nothing else records.

Cyanote holds all three shapes in one window: habits as a grid of the last four weeks, where a gap on the 3rd is visible straight down the page and any square is one click; notes for the four lines, searchable by any word in them years later; and routines for a warm-up or a session structure you repeat. It is one SQLite database on your own Mac with a readable JSON export — which for a record you are hoping to still have in 2036 is the part that actually matters.

You cannot. Nobody can. What you have instead is a story assembled after the fact, in which you knew roughly what would happen, and the surprises have been quietly written out because they no longer fit.

This is not a memory defect you can train away. It is how memory works, and it means that without writing something down, you cannot learn from your own decisions — you only get to learn from the versions of them you have already rewritten.

Why experience does not automatically improve judgement

You need three things for a decision to teach you anything: what you predicted, what happened, and a comparison.

The middle one is easy — outcomes are loud. The first is where it collapses, because by the time the outcome arrives you have already updated, and the updated belief feels like the original one. There is nothing to compare against.

The consequence shows up as two errors, both common in confident, experienced people. Outcomes get credited to reasoning that was not there — a good result from a bad decision that got lucky, remembered as good judgement. And bad outcomes get blamed on things nobody could have known, when the risk was in fact identified at the time and dismissed.

A decision journal fixes exactly one thing: it preserves the prediction so a comparison is possible. That is the whole mechanism, and it is why five lines beat any amount of reflection.

The five lines

Write these before you know how it turned out. That is the only rule that matters.

The decision. One sentence, plainly. "Taking the contract with X instead of Y."

What I expect to happen. Concrete enough to be wrong. Not "it should go well" — "I expect this to take six weeks and lead to more work in the spring."

Why — the two or three actual reasons. Not the justification you would give someone else. The reasons that are doing the work, including the unflattering ones. "Mostly because I want the money now and Y felt like a longer conversation."

What would make this wrong. The single most valuable line, and the one everybody skips. Name the thing that, if it happened, would mean this was a mistake. It forces you to hold a version of the world where you are wrong, at the one moment when you can still see it.

How I feel. Rushed, excited, cornered, relieved. State is a strong predictor of decision quality, and it is completely invisible in hindsight — you will never remember that you decided this while exhausted, but you will be able to read it.

Five lines. Two minutes. The whole method.

What to log, and what to leave alone

Not everything. A journal of every decision is a journal nobody keeps.

Worth logging: anything you would be annoyed to get wrong and will find out about within a year or two. Hiring someone. Taking or leaving a job. A significant purchase. Choosing a technology you will live with. Ending or continuing something. Any decision where you notice yourself arguing internally — that argument is the signal.

Not worth logging: reversible decisions, small ones, and anything whose outcome you will never learn. If there is no feedback, there is nothing to compare, and the entry is journalling rather than calibration.

Most people end up with somewhere between one and four entries a month. If you have twenty, you are logging preferences rather than decisions.

The review is half the value

An entry nobody rereads is a diary. The comparison is where the learning lives.

Set a date when you write it. "Check this in three months." Put it on the calendar or in the task list as a real dated item, because you will not spontaneously remember. This is the single most common failure of decision journals: the entries are excellent and nobody ever opens them again.

When the date arrives, read the entry before assessing anything. Read your prediction first. Then compare. The order matters enormously — read the outcome first and you will find your prediction was basically right, because that is what minds do.

Score the decision, not the outcome. This is the discipline that makes the whole practice worth doing. A good decision can have a bad outcome; a bad one can get lucky. If you only grade outcomes you will learn to be lucky, which is not a skill.

Look for patterns across entries, not lessons within one. One decision teaches you almost nothing. Ten teach you a great deal — that you consistently underestimate how long things take, that you decide badly when cornered, that your worst calls are the ones you made quickly to end a conversation. Those patterns are the actual product, and they only appear in aggregate.

Where it should live

In your ordinary notes, not a special app.

A decision journal in a dedicated tool becomes a thing you visit; in the same collection as everything else, it is a thing you pass. That matters, because the moment of writing is always the same: right after the decision, when you are moving on to the next thing and any friction means it does not get written.

Two mechanics make it work in practice. The review date needs to become a real task with a date on it, or the loop never closes — which is easiest if writing a dated task takes one sentence. And entries want to be linkable to the thing they are about, so a decision about a client shows up next to that client's notes without being filed there twice. That is the small linking habit doing useful work rather than decorative work.

The honest version

This is a slow practice with no visible payoff for a year. The first ten entries feel pointless, because there is nothing to compare them to yet, and most people stop somewhere around entry four.

It is also close to the only reliable method for improving judgement that does not require anyone else's involvement, and it costs two minutes a fortnight. The trade is heavily in your favour if you can survive the first year of it doing nothing.

Cyanote has a decision-journal template in the / menu — the five prompts above, in order, so an entry is a fill-in rather than a blank page. It sits in the same collection as the rest of your notes, searchable by any word in it, linkable to whatever it concerns, with a task carrying the review date. Everything lives in one SQLite database on your own Mac: for a document that records what you actually thought and how you actually felt, that seems like the right place for it.

Both situations produce the same paralysis, and it is not a technical one. The technical part — opening files, searching them — is easy. The difficulty is that you are holding a document that was written by someone who did not expect you to read it, and there is no obvious rule for what to do with that.

First, the question about reading

Before any organising, one decision: is this material you should be reading at all?

Work notes, handed over deliberately. Yes. That is what a handover is, and the person wrote it expecting exactly this.

Work notes found on a machine, not handed over. More care. A departed colleague's personal file may contain their own frustrations, their salary conversations, their private assessment of you. Look for what you need to do the job and stop when you have it. There is no obligation to read someone's diary because it happened to be on a work laptop.

A relative's private writing. The hard one, and it deserves a real answer rather than a technical one.

About a relative's journals

There is no rule here and anyone offering one is overreaching. What can be offered is the set of considerations people find useful.

Look for a stated wish first. In a will, a letter, a note at the front. People sometimes leave one and it is frequently missed, because nobody thinks to look for it before opening the files.

Consider that they knew they would die and did not destroy it. That is not consent. It is also not nothing — for a lot of people the journal was left because it was theirs and they were not going to spend their last months curating, and they would not have wanted it read.

Slower is better. There is no deadline. Deciding not to read something now does not prevent reading it in five years; reading it now cannot be undone, and things read in grief land differently than the same words read later.

A journal is not a message to you. This is the observation people find most useful afterwards. Journals are where people put the worst version of a bad week, because they had nowhere else. Reading a difficult passage as a considered summary of what they thought — of you, of themselves, of anything — is almost always a misreading. It was Tuesday, and they were angry, and they wrote it down instead of saying it.

Whatever you decide, back it up first. That decision does not have to be made under time pressure and it certainly should not be made irreversibly.

The practical part: making it searchable

Once you have decided what to engage with, the technical problem is straightforward.

Copy everything before touching anything. One copy on a separate disk, untouched. Everything else happens on a working copy. This is the whole insurance policy and it takes ten minutes.

Establish what format it is in. Plain files are trivial. An app's database is workable — SQLite is an open format and readable by free tools if the original app is gone. A proprietary blob may need the original software, which is a reason to try installing it before anything expires.

Get it into text if you can. Whatever the source, an export to Markdown or plain text into a folder means Spotlight indexes it and grep finds anything Spotlight misses. That is a working search over somebody's entire collection for about an hour of effort.

Do not reorganise. Strong recommendation. Their structure encodes their thinking, and imposing yours destroys information you do not yet know you need — most obviously the order in which they wrote things, which is often the most informative property of the whole collection. Search, do not sort.

What to look for in work notes

If this is a professional handover, the useful material is narrower than the volume suggests.

The undocumented facts. The reason something is done a strange way. The client who needs a phone call. The system that fails in a particular manner. These are what a handover document is supposed to capture and frequently does not.

Who they talked to. Their notes name people, and those people know things. Often the most valuable output of reading somebody's notes is a list of six names to go and ask.

What was in flight, and its real state. Distinct from its reported state, which is what the shared tracker has.

Their judgement. What they thought was actually wrong. Worth reading and worth weighing — they had context you do not, and they also had frustrations that may have coloured it.

You can usually extract all of this in an afternoon with search, without reading the collection front to back.

Then write down what you learned

The step everybody skips, and the reason the same loss happens again in two years.

Reading somebody's notes produces understanding that exists nowhere in writing. Put it somewhere: a short document of what you found, where the material is, and what the six important facts turned out to be.

Because the material itself is not the deliverable. Nobody will read a colleague's decade of notes twice, and if you do not extract the useful part now, the collection reverts to an archive nobody opens — and the fact that you once understood it is lost the same way theirs was.

For your own collection

The obvious corollary, and it is a two-minute job.

Whoever inherits your notes will face the same decisions with the same lack of guidance. You can remove that entirely by leaving one line somewhere findable: what should be kept, what should be read, what should not, and what should be destroyed. It costs nothing to write and it converts an impossible decision into an instruction.

That plus where the material is and how to get into it is the whole of a digital estate for notes, and it is worth doing while it is easy.

The honest version

The technical half of this is an afternoon. The other half is not a technical problem and there is no correct answer — only the observation that reading cannot be undone, backing up can always be done first, and nothing here has a deadline.

Cyanote is on the easy side of the technical question by construction: everything is in one SQLite database on the machine, in an open, documented format that outlives any particular app, and it exports to one readable JSON file. There is no account to recover and nobody here to ask, which is the guarantee working as intended — and the reason to leave a line about what you want done, while you can.

Nobody will read it. Not through rudeness — because a list of responsibilities does not answer any question a person actually has, and the questions only arrive later, when you are gone and something has broken.

Write it as answers, not as an inventory

The reframe that makes handover documents useful: write down the answers to the questions people will ask you after you have left.

That is a genuinely different document. It is not "I am responsible for the billing pipeline". It is "when billing fails overnight, it is almost always the currency conversion job, the logs are here, and Priya knows the manual fix."

You already know what those questions are, because you have been asked them. The list of things people interrupt you about is the handover document, and it is much shorter than an inventory of your role.

The five things worth writing down

The undocumented facts. Things that are true, that matter, and that exist nowhere but in your head. The service that must be restarted in a particular order. The client who needs a phone call rather than an email. The report that looks broken and is not. These are the highest-value lines in any handover and they are invisible to everyone except you, because to you they are simply how things are.

Who to ask, for what. Not the org chart — the real map. Who actually knows the payment system. Who to go to when the official route is stuck. Who will say yes to a small exception and who will not. This is the knowledge that takes a new person a year to acquire and ten minutes to write down.

What is in flight, and where it actually is. For each open thing: what state it is genuinely in, what the next step is, and what nobody else knows about it. Be honest about the ones that are stalled, including the ones stalled because you were avoiding them. That is the kindest thing in the whole document.

What will break, and when. The certificate expiring in March. The contract renewing in June. The thing that always fails in the last week of the quarter. Known future events with dates on them are the single easiest thing to hand over and the most commonly forgotten, because they are not on anyone's list yet.

What you would fix next. Your judgement about the shape of the thing, which is worth a lot and which nobody will ask for. Two or three lines about where the real problems are. Whether they act on it is not your concern; leaving it is a courtesy to whoever inherits the same frustrations.

Where to write it

In the shared system, not in your personal notes. This is the one document that belongs on the company's infrastructure — a wiki, a repo, wherever the team's knowledge lives. A handover in a personal file is a handover nobody can find.

Which is the other half of the split worth keeping deliberately: your own work log and your own notes go with you, and the operational knowledge stays. Deciding that consciously in your final weeks avoids both failure modes — taking things you should have left, and leaving things that were yours.

The two weeks before

Start now, not in the last week. The final week is meetings, goodbyes and access being revoked. A handover written then is thin, and it is written in a state of already having left.

Write it as you get asked things. For your remaining weeks, every time someone asks you a question, write the answer into the document rather than only replying. This produces a document about the things people genuinely ask, which is exactly what you want and impossible to guess in the abstract.

Do the walkthrough, and let them drive. Sit with whoever is taking over and have them do the task while you watch. This is the step that finds the gaps — everything you forgot to mention surfaces in the first ten minutes, and nothing else surfaces it. A walkthrough where you drive and they watch teaches almost nothing.

Say where the accounts and access are. Not credentials — where they live, which password manager, who administers them, what will need transferring. Access is the most common thing to break after somebody leaves, and it is the easiest to prevent.

Being honest about the stalled things

The section people write badly, and it is worth doing well.

There is always something you have been avoiding. A conversation not had, a decision deferred, a bug you keep deprioritising. The instinct is to leave it out of the handover, or to describe it in language that makes it sound like an ordinary open item.

Do not. Write down what is actually true, plainly: this has been open for five months, here is why, here is what I would do. Nobody is going to think less of you on the way out, and the alternative is that someone discovers it in three weeks with no context and forms a much worse impression than the honest version would have created.

What this is also for

Two things beyond the obvious.

Writing it is the clearest picture you will ever have of your own job. People are routinely surprised — by how much they were holding, by how much was undocumented, by how much of the role was not in the job description. That is worth knowing at exactly the moment you are deciding what to look for next.

It is CV material. Not the document itself, but the process of writing it surfaces everything you did and everything that depended on you. Copy the useful parts into your own work log before you lose access.

The honest version

Some handovers do not matter. If the role is genuinely replaceable and well documented, an afternoon is plenty and a thorough document is effort spent on nobody's behalf.

Where it matters is where you were the only person who knew something — which is far more common than organisations like to admit, and which you are the only person in a position to notice. If there are five facts that exist only in your head, writing those five down is the whole job, and everything else in this post is optional.

Cyanote holds the half that is yours: your work log, your record of what you were promised, your judgement about what was actually going on, in one local database on your own Mac that does not need a company account to keep working. The handover itself belongs in whatever the team uses — but writing it is much easier from a set of notes you have been keeping all along than from four weeks of trying to remember.

If your notes live in one database on one Mac, they are on one Mac. There is no phone app, no web view, and no clever architecture that makes a file on your desk appear in your pocket. That is not a missing feature; it is the same property that gives you the speed, the privacy and the not-having-an-account, seen from the other side.

So: what do people actually do about it, and is it enough?

First, the question that decides everything

Not "do I want my notes on my phone". Everyone says yes to that.

The question is: in the last month, how many times did you need something from your notes while away from your Mac, and could not get it?

Count honestly, in actual incidents. For a lot of people the number is one or two, and both were "the address of the place I am going", which is a solved problem. For others it is several times a week, because they genuinely read and write on a phone all day.

If your number is high, stop here. A local-first single-machine app is the wrong tool and no workaround fixes it — you want something with a real phone client and real sync, and paying for one is the correct decision. The rest of this is for people whose number turned out to be low, which is more people than expect it.

The four routes

In ascending order of effort, descending order of how often you need them.

One: send it to yourself. The thing you need on the phone is usually one address, one code, one paragraph. Message it to yourself, or email it. This looks unserious and it covers the overwhelming majority of real cases, because the real case is one item and not a library. The reason it feels like a hack is that we have been sold sync as the general solution to a problem that is almost always specific.

Two: put the phone-shaped things in a phone-shaped app. Your phone already has notes and reminders that sync for free and work brilliantly. Use them for what phones are for — capturing something while standing up, a shopping list, an address — and let the Mac hold the writing you do sitting down. This is not defeat. Two apps with clearly different jobs is a workable system; two apps with the same job is the mess people are trying to escape.

Three: export and read. Any local app worth using exports. A JSON or Markdown export into a folder your phone can reach means the archive is readable when you need it. It is not live and it is not editable. For "I need to look something up while travelling", it is entirely sufficient, and it is the same file you should be producing for backup reasons anyway.

Four: reach the Mac itself. Screen Sharing to your own machine over the network, or a remote-desktop app, and the notes are right there. Clunky, occasionally invaluable, and worth knowing exists before the day you need it.

What you should not do

Do not put the app's live database in iCloud Drive or Dropbox. It is the obvious idea and it is the one that ends badly. A sync service copies whole files after they change; a database is written to continuously, and two machines writing to one synced file produces conflicted copies or a silently chosen winner. You can move an app's storage to another disk or folder safely. Moving it into a folder that two machines are actively syncing is how corruption happens, and it happens quietly.

Do not run a self-hosted sync server unless you enjoy that. It works and some people love it. It also means you now operate a server, with the certificates, updates and 2am failures that implies. If that sentence sounds appealing, go ahead. If it sounds like a chore, it will be one.

The part nobody says about phone notes

Having your notes on your phone is not the same as using them there.

Watch what actually happens on a phone: capture, and lookup. You write four words while standing on a platform, or you check an address. Reading a long note on a phone is unpleasant; writing one is worse; reorganising anything is a genuinely miserable experience that people do once and never again.

Which means the phone requirement, examined closely, is usually capture plus lookup — two narrow jobs — and not "the full system, everywhere". Capture is solved by any app with a text field, including the one already on the phone. Lookup is solved by an export, or by having sent yourself the one thing you needed.

The full-sync solution solves all three jobs including the one nobody does. That is fine if it is free, and it is a real cost if it means an account, a subscription, and a spinner where your notes should be.

The version that works in practice

For people who have made this work, the shape is consistent:

• The Mac is where the writing lives. Long notes, the archive, the search, the actual thinking.
• The phone's own notes app is the inbox. Anything captured away from the desk lands there, and gets moved over — or not — during the weekly review.
• Anything genuinely needed on the go gets sent ahead, deliberately, the way you would check you have the tickets.
• An export sits somewhere reachable, updated occasionally, for the lookup case.

That is not as good as real sync. It is meaningfully cheaper, in money and in what it asks of your data, and for a lot of people the gap turns out to be smaller than the fear of the gap.

The honest version

I would rather say this plainly than sell around it: if you need your notes on your phone, buy something that does that. Apple Notes is free and excellent at it. Obsidian syncs a folder of files, including through iCloud Drive or Dropbox, because the notes are files rather than a live database. Notion is in any browser. All three are better answers to that requirement than any workaround above.

Cyanote is a Mac app with one database on your own disk, no account and no sync — and no phone app. The trade is the whole design: everything opens instantly, nothing needs a connection, and no copy of your writing exists anywhere you have not put it. Everything exports to a readable JSON file whenever you want, which is the route out and the route to any other device. If the four routes above sound like too much friction, that is a real answer, and it is worth knowing before you pay rather than after.

The shutdown at the end of the day where you always forget one thing. The invoice run where the numbers are right and the sending happens Tuesday. The publish that works except for the one cache nobody clears. Each of these has a shape, you have performed it forty times, and you still occasionally drop a step, because holding six things in your head while doing the first one is not something people are good at.

A recurring task is not a checklist

This is the mismatch, and most to-do apps only offer the first one.

A recurring task says: do the thing. "Invoicing, every Friday." It appears, you tick it, it comes back next week. What it never tells you is what the thing consists of, so the contents live in your head and degrade quietly. You did it forty times, so you are confident, and confidence is precisely the state in which a step gets skipped.

A checklist says: the thing is these six items, in this order. You do not have to remember; you have to read. That difference is the entire value, and it is why aviation, surgery and every industry with expensive mistakes converged on the same boring artefact.

The half-finished weekly job is almost always a recurring task pretending to be a checklist. The fix is not more discipline. It is writing the six items down once.

What makes a checklist that survives

Most home-made checklists die within a month. The ones that hold have a few properties in common.

Written during the job, not before it. A checklist authored in advance describes what you imagine you do. One written while actually doing the thing — jotting each step as you take it — describes what you actually do, including the small awkward step you would never have thought to include and which is exactly the one that gets forgotten.

Every item is a physical action. "Check the deploy" is not an item; it is a category. "Open the status page and confirm the version number" is an item, because you can be certain whether you have done it. If an item's completion is a matter of opinion, it will be ticked in a mood rather than in fact.

In the order you actually do them. Not grouped by theme, not sorted by importance. Sequence is what makes a checklist a checklist — you are meant to read the next line, not scan a set.

Short. Six to ten items. Past that, people stop reading and start pattern-matching, which is the failure the checklist existed to prevent. If it genuinely has thirty steps, it is two or three routines.

Edited on the day it fails. The first time you follow it and something still goes wrong, add the line. A checklist that is never revised is a document; one revised four or five times is a tool.

Where a clock belongs, and where it does not

Some checklists need timings and most do not.

A shutdown routine has no timings. Six steps, done at the pace they take, and putting a clock on them adds pressure to a thing whose purpose is to end the day calmly.

A morning routine or a focus block sometimes does, because the timing is the method: twenty minutes on this, ten on that, and the constraint is what stops the first item eating the hour. This is where a checklist and a timer belong in the same object rather than in two apps — the same argument as a Pomodoro timer that lives where the work does.

The rule of thumb: put a clock on a step only when finishing on time is part of doing it correctly. Everywhere else, a timer is decoration that turns a helpful list into a small performance review.

The five that most people end up with

Not a prescription — an observation about what recurs.

A shutdown. The five things that make tomorrow morning start cleanly rather than in a heap: close the loops, write down where you got to, clear whatever inbox you keep.

A start. The two or three things that put you in front of the work rather than in front of your email. Usually shorter than people expect.

A weekly review. The one everybody has heard of, which works when it is a checklist and stalls when it is an aspiration. Twenty minutes is the realistic version.

A recurring work job. Invoicing, publishing, reporting, the backup you verify. Whatever your version is of a job with steps that comes back on a schedule.

A leaving-the-house or travel list. Unglamorous, and the one that has saved most people the most actual money.

Where this goes wrong

Turning a checklist into a habit tracker. They look similar and measure different things. A habit is one recurring action you are trying to make automatic; a routine is several actions that need to happen together. Ticking a six-item list and calling it a streak conflates "did the thing" with "did all of the thing", and the number stops meaning anything.

Building the system instead of using it. There is a version of this where you spend a Sunday designing eleven routines with nested sub-steps and colour coding, and follow none of them. The rule that prevents it: write one, use it four times, then write the second.

Keeping them somewhere you do not open. A checklist in an app you visit weekly is a checklist you will not read at the moment you need it. It has to be where you already are when the job starts — which is usually the same window as your notes and your day, not a separate icon you have to remember exists.

The honest version

If your checklists coordinate other people, have conditional branches, or need an audit trail of who did what, this is a workflow tool problem and a proper one will serve you far better than a list in a notes app. Process management is a real category and it exists for good reasons.

For your own recurring jobs, the whole thing is: six items, in order, somewhere you will see them. That is close to a solved problem and needs almost no software.

Cyanote's routines are checklists with an optional clock on the steps where the clock is part of the method, sitting in the same window as the notes, the tasks and the day. Today shows the routines not yet run alongside what is due and which habits are outstanding, so a routine is something you meet rather than something you have to remember to go and open. It all lives in one database on your own Mac, which means your shutdown list is not an item on somebody's server.

For a lot of people that assumption does not hold, and the result is a persistent, unfair sense of being bad at systems — when what has actually happened is that every system on offer was designed around a capability that varies enormously between people, and nobody said so.

If your experience is that the intention evaporates between having it and reaching somewhere to record it, none of the standard advice is addressing your problem. This is about the version that does.

The principle: never depend on a second step

Every gap between the thought and the record is a place it can disappear. Standard advice puts several of them in a row: have the thought, hold it, get to the app, decide where it goes, write it, later process it into the right place.

That is five opportunities to lose it, and the advice implicitly assumes the loss rate at each is near zero.

Design instead so that a thought recorded once is done. No processing step, no filing decision, no "I will sort that later" — because later is exactly the thing that does not reliably arrive.

What that means concretely

One destination, no decision. Everything goes to the same place. A daily note, an inbox note, one list. Not because it is tidy, but because a choice about where is a step, and steps are where things are lost. Search will find it later; that is what search is for, and it is why filing matters less than people think.

Capture reachable from anywhere. A global shortcut, not an app you switch to. If recording something requires finding a window, the window is a step.

Instant. Under a second. A loading spinner is long enough for the thought to go, and this is not hyperbole — it is the actual failure.

Nothing to process. Systems requiring an inbox to be emptied on a schedule fail here specifically, because the processing session is a recurring appointment with your future attention and it is the first thing to be missed. A system that works without processing is worth more than a better-organised one that requires it.

No decisions at capture time. No category, no priority, no project, no tags. Type the sentence, press return. Anything the app can extract from the sentence itself — a date, a time, a priority — is free; anything requiring a separate choice is a step.

Pull, not push, for retrieval

The other half, and it is where most systems fail people quietly.

Notifications are the standard answer to "how will you remember", and they work poorly here: they arrive when you cannot act, get dismissed reflexively, and the dismissal is complete — no trace, no queue, nothing to come back to. A reminder that fires while you are driving has not reminded you of anything.

What works better is one place you go, containing everything currently relevant, so that arriving is enough and no interruption has to survive. Today's list, checked at a moment that already exists in your day — after coffee, when you sit down, before you leave. Attaching it to something that already happens is the whole trick, because an attached habit survives and a new ritual does not.

Externalise the sequence too

If holding a multi-step task in your head while performing it is unreliable, the fix is not to try harder. It is to write the steps down and read them.

That is what a routine is — six items in order, read rather than recalled. It is not a compensation for a deficiency; it is what aviation and surgery do, for the same reason, with people whose memory is fine.

The list of things you do every time you leave the house. The sequence for the recurring job that always loses a step. The morning order that gets scrambled when something interrupts it. Writing them down converts a memory task into a reading task, and reading is much more robust to interruption.

Redundancy is not untidy

A rule from standard advice that is worth dropping: everything in exactly one place.

If writing it twice makes it more likely to be found, write it twice. If the important date is in the calendar and the task list and on a note stuck to the monitor, that is three chances, and three chances is the point. The cost of duplication is mild untidiness; the cost of a single point of failure is a missed thing.

Optimise for the thing being found, not for the system being elegant.

What tends not to work

Said plainly, so it can be stopped rather than repeated.

Elaborate systems. Anything with more than about two rules. Every rule is a thing to remember about the system, on top of the things you were trying to remember with it.

Inbox processing. Any design where capture is provisional and a later session makes it real.

Reminder escalation. More alerts, louder, more often. Produces dismissal reflex faster than it produces action.

Blaming yourself for the last one failing. Six abandoned systems is information about the systems. It is very commonly read as information about the person, and that reading is what makes people stop trying.

The honest version

I am describing a design pattern, not giving anyone advice about their brain, and there is no software that fixes this. What software can do is remove steps — and since the number of steps is the whole variable, that is not a small contribution.

The two changes that do the most: one destination with no decision at capture, and one place you go, rather than notifications that come to you. Almost everything else is optional.

Cyanote is shaped that way, though not deliberately for this: ⌘N and ⇧⌘D reach a note in one keystroke, tasks take their date and priority out of the sentence so there is nothing else to fill in, ⌥⇧C brings the window up from any app, and Today is one view holding what is scheduled, what is due, which habits are outstanding and which routines have not been run. There is no inbox to process and no filing required — full-text search across everything is what makes that viable. It opens in under a second from a local database, which is the part that actually decides whether a thought survives the trip.

What that button actually grants is worth reading before you press it. OAuth scopes for calendar access are not "show me what is on Thursday". They are, typically, read and write access to every calendar on the account, held by a third party, valid until you go and revoke it — and, depending on the app, a copy of your events sitting on that third party's server so their sync can work while your laptop is closed.

For a calendar app you have chosen deliberately, that may be a fine trade. For a notes app that also happens to show your week, it is a lot to hand over so that Thursday has three lines on it.

There is a middle option. It has existed since the late nineties, it is boring, and almost nobody mentions it.

Subscribing instead of signing in

Every major calendar service can hand out a secret address: a long URL that returns your calendar as an ICS file, the plain-text format calendars have used for decades. Any app that can fetch a URL can then show your events.

In Google Calendar it sits in an individual calendar's settings under "Integrate calendar", named the Secret address in iCal format — and Google's own help page for it files it under getting a view-only copy, with the instruction that only you should know the address and it should not be shared. Apple's iCloud calendars can be made public and produce a comparable link. Outlook has its own version. Most work calendars, university timetables, sports fixtures and bin collections publish one too.

What you get:

• Read-only. The app can display your events. It cannot create, move or delete anything, because the format has no way to write back. For seeing your week next to your notes, read-only is the entire requirement.
• No account, no token, no scope. Nothing is authorised. There is no session to revoke and no app sitting in your Google security settings.
• Per calendar, not per account. Subscribe to your personal calendar and leave work alone, or the other way round. Signing in is all-or-nothing at the account level; a link is one calendar.
• Revocable in one click. Regenerate the address in your calendar's settings and every copy of the old URL stops working immediately.

The honest caveats

This is where most write-ups of this trick stop, so: three things you should know.

The URL is the password. Anyone who has it can read that calendar, forever, without logging in as you. Do not paste it into a shared document, a support ticket, or a chat with your team. If you think it has leaked, regenerate it — that is what the button is for.

It still makes a network request. Your app fetches that URL from Google, so Google sees a request from your IP on some schedule. This is not local and it is not private from Google. It is only private from everyone else: no third-party app holds a token, and no third-party server holds a copy of your events.

It refreshes on a delay. Subscribed calendars are polled, not pushed: your app asks for the file every so often, and the publisher decides how current the file it hands back is. In practice an event you add on your phone can take hours to appear in a subscribed view, and neither end promises otherwise. For a week you are looking at rather than editing, that is fine. If you need something you just accepted to show up within seconds, subscription is the wrong mechanism and you want a real sync.

The other option: import the file once

If even one request is more than you want, download the .ics file and import it. Your calendar app can export one; so can most event pages and every conference that sends you a booking.

This makes literally zero network requests. It also does not update, ever — it is a snapshot. Which sounds useless until you notice how many calendars never change: a term timetable, a fixture list, the twelve dates of a course. Importing those once is not a downgrade. It is the correct shape for the data.

The two mechanisms cover different things, and most people want both: subscribe to the calendar that moves, import the ones that do not.

What this cannot do

Worth being plain, because a subscription genuinely gives up capability.

You cannot create an event and have it appear on your phone. You cannot accept an invitation. You cannot see whether a room is free, or free/busy for a colleague. You cannot move a meeting and have anyone else find out. All of that needs write access, and write access means signing in.

So the real question is what you want the calendar in this app for. If it is scheduling with other people, use the app your organisation already runs on and sign into it properly. If it is knowing what today looks like while you are writing your notes and picking what to work on — the what does my day look like question — then read-only covers it entirely, and paying for it with a permanent OAuth grant is a bad exchange.

Events you create locally are a separate thing

There is no rule that every event has to come from a server.

Personal things — a deadline you set yourself, a repeating block for focused work, the day the car needs its service — do not involve anyone else and gain nothing from living in the cloud. Created locally, they stay on your machine, work with the wifi off, and are not one account recovery away from being someone else's problem.

Most people end up with a mix: work events arriving read-only by subscription, personal ones created in place. That is not a compromise between two systems. It is the shape the information already had.

The honest version

If your day is meetings, a real calendar client is the right tool and Fantastical or Apple's Calendar will serve you far better than anything bundled into another app. Nothing here competes with them, and the moment you need to reply to an invitation you will want one open anyway.

For everyone else, the useful realisation is that the sign-in button is not the only door. A read-only address does about ninety percent of what looking at a calendar involves, at none of the cost.

Cyanote takes both routes and neither requires an account: paste a calendar's ICS address to subscribe, or import an .ics file and make no requests at all. Events you create yourself carry a time, a place and notes, repeat daily, weekly or monthly, and can remind you 5, 10 or 30 minutes, an hour or a day ahead — with the reminder following a repeating event between occurrences. All of it sits in one local database with the notes, tasks and habits, and the only calendar request that ever leaves the machine is the one for a feed you asked for.

The useful move is not reading more of them. It is checking — which is easier than most people assume, takes about ten minutes, and turns a claim into an observation. And it works on any app, including the ones whose pages you have never read.

What "telemetry" actually covers

The word is used loosely enough to hide things, so it is worth separating.

Analytics. An SDK reporting which screens you opened, which features you used, how long you stayed. Usually a third party. Usually described as "anonymous", which is doing more work in that sentence than it can carry — a device identifier plus a usage pattern is not anonymous in any useful sense.

Crash reporting. Sends a stack trace when the app falls over, often with a device identifier and sometimes with surrounding memory. Genuinely useful to developers and genuinely a data transfer.

Update checks. The app asks whether a newer version exists. This one is close to unavoidable for software distributed outside an app store, and it is the most defensible of the four — though it is still a request, still carries your IP, and can carry an identifier if the developer chose to include one.

Licence and account calls. Checking that your key is valid, or your session, or your subscription. Frequency is the tell: once at install is one thing, at every launch is another.

An app with none of the first two and one of the last two is a normal, honest arrangement. An app with all four, none of which is disclosed, is a different proposition.

How to check, in ten minutes

Three routes, in ascending order of effort and certainty.

Read the privacy page for specifics, not adjectives. A page that says "we respect your privacy" tells you nothing. A page that names the exact endpoints, what each one carries, and how often it fires is making claims you can then verify — and the willingness to be that specific is itself a signal.

Watch the connections. macOS ships with the tools. Open Activity Monitor, go to the Network tab, and watch the app's data figures while you use it. An app that transfers steadily while you type is doing something worth asking about. For detail, nettop -p <pid> in Terminal shows live connections per process, and lsof -i -a -p <pid> lists what it currently has open.

Use an outbound firewall. This is the real answer if you want certainty. Little Snitch and LuLu both intercept outbound connections and ask you to approve each one, by app and destination. You will learn a great deal in the first week — much of it about apps you had never suspected — and you can simply deny the ones you do not want. LuLu is free and open source; Little Snitch is paid and more capable.

The blunt test: turn the wifi off and use the app for ten minutes. Anything that stops working was talking to something. This does not find the quiet stuff, but it is free and takes no setup, and it is the same wifi-off test that tells you about offline capability.

What you will find, and what to make of it

Expect more connections than you assumed, and do not treat every one as a betrayal.

A request to api.<the developer's domain> once when you first enter a licence key is a licence check. A request to an update endpoint a few seconds after launch is an update check. A font loading from a CDN is a design decision. None of those is telemetry, and finding them is not a scandal.

What is worth reacting to: a third-party analytics domain, a crash reporter you were never asked about, a request that fires every time you open a document rather than every time you open the app, and — most of all — anything that scales with what you write rather than with what the app does. Request volume proportional to your content is the signature that matters, because it means content is going somewhere.

The part that is not about trust

There is a version of this argument that ends in paranoia, and it is not the useful version. Most developers who collect analytics are trying to find out which features are unused, which is a reasonable thing to want.

The point is not that data collection is malicious. It is that it is a surface: a copy of something about you, on infrastructure you do not control, subject to a breach at that company, an acquisition, a policy change, or a subpoena. Every one of those has happened to companies with sincere privacy pages. The only reliably safe data is data that was never transmitted, and that is an architectural property rather than a promise about intent.

Which is why the strongest version of this is not "we handle your data carefully". It is "there is no data here to handle" — the local-first arrangement, where the absence of a server is the guarantee.

What good disclosure looks like

If you want a standard to hold apps to, this is a fair one:

• An exhaustive list of endpoints, not a summary. "These are the only requests" is a claim that can be falsified by watching the network, which is what makes it worth something.
• What each request carries, including what is inferable from it. An anonymous request still carries an IP address and a timestamp, and an honest page says so.
• How often it fires, in real units. "Periodically" is not a unit.
• What is not sent, stated plainly, so the absence is on the record.
• No third parties, or a clear statement of which ones and why.

An app that publishes all five and is telling the truth is verifiable in ten minutes. An app that publishes none of them may be perfectly fine — you just have no way to know, and no way to find out except by watching.

The honest version

You do not need to audit every app on your Mac. That is a hobby, not a security posture.

Audit the ones holding things you would not want copied: your notes, your journal, your client files, your passwords. For everything else, a privacy page is probably enough, and the checking is only worth ten minutes for the apps where the content matters.

Cyanote makes exactly three requests, and this is the whole list. A one-time licence check to api.lemonsqueezy.com when you first install, carrying your key and a label with the version and OS. An anonymous update check to updates.cyanote.app a few seconds after launch and every six hours the app stays open — no key, no account, no identifier. And a calendar feed, only if you subscribe to one, going to whoever runs that calendar rather than to us. There is no analytics SDK, no crash reporter, no usage pings and no install identifier, and none of the three requests carries a word you have written. All of that is checkable with the tools above, which is the reason to state it that specifically.

That is not a creativity problem. It is a scheduling mismatch: the arrival and the use happen at different times, and if you do not bridge the gap, every session starts from zero while your best material evaporates in the queue at the supermarket.

What actually needs catching

Not "ideas", which is too vague to act on. Four specific things, and they behave differently.

The angle. Not a topic — a take. "Habit trackers are the worst-suited category to being their own app" is an angle. "Habit trackers" is a topic, and topics are worthless because you already have infinite topics.

The first line. Sometimes an opening arrives fully formed. Write it exactly as it came, because you will not reproduce the rhythm later, and a good first line is often the whole piece in compressed form.

The observation. The specific thing you noticed. A detail, an overheard sentence, an odd fact, a moment. These are the raw material that makes writing concrete rather than general, and they are the fastest to fade because they were never verbal to begin with.

The connection. "This is the same argument as that." Connections between things you already know are where most original writing comes from, and they arrive unannounced and leave immediately.

Notice what is not on the list: research, links, quotes from other people. Those are collectable at any time, which is why people collect them — it feels like preparation and it is the part that is never the bottleneck.

Capture in the form it arrived

The most common mistake is tidying at capture time.

Someone has a rough, alive, slightly incoherent thought and writes down a neat summary of it. The summary is accurate and dead. Six months later it reads as a topic, and the thing that made it interesting — the specific irritation, the odd angle, the exact phrasing — is gone.

Write it messy. Write the sentence as it occurred to you, including the swearing, the incomplete clause, the "something about how...". The mess is the information. It is what will let you recognise, later, why you cared.

The corollary: capture has to be fast enough to allow mess. Anything that requires choosing a category, a tag or a location will produce tidied output, because you will compose while you file. The four-second window applies here more than anywhere.

One bank, not a filing system

The temptation is to organise ideas by theme, project or type. Resist it, for a specific reason.

Ideas are not useful in the category you assigned them. They are useful when they collide with something else, which is a thing that only happens if they are in one place where you read past the ones you were looking for. A well-organised idea file returns exactly what you searched for and nothing else, which is the opposite of what you want from it.

So: one place. Either one note per idea in a flat collection, or one long note per month that you append to. Both work. The one that does not work is eleven notes by theme, because assigning a theme is a decision at capture time.

Add a date and, if you can, one word about where you were or what prompted it. That context is often what makes the idea legible again later.

Reading it back is the practice

Capturing is easy. Rereading is the part that makes the bank worth having, and almost nobody does it.

Once a month, read the whole thing. Not to find something — to reload it. Ideas that have been read recently are the ones that surface while you are writing about something else. An unread bank is a graveyard, however good the contents.

Expect most of it to be bad. Genuinely. Two thirds of anything captured in the moment turns out to be nothing, and that ratio is fine and normal. The bank works on volume; the price of catching the good one is holding the mediocre ones.

Notice repeats. The thing you have written down four times in different words is trying to tell you something. Repetition across months is the single strongest signal a bank produces, and it is invisible unless you reread.

Delete freely. The same eviction discipline that keeps a someday list readable. If it has been there two years and produces nothing on reading, it goes.

The gap between an idea and a draft

The step nobody talks about, and it is where most banks stall.

An idea is one line. A draft needs a shape. In between there is a small, specific piece of work: taking the line and writing three or four sentences about why it matters and what the argument actually is.

Do that when you first reread it, not when you sit down to write. It takes five minutes, it is much easier than starting a draft, and it converts an idea into something you can pick up on a low-energy day. A bank of one-liners requires inspiration to use. A bank of four-sentence sketches does not, and the difference in how often you actually write is substantial.

The honest version

A large idea bank is not evidence of anything. Plenty of people have four hundred captured ideas and no finished work, and the capturing became the hobby — which is the same failure as building the system instead of using it, applied to writing.

The bank is worth exactly as much as the rereading. If you are not going to reread it monthly, capture less and write more.

Cyanote suits the messy-and-flat approach: ⌘N for a new note, ⇧⌘D for today's daily note if you would rather append than create, and no requirement to file anything anywhere. ⇧⌘F searches the body of every note you have ever written, [[ links an idea to the piece it eventually became, and notes nest into sub-pages when a sketch grows into something. It is one local database on your own Mac — which for half-formed thoughts you would not want anyone to read is a reasonable place for them to sit.

There is one property they share that is worth stating plainly before you decide how you feel about it: almost all of them work by sending your notes to somebody else's computer.

That is not a scandal and it is not hidden. It is how the technology works at the quality people expect. But it inverts the arrangement for anyone who chose a notes app for privacy reasons, and it is worth understanding at the level of what actually leaves.

What each feature transmits

The features are sold as one category and they have very different footprints.

Summarise this note. Sends that note. Bounded, and the easiest to reason about — you know exactly what went.

Rewrite or continue this paragraph. Sends the surrounding text. Also bounded, usually small.

Semantic search across everything. Sends all of it, at least once. To search by meaning rather than by word, every note has to be turned into embeddings, and unless that happens on your machine, every note is transmitted. This is the feature people most underestimate, because it feels like search — a local-seeming operation — and it is the one with the largest footprint.

"Ask your notes anything." Sends whichever notes the system judges relevant to your question, on every question. Over months that converges on most of your collection, in fragments, with no record of which fragments went where.

Automatic tagging, linking or organising. Reads everything, on a schedule, whether or not you are using the app.

If you are weighing this, that ordering is the useful one. The first two are a transaction you initiate. The last three are standing arrangements.

The questions to ask

Vendors vary enormously and several are genuinely careful. These are the questions that distinguish them.

Is my content used for training? Most business-focused vendors now say no by default. Check whether that is the default or an opt-out, and whether it differs by plan — free tiers sometimes have different terms.

How long is it retained? Many providers keep API inputs for a period for abuse monitoring, commonly around 30 days. That is reasonable operationally and it means your notes exist on their infrastructure after the request.

Who is the third party? Most apps do not run their own models. Your notes are going to the app vendor and to whichever model provider they use, which is two organisations and two sets of terms.

Is it opt-in per action, or always on? A button you press is a decision. Background indexing is a policy.

Can it be turned off completely? Not "disabled in the UI" — actually not running. Worth checking, because some indexing runs regardless of whether you use the features.

What can genuinely run locally

This is improving and it is worth knowing what is realistic in 2026.

Local embeddings for semantic search: yes, realistically. Embedding models are small enough to run on any modern Mac, and the quality is good. This is the local AI feature that most makes sense, because it is the one with the worst privacy profile when remote.

Local summarisation and rewriting: yes, with caveats. Small models run on Apple Silicon and produce useful output. They are noticeably worse than the frontier hosted models, and they cost several gigabytes of download plus real memory while running. Whether that trade is good depends on how much better you need the output to be.

Local "ask your notes anything": partially. The retrieval part runs locally. The answering part is where local models are weakest, and it is the part people judge the feature on.

The honest summary: local AI is genuinely viable in 2026 and it is not as good. Anyone claiming the gap has closed is selling something, and anyone claiming local models are useless has not tried recently.

The thing nobody mentions about app size

A local model is a few gigabytes. That is a large change to what installing a notes app means — an app that was 15 MB becomes a multi-gigabyte download, holds significant memory while running, and has real implications on an older machine.

Which is why most apps that offer local AI make it an optional download, and why apps that value being small often decline the feature entirely. It is a real architectural fork, not a checkbox.

Where this leaves a local-first app

Being straight about the position, since this is the part where a page like this usually gets evasive.

An app with no server has three options. Call somebody else's API, which contradicts the reason people chose it. Ship a local model, which multiplies the download size and gives worse results. Or not have AI features, and be worse at some genuinely useful things than the competition.

There is no fourth option, and anyone telling you their local-first app has frontier-quality AI with nothing leaving the machine is describing something that does not exist.

What a local app does have, and it is worth weighing: very good conventional search. Ranked full-text search across everything answers a large share of what people use AI search for, instantly, with no model, no transmission and no wait. It fails on the questions where you cannot remember any word from the note — which is exactly where semantic search shines, and that is the honest boundary between them.

How to decide

If the material is ordinary — work notes, projects, drafts, things you would not mind a colleague reading — hosted AI features are a reasonable trade and the productivity is real. Check the training and retention terms, and get on with it.

If some of it is sensitive — client work under NDA, health, legal, a journal, anything covered by a policy — the useful move is not to refuse AI entirely. It is to keep the sensitive material somewhere without it, and use AI-equipped tools for the rest. Two places with a clear line beats one place with a policy you hope holds.

If you cannot tell what is going where, that is itself the answer. A feature you cannot characterise is one you cannot consent to, and vagueness at this specific point is worth reacting to — the same standard as any other claim about what an app transmits.

The honest version

AI features in notes apps are useful and I am not going to pretend otherwise. Summarising a long meeting note, finding something by meaning, turning fragments into prose — these save real time.

The cost is a copy of your writing on infrastructure you do not control, and whether that matters depends entirely on what you write. For most notes it does not. For some notes it very much does, and the mistake is having one policy for both.

Cyanote has no AI features at all. Nothing is summarised, nothing is embedded, nothing is sent — the app makes three network requests in total and none carries a word you have written. What it has instead is ranked full-text search across every note, code block and table, running against a local database, returning results while you are still typing. That is a real trade rather than a superior position: if what you want is to ask your notes a question in plain language, this app does not do that, and one that does will serve you better.

You can remember the last six weeks in detail and the eight months before that as a haze with two or three landmarks in it. So you write about the last six weeks, plus whatever you can reconstruct, and the thing you are most proud of — the messy problem in March that you quietly fixed and nobody noticed — does not make the list, because you cannot recall it clearly enough to describe.

This happens to everyone every year, and the fix is about ninety seconds a week.

Why memory fails at exactly this

Not because your memory is bad. Because of what work looks like from inside.

The hard parts are invisible in hindsight. The thing that took three weeks of careful, frustrating effort gets compressed into "we shipped the migration" — a phrase with no evidence of difficulty in it. The version in your head is the outcome. The version worth writing about was the process.

Prevented problems leave no trace. The outage that did not happen, the bad decision you talked someone out of, the design flaw caught in review. These are frequently the highest-value things anyone does and they are literally unobservable — there is no artefact, no ticket, no launch. If you did not write it down, it did not happen.

Recency crowds everything else out. Whatever you did in the last month feels representative of the year, and it never is.

Other people's memory is worse than yours. Your manager has their own year to remember, plus five other people's. Assuming your contributions are visible to them by default is the most common and most expensive mistake in this whole area.

The two lines

Friday, or whenever the week ends for you. Two lines:

What I did. Not tasks — outcomes and the thing that made them hard. "Fixed the export timeout — the cause was the N+1 in the serialiser, not the DB, which took two days to find."

What that changed. For whom, and by how much if you can say. "Support had four tickets a week about this; it is now zero."

Ninety seconds. That is the entire practice.

The reason two lines beat a proper journal is that a proper journal does not get written. The bar has to be low enough to clear on the Friday when you are tired and want to leave, because those are the weeks it matters most — the hard weeks are where the good material is.

What to write that people leave out

Numbers, whenever one exists. Not because managers are impressed by metrics, but because a number is unforgettable and a claim is not. "Reduced the build from 14 minutes to 3" survives a year of hindsight. "Improved build times" does not survive the week.

The thing that made it hard. This is the difference between a work log and a task list. Anyone can list what shipped. Only you know that it needed three approaches, or a subtle bug, or a conversation with a team that did not want to have it.

Praise, verbatim, with the date. When someone says something appreciative in a message or a meeting, paste it in with the date and who said it. This feels awkward and it is the single highest-value thing in the whole log at review time, because it is evidence rather than self-assessment.

Things you were asked to do that were not your job. The scope you absorbed. This is how work quietly expands without recognition, and the log is the only record that it happened.

What you learned. Half for the review, half for you. A year of these is a surprisingly good picture of your own trajectory, and it is what you draw on when someone asks where you want to go next.

What went badly, and what you did about it. Not self-flagellation — the recovery. Reviews go better when you bring a failure with a lesson attached than when you appear to have had a perfect year, which nobody believes.

Reading it back

Three moments where the log earns its keep.

Before a one-to-one. Skim the last fortnight. Two minutes, and it turns "how's it going" into a specific conversation about specific things, which is what a 1:1 is supposed to be.

Before a review. This is the payoff. Instead of staring at a form trying to remember March, you read fifty entries and select. The work is choosing what to include, which is a much better problem than the one you had before.

Before an interview. A year of concrete examples with the difficulty preserved is exactly what behavioural questions ask for, and it is the reason people who keep logs interview better. They are not more accomplished; they can just remember what they did.

Where it goes

In your own notes, on your own machine, and this is not an incidental detail.

A work log kept in a company wiki or a work-issued account is a work log you lose access to the day you leave — which is precisely the day you need it most, for a CV, an interview, or a case for what you are worth. The same applies to anything in a Slack DM to yourself: it goes when the account goes.

It should also be somewhere private. An honest work log contains things you would not put in a shared document: what was frustrating, who was difficult, what you were unsure about. If it is somewhere your manager could read it, you will write a sanitised version, and the sanitised version is worth much less.

One note, growing downward, in a searchable collection you own. That is it — the same shape as a client note and for the same reason.

The honest version

This does not make you better at your job. It makes you able to describe your job, which is a different skill, and one that determines outcomes at exactly the moments that matter — promotions, reviews, interviews, and the conversation about whether you are underpaid.

The unfairness worth naming: people who keep logs do better at reviews than people who do not, at equal quality of work. That is a bad property of review processes rather than a good property of note-taking. Given that it is true, though, ninety seconds a week is a very cheap response.

Cyanote is a reasonable place for it because the log stays yours: one SQLite database on your own Mac, no account, nothing on a company server. ⇧⌘D opens today's daily note if you would rather log as you go, full-text search finds "that thing about the migration" a year later, and any note can be locked with a password. There is a weekly review template in the / menu if you want the log to hang off something you already do, which is usually how habits survive.

Two weeks later you need to know what was agreed about the deadline. There is a 6,000-word transcript and a summary with six bullets, none of which is the thing you need, and searching the transcript returns eleven mentions of "deadline" in fragments of sentences with no way to tell which one was the decision.

The technology worked exactly as advertised. Capture is solved. It turns out capture was not the problem.

What notes were for

Taking notes was never primarily about recording what was said. It did three things, and only the first is what a recorder replaces.

It kept a record. Genuinely replaced, and improved on — a transcript is more complete and more accurate than anything a human types.

It forced attention. You cannot take notes without deciding, continuously, what matters. That decision is the work, and it is why people who take notes remember meetings better even when they never reread them. A recorder removes the decision, which is the point and also the cost.

It produced an artefact you could use. Six lines you can read in twenty seconds before the next meeting. A transcript is not that. It is a source document, and reading it costs about as long as the meeting did.

The gap is between record and artefact, and no amount of transcription quality closes it. A better transcript is a better source document.

What the summaries do and do not do

Automatic summaries are genuinely useful, and it is worth being precise about the boundary.

Good at: who was there, what topics came up, the rough shape of the discussion, and a list of anything explicitly stated as an action.

Unreliable at: what was actually decided as opposed to discussed, what was agreed implicitly, who is really doing something when nobody said "I will", the difference between a firm commitment and someone thinking aloud, and — most importantly — the thing that mattered to you, which was probably one sentence somebody said in passing.

That last one is the fundamental issue. A summary is a general-purpose compression of the meeting. What you needed was a specific extraction relative to your own concerns, and the model does not know what those are.

The three lines that make the recording useful

Keep the recording. It is a better record than you would produce. Then, within ten minutes of the meeting ending, write three lines.

What was decided. In your words, plainly. "We are moving the launch to the 12th."

What I owe, and to whom, by when. Yours specifically. It becomes a dated task straight away — one sentence with the date in it — because an owed thing that lives only in a summary is not tracked.

What I need to remember that the summary will not contain. The tone. The fact that someone was clearly unhappy. The thing said just before the call ended. The reason behind a decision, which never survives into a bullet list.

Ninety seconds. That produces the artefact, and now the transcript is a genuinely useful thing to have behind it — you have a short document with the meaning in it, and a long document you can search when you need the exact words.

Attention, and what it costs to stop paying it

The uncomfortable part.

Meetings where everyone knows it is being recorded are measurably less attentive meetings. People check messages, half-listen, and rely on the summary. And the summary does a reasonable job of the content, which means nothing appears to be lost — except the thinking that used to happen during the meeting because people were engaged with it.

That is a real cost and it is invisible in the artefacts. The meeting produced a good transcript and a worse outcome.

The version that works is deliberate: the recorder handles the record, and you use the attention it freed up on the discussion rather than on your messages. That is a decision to make on purpose, because the default is not that.

Consent and where the recording lives

Two things worth thinking about once rather than never.

Recording people has legal and social requirements. Rules on consent vary by jurisdiction, sometimes significantly, and this is genuinely worth checking for the places you work rather than assuming the tool has handled it. Socially, a bot joining unannounced changes what people say, which is a cost to the meeting whether or not it is lawful.

A transcript is one of the most sensitive documents an organisation produces. It is a verbatim record of what people said, including the parts they would not have written down — offhand remarks, complaints, half-formed opinions about colleagues. It sits on the transcription vendor's infrastructure, and it is discoverable, breachable, and reviewable by whoever has admin access.

If it would matter for a conversation to be read back verbatim, that is a reason to take notes rather than record. The three-line artefact contains what was decided. The transcript contains what everyone said, which is a different and much larger liability.

Where each thing belongs

Transcripts stay in the meeting tool. They are bulky, they are the organisation's record, and they belong where they were produced.

Your three lines go in your own notes. In the same collection as everything else you write, so a decision from March turns up when you search for the project. They leave with you, they contain no verbatim record of anyone else, and they are short enough to actually reread.

This split is the same one that applies to work notes generally: shared records go in the shared system, your own understanding goes somewhere that is yours.

The honest version

If you run a lot of meetings, use a transcription tool. Do not stop — the record is genuinely better than what you would write, the search is useful, and being able to check what someone actually said has settled more disagreements than any minutes.

Just do not mistake it for notes. It is a recording. The notes are the ninety seconds afterwards where you decide what it meant, and that step has not been automated because it is not a summarisation problem. It is a what mattered to me problem, and nothing else knows the answer.

Cyanote has no transcription and no AI summarisation — it is the place the three lines go. Meeting and standup templates in the / menu, tasks that take an owner and a date out of a typed sentence, [[ links so a decision attaches to the project and the person, and full-text search across every meeting note you have written. It is a local database on your own Mac, which is a reasonable place for the short document containing what things meant, whatever your organisation does with the long one.

You have not opened it in eleven months, and when you do it produces a specific unpleasant feeling — a wall of intentions you have not acted on, arranged as evidence. So you close it. And because you closed it, the next genuinely good idea also goes in and is also never seen, which means the list has stopped being a system and become a place where ideas go to be filed away from you.

The mechanism it was supposed to provide is real. It just needs one thing nobody does.

What the list is actually for

Two jobs, both legitimate.

Getting it out of your head. An unrecorded intention costs you background attention indefinitely — it keeps surfacing, because part of you does not trust that it will be remembered. Writing it down genuinely stops that, and that alone justifies the list even if nothing on it is ever done.

Being there when the conditions change. You have three free weeks, or a budget, or you finally moved house. The list is where you look, and the value is that six months ago you knew something about what you wanted that you have since forgotten.

Note what is not on that list of jobs: making you do things. A someday list is not a to-do list with a longer horizon. It is a holding pen, and the moment you treat it as commitments you have created a debt you cannot service.

Why it becomes a graveyard

Nothing is ever removed. Items only go in. After two years there are 200, and no list of 200 things is readable — you scan the first twelve and close it.

It mixes categories. "Learn Portuguese", "buy a lamp" and "write a novel" require completely different amounts of life, and interleaving them makes the whole list feel equally unachievable.

Every item is a small reproach. Because it is written as a commitment — "learn Portuguese" — rather than as a note about a desire. The wording turns a preference into an unpaid obligation, 200 times.

There is no moment where it gets looked at. So it is only ever read accidentally, which is always the wrong emotional moment for a list like this.

The fix: deletion is the feature

The list needs an eviction rule, and it has to be a rule rather than a judgement, because judged item by item nothing is ever deletable.

Every item gets a date when it was added. Almost free, and it is the whole mechanism, because age is the signal.

At review, anything over a year old gets one question: would I start this in the next three months? Not "do I still like the idea" — every idea on the list is a nice idea, that is why it is there. Would you start it. If no, delete it.

Deleting does not mean you have given up. This is the part that makes it psychologically possible. If the desire is real, it will come back — that is what a real desire does. If it never comes back, it was a passing interest, and passing interests are not failures. They are how people find out what they like.

A list that shrinks is a list you will keep reading. That is the entire trade.

Sorting by size, not by theme

Categories that work, because they map to what has to be true for you to start:

An afternoon. Fix the cupboard, cancel the thing, get the frame made. These do not belong on a someday list at all — they belong on your actual to-do list with a date on them, and moving them off is usually a third of the list gone in one pass.

A weekend. Small projects. These are the ones the list is genuinely for, because they need a free weekend to coincide with the inclination, and that coincidence is exactly what a list catches.

A season. Learn the thing, write the thing. You can run one of these at a time and not more. If four are marked active, none are.

A different life. Move country, change career, buy the boat. These are worth keeping and they are not projects. They are preferences, and reading them once a year is genuinely informative about where you are heading.

The last category is the one to keep in a note rather than a task list. Written as prose — "I keep coming back to wanting to live somewhere with fewer people in it" — it stops being an unpaid obligation and becomes what it actually is: a thing you know about yourself.

The review that makes it work

Once a quarter. Twenty minutes. Not more often — nothing changes in a month, and a list reviewed monthly becomes a monthly reminder of what you have not done.

Delete by the rule first, before reading properly. Get the list down to something readable, and do it mechanically so you are not negotiating with each item.

Move afternoon-sized things to the actual to-do list, with dates.

Pick one. One thing that becomes real this quarter, with a first step that is a dated task. One, because two is none.

Read the rest without deciding anything. That is the part that does the work you cannot force — it puts the ideas back in circulation, and one of them will surface next month while you are doing something else.

Attaching this to something you already do is what makes it happen at all. A quarterly review that hangs off a weekly review you actually keep survives; one that requires remembering a new ritual does not.

The honest version

The uncomfortable truth is that you will do maybe five percent of what goes on that list, and a bigger list does not raise the number. Capacity is the constraint, not memory.

Which means the list's real job is not storage. It is being small enough to read, so the ideas are actually in circulation rather than filed away from you. Every deletion makes the remaining items more likely to happen, and that is a genuinely counterintuitive property worth internalising.

Cyanote holds both halves in one place: the afternoon and weekend items as tasks with dates lifted out of the sentence you typed, and the seasons and the different-life material as notes, in prose, where they read as things you know about yourself rather than as debts. A board view gives the quarterly sort a shape, and full-text search finds the idea you had in 2024 and half-remember. It is one local database on your own Mac — which for a list of everything you privately want is not an incidental detail.

Which means the question of where it lives is not primarily a security question. It is a writing question — because if some part of you suspects the words could be read, you will write a slightly managed version of what you think, and the managed version is worthless. It is the same as the unmanaged one with the useful part removed.

People often discover this the wrong way round: they journal in a shared workspace for a month, produce nothing but bland entries, and conclude they are not a journalling sort of person.

The three things that make you self-censor

A shared or work account. Anything administered by an employer. Whether or not anyone would look, you know that someone could, and knowing is enough.

A device other people use. A family iPad, a laptop left open, a machine with a session that does not lock. The risk is not a breach; it is somebody walking past.

A service that reads your content. Anything doing automatic summarising, tagging or semantic indexing has, by construction, transmitted what you wrote. That is a real property of those features, not a suspicion, and it is worth knowing which side of it your app is on before you write down something you have told nobody.

The fix for all three is the same and it is architectural rather than behavioural: put the journal somewhere that has no route out.

What a private-by-construction arrangement looks like

A local file, on a machine you control. No account to breach, no server holding a copy, no support person with database access. The threat model becomes: someone with your unlocked laptop. Which is a threat you can actually reason about.

Encrypted where it sits. Full-disk encryption at minimum. Per-note locking on top, if the app offers it, so a shoulder does not read it and neither does anyone who gets past the disk.

No AI, or AI that provably runs locally. Not because the feature is bad, but because "summarise my journal" and "nothing leaves the machine" are mutually exclusive unless the model is on your disk.

An export you control. Journals are the notes people most want to still have in twenty years. That means a readable format and a backup, which is the one place this gets complicated — see below.

The one that actually needs thinking about: backups

Here is the tension nobody resolves cleanly.

A journal is the single hardest thing to lose and the single worst thing to have copied. Those pull in opposite directions, and most advice picks one and pretends the other does not exist.

The arrangement that handles both: an encrypted backup you control the key to. An external drive, encrypted, kept somewhere else. Or an encrypted archive of the export, in cloud storage — the storage provider holds a blob they cannot read, which is a genuinely different arrangement from them holding your text.

What does not work: putting the journal in a sync service for safety. That is a copy on someone else's infrastructure in readable form, and it undoes the entire arrangement in exchange for convenience.

If that sounds like too much, the honest minimum is: full-disk encryption on, one encrypted copy on an external drive, updated occasionally. That covers the fire and the theft, which are the realistic losses.

What actually goes in one

Since the question of what to write stops most people faster than where to put it.

No obligation to write daily. The daily streak is the most common reason people abandon journals, because a missed day becomes a small failure and three missed days become a stopped habit. Write when there is something.

The uncomfortable version. If the entry could be shown to a colleague without difficulty, it is probably not doing the job. The value is in what you are not saying out loud.

What you are actually worried about, not the tidy version. The tidy version is the one you have already told people, and you did not need to write it down.

Occasionally, what happened. Plain events with dates. Not for the writing — for the reading. In five years the emotional entries will be strange to you and the factual ones will be the ones you are glad exist.

Reading it back

The part that makes it worth having done, and the part almost nobody does.

Once or twice a year, read a year old. Two things happen reliably. Things you were certain about turn out to have been wrong, in ways that are useful and slightly humbling — the same mechanism as a decision journal, applied to your life rather than your choices. And things that felt enormous turn out to have been survivable, which is the most useful information a journal ever provides, and it is only available in your own handwriting about your own crisis.

Expect to find some of it embarrassing. That is what an honest record looks like, and the entries that are not embarrassing are usually the performed ones.

Paper, briefly

Worth mentioning honestly: paper is genuinely private, needs no threat model, and cannot be indexed by anything.

It also cannot be searched, is difficult to back up, and is readable by anyone who opens the drawer — which for a lot of living situations is a worse privacy property than an encrypted file, not a better one.

The reasonable answer is: paper if you like writing by hand and nobody goes in your drawer; an encrypted local file if you want to search it in ten years. Both are defensible. What is not defensible is a journal in a work account.

The honest version

If you have tried journalling and produced nothing but bland entries, the diagnosis is usually not discipline. It is that some part of you did not believe the document was private, and that belief is not something you can override by deciding to be honest.

Fix the arrangement first. The writing tends to follow.

Cyanote is private by construction rather than by policy: one SQLite database on your own Mac, no account, no sync, no analytics, no crash reporter, no AI reading anything. Any note can be locked with a password and is encrypted where it sits, so the journal can be locked while the shopping list is not. ⇧⌘D opens today's daily note when you do want a dated habit, and everything exports to one readable file — which, encrypted and kept on a drive somewhere else, is the version of a backup this particular material deserves.

Most people who try one stop within a month, and the reason is not that the features do not work. It is that being reminded your friendship with someone is 14 days overdue makes you feel like a bad person operating a pipeline, and that feeling is stronger than the mild benefit of the reminder.

There is a useful thing underneath, though, and it survives without any of that.

The two real problems

You forget what people told you. Their sister's name, the job they were nervous about, the thing they said they were struggling with, the fact that they were moving in the spring. Then you see them in four months and cannot ask about any of it, which makes the conversation start from nothing.

Time is a liar. The friend you have not spoken to since "a couple of months ago" is at fourteen months. Not deliberately — there is simply no signal, and without a signal, elapsed time is invisible.

Those are memory and measurement problems, and both are fixed by writing things down. Neither requires scoring anybody.

One note per person

The whole system, and it is the same shape as a client note with a completely different tone.

At the top, the things that are permanent: partner and children's names, where they live, what they do, how you know each other, birthday if you mark it. The details you feel awkward asking for a second time.

Below, dated entries after you speak. Two or three lines. What is going on with them, what they were worried about, what they were looking forward to, what you said you would do.

That is it. Written within ten minutes of the conversation, which is the only moment it will get written.

Why the note beats the reminder

Because it changes what happens at the beginning of the next conversation.

Three minutes before you call, read the last entry. Now you can open with "how did the thing with your brother work out" instead of "how are you", and that difference is the entire point — it says you were listening and you remembered, which is most of what people mean by feeling cared about.

A reminder gets you to call. The note makes the call good. The second is worth considerably more, and it is the half the apps in this category do worst, because they are built around cadence rather than content.

The one rule about time

Not a cadence, not a score. One question, at whatever interval you already review things.

Who have I been meaning to contact and have not?

Read the list of people. Some names produce a small pull — you have been meaning to, you would like to, it has been a while. That pull is the signal, and it is far better information than any elapsed-time counter, because it already accounts for the fact that some friendships are fine at once a year and some feel neglected at once a month.

Pick one or two. Message them. That is the whole practice.

The reason this beats a computed cadence: a system telling you that a close friend is overdue and a person you met once is due creates the same alert for two completely different things, and the flattening is what makes the whole idea feel wrong.

What not to record

The line matters here more than anywhere else in note-taking, and it is worth deciding once.

Nothing you would be ashamed for them to read. That is the whole test and it is a good one. "Interested in Portuguese, nervous about the move" is a note made by someone paying attention. Anything analytical about their character, or strategic about what they are useful for, is a note made by someone doing something else.

Nothing that is theirs to hold. Health information, a confidence, someone else's marriage. If they told you in confidence, holding it in a searchable file is a different act from remembering it, and it is worth being deliberate about which you are doing.

Nothing that would be embarrassing in aggregate. A single note is innocuous. A file with a detailed history of forty people's lives has a different character, and it is worth noticing that before you build one.

The practical rule: write what helps you be a better friend, and nothing that helps you be a better operator.

Where it should live

On your own machine, in your own notes, and this one is not a preference.

This is a file about other people, who did not consent to being in a database. It should not be on a service that could be breached, sold, acquired, or mined for a graph of who knows whom. A local file with no account is the arrangement that matches what the material actually is — and it is checkable rather than promised.

The birthdays go in the calendar as repeating events with a reminder a few days ahead, which is enough to do something about it. The people go in notes. Nothing needs a score.

The honest version

Some people will do the note after every conversation and it will genuinely improve their friendships. Most will do it for three weeks.

The version that survives, for almost everyone, is much smaller: write things down after the conversations that mattered, and once a month read the list of names and notice who you have been meaning to call. That is a fraction of the effort and most of the benefit.

If you actually need cadences and reminders — for professional networking, or if you are managing a genuinely large number of relationships for work — those apps exist and they are built for it. But that is a CRM, and calling a CRM personal does not change what it is.

Cyanote holds this the plain way: a note per person that grows, [[ links so someone's page collects the meetings and projects they appear in without you filing anything, birthdays as repeating calendar events with a reminder a day ahead, and full-text search so "who was it that knew about roofs" is one query. It is one SQLite database on your own Mac with no account, which for a file containing what your friends told you in confidence is the only arrangement that makes sense.

Notion is very good at a specific job: a shared, structured workspace where a page can also be a database, several people can be in it, and the whole thing is reachable from any browser on earth. Nothing local-first does that, and nothing will, because the properties are in direct opposition.

So the question is not which is better. It is whether you are using the part of Notion that costs you the things it costs you.

What Notion is genuinely good at

Worth listing before the criticism, because these are real and a local app has no answer to any of them.

Databases-as-pages. A table that is also a board that is also a calendar, with the same rows underneath, filtered and grouped per view. This is the actual product, and it has no equivalent in a notes app.

Several people in the same document. Comments, mentions, permissions, a shared source of truth for a team of nine. If your notes are how a group coordinates, this is the whole requirement.

Any device, no install. A browser is the client. Someone with a Chromebook and someone with an iPad are equally full participants.

Templates that are systems. Not a starting shape for a note — a whole tracker someone else designed, duplicated into your workspace in one click.

If two or more of those describe why you opened Notion this morning, the rest of this post is not for you, and switching would be a downgrade.

What it costs

Also real, also worth stating plainly.

It opens at the speed of your connection. Every page load is a request. On a good day this is fine. On a hotel network it is a spinner where your notes should be, and that delay is not neutral — it decides whether a passing thought gets written down.

Offline is a fallback, not a mode. There is offline support, and it is genuinely better than it was. It is still a cache of a workspace whose truth lives elsewhere, which means the honest version of the wifi-off test will show you edges: pages you have not opened, search that behaves differently, attachments that were URLs.

Your writing is on somebody's servers, tied to an account. For a team workspace this is the point and not a complaint. For a private journal, client notes under NDA, or anything you would rather not have restored to a future device, it is a decision you should have made deliberately.

Structure grows whether or not you asked it to. Databases invite properties. Properties invite filling them in. A capture that started as "write down the thing" becomes a small form with a status field, and the tax lands at exactly the moment that has to stay cheap.

Getting out is work. Export exists — Markdown, HTML, CSV — and it produces something real. What it does not produce is your workspace: the database views, the relations between tables, the rollups. The prose comes out. The structure, which is what you spent the time building, largely does not.

The question that decides it

Not "is Notion good" — it is. The question is: are you the workspace, or are you a person with notes?

A lot of individual Notion users are running a single-player instance of a multiplayer product. They have one workspace, no collaborators, four databases they built in an enthusiastic weekend, and a daily usage pattern that is: open a page, write a paragraph, close it. That usage is served identically by anything with a text editor, and it is paying the full price of the architecture — the load time, the account, the connection — for features nobody in the workspace is using.

If you have collaborators, or genuinely rely on the database views, stay. If you are one person writing paragraphs, you are paying for a team product with no team.

What a local app can actually replace

Being specific, because vagueness here is how people end up disappointed.

Replaceable straightforwardly: pages of prose, nested sub-pages, the block editor with headings and lists and callouts and toggles, code blocks, tables inside a document, linking pages to each other and seeing what links back, templates as starting shapes, tasks and a board view of those tasks.

Not replaceable: a database with multiple synced views, relations and rollups between databases, formula properties, sharing a page with a colleague, comments and mentions, access from a browser you do not control, the template gallery ecosystem.

If your Notion is mostly the first list, the switch is a straight upgrade in speed and ownership. If it is genuinely the second, no local app is the answer and I would not sell you one.

How to test it in an afternoon

Do not migrate. Test.

Open your workspace and count the databases you have touched this month. Not built — touched. If the answer is zero or one, the structure is decoration.

Look at your last twenty edits. Were they prose in a page, or property values in a table? That ratio is your answer.

Export the workspace now, whatever you decide. Markdown and CSV, into a folder. Do it today. It costs ten minutes and it means the decision stays yours later, which is the whole point of an export you have actually run rather than one you assume works.

Then, if you are leaving: take the last six months and the pages you actually reference. Leave the rest in Notion, which is not going anywhere on the free tier. Wholesale migration is how people spend a weekend and end up with two half-populated workspaces.

The honest version

Notion at its free tier costs nothing for one person, and "free and good" is a strong position. What it is not is fast, private, or yours — and for a single person writing paragraphs, those three are worth more than a database engine they are not using.

Cyanote covers the first list above and none of the second. A block editor with headings, lists, quotes, tables, tick boxes, images, callouts, toggles and syntax-highlighted code, reachable from a / menu; notes that nest into sub-pages; [[ links with backlinks; templates; tasks in a list or on a board. All of it in one SQLite database on your own Mac, with no account and no server — which is why it opens in under a second and does the same thing with the wifi off. There is no collaboration, no browser access, and no phone app. Those are not oversights; they are the other side of the same coin.

Code does not work like that. A command is right or it is not, and "roughly right" is the failure mode that costs you an hour, because it looks correct and does something else.

These are two different postures. Most of us hold both in the same working day, often within the same task, and the moving between them is where the day quietly leaks.

The switch is not the two seconds it looks like

Say you are writing up a process and you need the exact command. You switch to the editor to get it.

The two seconds are not the cost. The cost is that the editor is full of other things — a file you had open, a diff you had not finished reading, an error in the terminal below it. You went in with one narrow errand and arrived somewhere with its own agenda. Twenty minutes later you are doing something legitimate and it is not what you were doing.

The other half of the cost runs the opposite way, and it is subtler. Because getting the snippet is annoying, you do not get it. You write "run the usual deploy command" and move on. The document survives; the useful part of it does not. Then the version of you who reads it in March has to reconstruct what "usual" meant.

Why the mode shows up in the typing itself

The two modes are not just a state of mind — they disagree about what should happen when you press a key.

In prose mode you want the software helping. Straight quotes becoming curly ones, a list continuing itself, a heading formatting as you type. This is invisible and correct, and you would miss it immediately if it stopped.

In code mode every one of those is sabotage. The curly quote breaks the command. The list continuation mangles the indentation. A "helpful" capital at the start of a line changes what a case-sensitive flag means. Exactness needs an editor that does nothing you did not type.

This is why the two live in different applications for most people — not because anyone chose that, but because one text box cannot do both. If you want the underlying argument for why one app can hold both anyway, that is a separate piece. What follows assumes you have somewhere for both and is about how to arrange them.

Keep the artefact next to its explanation

The single most useful arrangement is also the least clever: whatever you write about the thing should sit next to the thing itself.

A runbook is a prose note. Each command it depends on is its own code note, linked from the runbook with [[. The runbook explains and links; the code note is the exact text and nothing else. Because the link shows up from both ends, the snippet knows which document it belongs to — so when you find it in six months, it comes with its reason attached.

That solves the failure mode where the explanation and the artefact drift apart. They can still drift, but the moment you notice, they are one click from each other rather than two apps apart.

Practically, in Cyanote, that is ⌘N for the prose note and ⇧⌘N for the code note, [[ to link them, and ⌘S in a code note to save it back to a real file on disk if the text is also live configuration somewhere. ⌘K reaches any note by name and ⇧⌘F searches inside all of them at once, so the retrieval end does not depend on your having filed anything correctly.

Make the mode visible before you read a word

A small thing with a return out of proportion to the effort: set the code notes in monospace and leave the prose notes in whatever you write in. Typeface, size and line spacing are per-note settings, so this costs nothing after the first time.

The point is not aesthetics. It is that you can see which mode a note is in before you have read a word of it — and so you arrive already in the right posture instead of adjusting halfway down the page. The rest of what is worth setting is mostly about reading comfort; this one is about attention.

Batch the modes when you can

The cheapest switch is the one you do not make. Two habits do most of the work here.

Write first, verify second. Draft the whole document in prose mode, leaving a marker wherever an exact value goes. Then do one pass collecting every exact value at once. One switch instead of nine, and the writing keeps its momentum, because it was never interrupted to go and fetch a flag.

Capture snippets when you are already in code mode. The moment to save a command is the moment it finally works — not later, when you are writing the document, because by then you are in the wrong mode and you will paraphrase it instead. A working command and a sentence about what it does, saved at the moment of relief. That sentence takes eight seconds and is the entire difference between an archive and a junk drawer.

If you keep a lot of things this way, the clipboard is the other half of that story: the pinned snippet and the copy history catch things you have not decided to keep yet.

When you should absolutely switch apps

Do not take any of this as an argument for working in one window.

When you are actually building — running things, reading errors, moving between files, using git — go to a real editor and stay there. That is code mode at full depth and a notes app has no business in it. There is no debugger here, no terminal, nothing to run, and pretending otherwise would waste your afternoon.

The arrangement above is for the other thing: the writing that surrounds the work. Runbooks, decisions, how the thing is configured and why, the fragments you will need again in a context you cannot predict. That work is mostly prose with exact bits embedded in it, and it is the work that gets abandoned when the two halves live in different buildings.

The honest version

If your working day is entirely one mode, this is not a problem you have. A writer with no snippets and an engineer who never writes anything down are both well served by one good app and no thought about it at all.

The switching cost is worth attention when the two are genuinely interleaved — when the document you are writing is about a system, and half of what makes it useful is text that has to be exact.

Cyanote holds both kinds in one window, on one Mac, in one local database, for $10 once. It has no sync and no mobile app, so if the runbook needs to be readable from a phone at 3am, this is the wrong tool and you should know that before you pay rather than after.

Which makes it a strange category to put behind its own app icon, its own launch, its own moment of remembering it exists.

The mechanism is visibility, not features

Most habit-tracking apps compete on what happens around the checkmark — streak graphics, charts, badges, social accountability, reminders tuned by machine learning. Some of that helps some people. None of it is the mechanism.

The mechanism is: you open something, you see today's habits, you mark them or you don't. Everything else is decoration on top of a single daily glance. Which means the question that actually matters isn't "which app has the best streak visualisation" — it's "which app am I actually going to open every day without being asked."

Why a dedicated habit app struggles with its own job

This is the part that's a little unfair to habit apps, because it's not a quality problem. It's a category problem.

A habit tracker is, almost by definition, an app you don't need for anything else. You don't check it to write something down, look something up, or get something done — you check it to check it. That makes it the easiest app on your Mac to simply stop opening, because nothing else pulls you toward it. A notes app gets opened because you need to write a note. A habit tracker gets opened because you remembered to open the habit tracker, which is precisely the kind of remembering a habit tracker exists to replace.

The apps that work around this lean hard on notifications — a push reminder every evening, sometimes several. That's a real solution, and it's also the reason people delete habit-tracking apps: the badge count and the reminders become their own small source of guilt, decoupled from whatever the habit actually was.

What changes when it's not a separate app

Not a redesign of the mechanism — the same glance, the same checkmark. What changes is where that glance happens.

If your habits live in the same window as the notes you're already writing and the to-dos you're already checking, the habit tracker stops needing its own reason to be opened. You see today's habits because you were already there for something else, the same way a kitchen calendar gets glanced at while you're getting coffee rather than because you scheduled time to look at a calendar. The visibility the whole category depends on gets inherited from an app you were opening anyway, instead of manufactured by a notification.

This is the same argument I made about the weekly review fitting into twenty minutes rather than becoming its own ceremony — the systems that survive are usually the ones that attach to something you were already doing, not the ones that ask for a new standalone ritual. A habit tracker you have to remember to open is asking for a ritual. One sitting inside your daily notes is attaching to one you already have.

A dedicated habit app is a perfectly good answer

Worth saying plainly, because a page selling the bundled version has an obvious reason not to.

If you want serious analytics on your habits — correlation between habits, long-range charts, a gamified system that genuinely works for you — a dedicated tracker will do more than a habit list bolted onto a notes app ever will. As of 16 August 2026, Streaks is a one-time $5.99 purchase on the App Store and has been one of the more respected habit trackers on Apple platforms for years; Habitica turns the whole thing into an RPG with a free tier, for people who are honestly motivated by that. Both have spent years refining exactly this one thing, and if what's currently stopping you is that your habit tracker isn't good enough at being a habit tracker, switching to a plainer, less-featured one won't fix that.

The bundled version isn't trying to out-feature them. It's solving a different, more common failure: not "my habit tracker's charts aren't detailed enough" but "I stopped opening my habit tracker in February and didn't notice until April."

What actually breaks a habit-tracking streak

Worth naming, because it's rarely the habit itself.

Too many habits at once. A list of eleven things to check every day is a chore, not a habit tracker, and the eleventh item is the one that quietly stops getting checked first — followed, a few weeks later, by all of them.

No room for a miss. A single missed day that resets a 40-day streak to zero teaches exactly one lesson: stop looking at the app. The trackers that hold up long-term usually let a streak bend without breaking outright.

The tracker itself becoming the thing you avoid. If checking in has started to feel like a small guilt trip rather than a small win, the app has started working against its own mechanism.

None of these is fixed by more features. They're fixed by fewer habits, more forgiveness, and — the part this post is actually about — a lower cost to glancing at the thing in the first place.

The honest version of the choice

If you're deep into habit tracking as its own discipline — chains, correlations, a system you've tuned over years — a dedicated app that's spent that long on the one feature will serve you better than a habit list living inside a bigger app.

For the more ordinary case — a handful of habits you want to keep half an eye on without giving them their own icon, their own notifications, and their own moment of remembering to open it — the bundled version's whole argument is that it doesn't need a mechanism of its own. It borrows the one you already have, from the app you were opening anyway.

Cyanote's habit tracker sits in the same window as the notes and the to-dos, in a local database on your Mac, with no account and no streak data leaving your machine. It is one part of five, not the deepest habit tracker available — and if the depth is what you're after, Streaks or Habitica will out-feature it honestly.

The technique doesn't need an app

You could run a Pomodoro session with a kitchen timer, and for the first decade or so people mostly did. The method's entire value is the boundary — a fixed block where you've pre-committed to one task and a fixed break where you've pre-committed to stopping. Nothing about that requires software.

What software adds is the parts around the boundary: a sound when the block ends, a count of how many rounds you've done today, a way to see the streak. Useful, but worth naming as decoration on a method that works without any of it — the same relationship a habit tracker's charts have to the actual checkmark.

Where a separate timer app costs you something

The problem isn't that dedicated Pomodoro apps are bad at the timer. They're usually good at it. The problem is where they sit relative to the work.

You're writing, or coding, or working through a task list, and you switch to the timer app to start a session. Twenty-five minutes later it makes a sound, and you switch to it again to start the break, then switch back again to resume. None of those switches is expensive on its own. Multiplied by six or eight rounds a day, it's a small tax paid entirely in the currency the technique exists to protect — your attention, spent on the tool that's supposed to be protecting it.

There's a sharper version of this if the timer app has its own notifications, its own badge, its own reason to check in on you. At that point the tool meant to reduce context-switching has become a second source of it.

What changes when the timer is where the work is

The mechanism doesn't change — still 25 minutes, still a break, still the same countdown. What changes is that starting it doesn't cost an app switch, because it's a control inside the window you were already using to do the work. You start a round from your task list, keep working in the same place, and the timer runs alongside rather than requiring its own visit.

That matters more for the break than the work block. The moment a 25-minute timer ends is exactly the moment you're most likely to open something distracting "for a second" — and if the timer itself lives inside the app that also holds your to-do list, the natural next glance is at the list, not at whatever's one tab over in a browser. A five-minute break inside a focus tool tends to stay five minutes. A five-minute break that starts by opening a browser tab rarely does.

This is the same logic behind running a weekly review in twenty minutes rather than letting it sprawl — a bounded block only holds its boundary if the tool running it isn't itself an invitation to wander.

Routines are the same idea, run longer

A single Pomodoro round is a 25-minute boundary around one task. A routine is the same idea stretched across a morning, an evening, or a weekly reset — a fixed sequence of steps you run without re-deciding the order each time.

The value of both is identical: deciding the shape of the block once, in advance, so you're not negotiating with yourself in the moment about what comes next or how long it should take. A routine that lives next to your to-do list can pull directly from it — the same way a Pomodoro session started from your task list already knows what you're working on, a morning routine sitting next to your notes can open straight into the day's first task instead of ending in "okay, now what."

A dedicated Pomodoro app is a perfectly good answer

As with the rest of this app, worth saying plainly rather than around.

If you want serious analytics on your focus time — long-range charts of deep work, integrations with a calendar or a task manager you already use, a genuinely well-designed standalone experience — a dedicated timer will do more than a Pomodoro control tucked into a bigger app. As of 16 August 2026, Session is $4.99 a month or $39.99 a year and is built specifically around deep-work tracking; Be Focused is a one-time $4.99 on the Mac App Store and covers the core technique cleanly without a subscription; Forest gamifies the block by growing a virtual tree, with Forest Plus from $5.99 a month for the extras, though its Mac presence is a browser extension rather than a native app. Years of attention have gone into each of those, in a way a timer that's one feature among five isn't trying to match.

What the bundled version is solving is narrower: not "make the best possible Pomodoro app," but "don't make starting a 25-minute focus block cost an app switch in the first place."

What to check before you rely on either

If a timer's alerts are the thing that pulls you out of focus — a notification banner, a sound that cuts through headphones at the wrong volume — check what you can turn off before you commit to a method that depends on the boundary being quiet rather than loud.

Check whether the break is actually enforced or just suggested. A timer that lets you skip the break with one click is teaching you to skip the break.

And ask whether the routine or timer data needs an account to work. A 25-minute countdown has no reason to touch a server, and neither does a checklist of morning steps.

The honest version of the choice

If focus tracking is a discipline you're serious about — data across weeks, integration with a bigger deep-work practice — a dedicated app built entirely around that will outperform a timer that's one part of a larger tool.

For the far more common case — you want the boundary the Pomodoro Technique provides without paying an app-switch tax to get it, and a routine that doesn't require its own launch to run — the value is in the timer not needing a reason of its own to be open. It borrows the one your task list already gives you.

Cyanote's timer and routines sit in the same window as the notes, the to-dos and the calendar, running locally with no account and nothing sent anywhere. It's one part of five, and if deep-work analytics or a gamified tree is what actually keeps you consistent, Session, Be Focused or Forest will serve that specific need better than a bundled timer ever will.

So you go and get it. And on the way back, if you are honest, about a third of the time you do not come back.

That round trip is so normal that it reads as the cost of doing business. It is worth asking why it exists, because the answer is more interesting than "I never got organised".

You keep two kinds of text, and they want opposite things

The first kind is written to be read. Sentences, headings, a list of what you decided and why. It tolerates a typo. It benefits from being tidied up as you type — a straight quote turned into a curly one, a dash lengthened, a stray double space collapsed.

The second kind is written to be re-run. A command, a config block, a regex, a query, the four lines that fix the thing that breaks every March. It does not tolerate a typo, and the tidying that helps the first kind is actively destructive to the second. A smart quote in a shell command is not a nicer-looking quote. It is a syntax error that takes ten minutes to see, because it looks correct.

That is the whole reason for the split. It is not laziness or a failure to consolidate. Your prose editor is helpful, your snippets need an editor that refuses to help, and one text box cannot be both at once.

Why "just use a code block" is not quite the answer

Every serious notes app has code blocks now. Fence some text in backticks, get a monospace font and syntax colouring, done.

That solves the smallest part of the problem. A code block inside a prose document is still living in a prose document: it is a paragraph that happens to be wearing a different typeface. It has no file on disk, so nothing can run it and nothing else can read it. It cannot be opened on its own. When you copy it out, you are as likely to bring along an invisible character as not.

It is a fine way to show code inside an explanation. It is a poor way to keep code you intend to use.

What the split actually costs

Not much on any given occasion, which is exactly why it lasts for years.

The explanation and the artefact drift apart. The snippet is in one place, and the paragraph explaining what it is for is in another, and only one of them gets updated. Usually the snippet. Six months later you have a command that works and no memory of what it does to the database, which is a worse position than having neither.

Two search boxes, and neither one is complete. You half-remember something. Was it a thing you wrote down or a thing you saved? You look in both apps, in order, every time. The answer to that question should never have been load-bearing.

Snippets end up wherever was closest at the time. A Gist, a message to yourself, an untitled file called test2.sh, the desktop. None of these is a bad place on the day. Collectively they are not a system, and the only index is your memory.

What changes when both live in one app

The useful version of "one app" is not a prose editor with better code blocks. It is two editors, each honest about what it is for, in the same window and the same database.

A code note in Cyanote is its own kind of note. It opens in a code editor rather than the block editor — monospace, syntax highlighting, language detected from what you paste, and none of the typing help that turns a working command into a broken one. ⇧⌘N makes one; ⌘N makes an ordinary note.

Three things follow from that, and they are the actual argument.

A code note can be a file. ⌘S saves it straight back to a real path on disk. So the config you keep and the config the machine reads can be the same text rather than two copies that agree for a while. That is the difference between a note about your setup and your setup.

The prose can point at the code. [[ links one note to another, and the note being linked to shows what links back. The runbook links to the snippet. Open the snippet in six months and it tells you which runbook it belongs to. Neither one can quietly become an orphan.

One search box covers both. Full-text search across everything you have written, prose and code alike, so "did I write it down or save it" stops being a question you have to answer before you start looking.

None of this is exotic. It is what you would build if you accepted that the two kinds of text belong together and that they need different editors — which most apps do not, because they have picked a side.

Where a real editor still wins, and it is not close

This is the part a product page would skip, so let me be plain about it.

Cyanote is not an IDE and is not trying to become one. There is no language server, no refactoring, no debugger, no test runner, no git integration, no extension ecosystem, and no way to run anything. It cannot open a project. It opens notes.

If you are building software, that work belongs in a real editor — free ones included, and they are extremely good. Notepad++ has done the exact-text job on Windows for two decades without asking anybody for a subscription. VS Code is free and does everything listed in the paragraph above.

The distinction that matters is between the code you are writing and the code you are keeping. The first belongs in a project, under version control, in a proper editor. The second — the loose, reusable, hard-won fragments that never justified a repository of their own — is the part that has no home, and that is the part this is for.

When two apps is the right answer

If everything you touch lives in a repository, and you have never once lost a command, the split is not costing you anything and this is a solved problem you do not have.

If your notes are already Markdown files in a folder, you are most of the way there by a different route: your editor can open them, and your notes are text your tools can read. That is a legitimately good setup and I am not going to pretend otherwise.

And if you work on more than one machine, stop here. Cyanote keeps everything in one SQLite database on one disk and has no sync of any kind, which for anyone moving between a laptop and a desktop is disqualifying on its own — not a caveat, a disqualification.

The honest version

The case for one app is narrow and specific. It applies when you keep prose and you keep snippets, when the two constantly refer to each other, and when you are tired of paying a context switch to move six inches between them.

Cyanote sits on that side: notes and code notes in one window, one local database, one search box, no account and no server, for $10 once. If the fiddling itself is what you enjoy, what is actually worth customising covers the settings that change how the text reads rather than how it looks, and two kinds of attention is about arranging the work rather than the app. And if what you want is Notion with fewer moving parts, the comparison page is the more useful thing to read next.

That gap is the whole subject here.

A calendar answers one question

A calendar is built to answer "when." It is extremely good at that one job — recurring events, time zones, invitations, the free/busy grid that makes scheduling with other people possible at all. None of that is in question.

What it was never built to answer is "why," or "with what." The event is a box with a start time. Anything you needed to prepare, remember, or bring to it has to live somewhere else, and "somewhere else" is doing a lot of quiet work in that sentence.

Where the missing half actually goes

In practice it goes in one of three places, and each has its own failure mode.

A separate notes app. You open the calendar, see the meeting, then switch apps and search for notes about it — if you remembered to title them in a way you'd recognise later. Two apps, two windows, and the connection between "this meeting" and "these notes" exists only in your memory, not in either tool.

The event description field. Better than nothing, and worse than it looks. Most calendar apps give that field no formatting, no links between entries, and a search that treats it as an afterthought. It becomes a place things go to be typed once and never read again.

Nowhere. The most common answer, and the reason meetings open with "sorry, can you remind me what this was about."

None of these is a character flaw. They are what happens when the tool that shows you when and the tool that holds why are not the same tool, and moving information between them is a chore you have to remember to do under time pressure — the exact conditions under which people don't.

What changes when they share a window

Less than the pitch usually implies, and something specific: the trip disappears.

When the calendar sits in the same app as your notes and your to-dos, an event on Thursday and the note about Thursday's meeting are one click apart instead of one app-switch and one search apart. You don't have to remember to link them, because there was never a wall to cross in the first place — you write the note the same place you see the date.

The other half is the to-do side. A task with a real deadline is a calendar problem wearing a to-do list's clothes. Keeping tasks and events in the same app means "when is this actually due" and "what does my Thursday look like" are one glance, not two tools reconciled by hand. If your task list is currently a kanban board, how a personal Kanban board holds up against a real weekly to-do list is worth reading before you decide whether the board or the calendar should own a given deadline — they answer different questions and a lot of task lists try to make one column do both jobs.

A dedicated calendar app is a perfectly good answer

I'd rather say this plainly than bury it, the same as I would for any of the other pieces of this app.

If your calendar life is genuinely just scheduling — you manage several shared calendars, you're coordinating meeting times across a team, you live and die by natural-language event entry — a dedicated calendar app will beat a bundled one on the thing it specialises in. As of 16 August 2026, Fantastical's Individual Premium plan is $6.99 a month or $56.99 a year, with a real free tier underneath it for people who don't need the extras; BusyCal is a one-time purchase in the same space, aimed at people who want the polish without a subscription. Both have had years to get scheduling exactly right, in ways a smaller calendar view inside a bigger app is not trying to compete with.

The combined calendar is not for that job. It's for the much larger number of days where the interesting question isn't "schedule this meeting with four people across three time zones" — it's "what am I doing today, and what do I need to remember about it."

Where the intersection actually sits

This is the same shape of gap I found writing about the clipboard manager next to the notes app: as of 16 August 2026, none of the dedicated Mac calendar apps do notes, to-dos and a clipboard history, and none of the all-in-one productivity apps has a calendar that holds up against a purpose-built one on its own terms.

So the honest framing isn't "an all-in-one calendar beats Fantastical." It doesn't try to. It's that a calendar view sitting in the same window as the rest of your day removes the specific friction of context that lives on the wrong side of an app switch — and that most days don't need what a specialist calendar is optimised for anyway.

What to check before you rely on one

If you're weighing a bundled calendar against a dedicated one, the questions worth asking are about what it can't do rather than what it can.

Does it handle recurring events properly, including the edge cases — a meeting that moves for one week only, an event that repeats on the last weekday of the month? This is where thin calendar implementations show their seams first.

Can it show more than one day at a time when you need to plan a week rather than react to today? A calendar that only does "today" is a to-do list wearing a date.

Does it sync with the calendars you don't control — a shared family calendar, a work calendar someone else manages? A calendar that only knows about events created inside it is a smaller tool than it looks like on the pricing page.

And the same storage question that applies everywhere in this app: is the calendar data local, or does using it mean handing your schedule to a server you don't control?

The honest version of the choice

If scheduling across other people's calendars is the actual job — team meetings, shared availability, invitations that need to go somewhere real — a dedicated calendar app is doing work a bundled one isn't built for, and no amount of window-proximity fixes that.

The combined view earns its place on the much more common day: the one where you're not scheduling anything, you're just trying to see what's happening and what you need to know about it, without a trip across two apps to reassemble the two halves of the same fact.

Cyanote's calendar sits in the same window as the notes, the to-dos and the board, in a local database on your Mac, with no account and no sync to a second device. That last part means it will lose to Fantastical or BusyCal the moment you need your calendar on more than one machine — worth knowing before you switch, not after.

Both mistakes are common. This is about telling them apart.

Most customisation is procrastination

Let me get this out of the way, because a page selling a customisable app has an obvious incentive not to.

Choosing a theme feels like work. It produces visible change, it is pleasant, it is reversible, and at the end of it you have written nothing. It belongs to the same family as reorganising your folders — an activity that borrows the feeling of getting your house in order without any of the effect, and I have written about that particular trap already.

If you are deciding between two accent colours, the honest answer is that neither will affect your life and you should pick the one you like and close the settings window.

Four settings that are not decoration

The exception is narrow, and it is about reading rather than looking.

Type size. Most software ships at a size chosen for a screenshot rather than for your desk. If you have ever enlarged the text on your phone, you have already decided this matters, and the same reasoning applies to the app you read for hours.

Line spacing. This is the one people never touch and feel immediately. Text set too tight is harder to come back to — your eye loses its place returning to the start of each line, which is why the effect shows up most on the notes you re-read rather than the ones you write once.

Line length. The third is not a font setting at all: it is how wide the text is allowed to run. A note stretched across a 27-inch monitor is a genuinely difficult read, and the fix is a narrower column rather than a bigger font.

Contrast. Not "dark mode versus light mode" but the actual distance between the text and the page behind it. Too little and you squint at midday. Too much, on a black background at night, and the letters glare and smear at the edges.

Get those four right and you will read your own notes more. That is the whole return, and it is bigger than it sounds — most notes systems fail at the reading end, not the writing end.

A theme is two palettes, not one

Here is the part that is genuinely harder than it looks, and where a lot of custom themes fall over.

Your Mac switches between light and dark on its own, at sunset or on a schedule, and a theme that has only been checked in one of them will be unreadable in the other about twelve hours from when you built it. Grey-on-grey that is elegant at 2pm becomes invisible at 11pm.

So a theme worth shipping is two full palettes that have both been checked for contrast, not one palette with the brightness inverted. Cyanote has fifteen of them on that basis. A few are there for specific conditions rather than for taste:

• Newsprint — broadsheet paper and pure black ink. The highest-contrast light theme, for a bright room or a screen you are fighting with.
• Sepia — warm, low-contrast reading paper. The opposite errand: easiest on the eyes in a dim room, and the one to reach for when you are reading rather than typing.
• Phosphor — amber on warm carbon. A terminal throwback that turns out to be a genuinely good theme for looking at code.
• Midnight — true black, for OLED screens. On a Mac the point is not battery, it is that a black page in a dark room stops the whole window acting as a lamp.

The rest are ordinary and that is fine. Ordinary is what you want for eight hours.

Per-note settings, which is the actual argument

Global settings assume everything you write is the same kind of thing. It is not.

A journal entry you will re-read wants a serif, generous line spacing and a narrow column. A meeting note you will scan for one decision wants tighter spacing and a size you can take in at a glance. A snippet wants monospace and nothing else, because in code the shape of the characters carries meaning — a zero has to be distinguishable from an O, and a serif will not help you find a missing bracket.

So in Cyanote the body, heading and code typefaces are set separately, the size and line spacing with them, and the column width per note — globally or on a single note. The per-note version is the one that earns its keep, because it means the format can follow the material instead of the material being flattened to fit one setting.

It also does something quieter: it makes the kind of note visible before you have read a word of it. Open something set in monospace and you already know what you are looking at. That is worth more than any colour scheme, and it is most of why writing and code end up wanting different treatment in the same app.

Building your own, and the way it goes wrong

If none of the fifteen fits, the whole app is drawn from seven colours and you can set all seven. That is enough to build something genuinely your own.

It is also enough to build something you cannot read, and the failure is not obvious on the day you build it. Two mistakes account for nearly all of it:

Contrast that only works in one mode. You will pick your colours in the light and discover the result at night, when your accent colour has become a dark smear on a dark background.

Contrast that only works on your screen. A palette tuned on a bright display in a bright room can be unusable on the same laptop outdoors, or on an external monitor with different colour handling.

The shipped themes have been checked in both palettes. A theme you build has been checked by you, on one screen, on one afternoon. That is not an argument against building one — it is an argument for living with it for a week before deciding it is finished.

When the defaults are the right answer

If you are undecided, use the default. It was chosen by someone who had to make it work for everybody, which is a decent proxy for making it work for you.

Change the size if the text is too small. Change the line spacing if you lose your place. Change the theme if the room is dark. Those are responses to an actual complaint, and a setting changed in response to a complaint almost always sticks. A setting changed out of curiosity almost always gets changed again next month.

The point of customisation is not self-expression in an app only you will see. It is that the software should stop being noticeable, so that what you wrote is the thing in front of you.

Cyanote does this the way it does everything else: locally, in a database on your own disk, with no account, for $10 once. The settings live with your notes, which means they survive a restore and do not follow you to a second machine — because there is no sync, which is a real limitation and not a philosophical position.

So it is worth saying at the top: most of the time, the right outcome of that search is to close the tab and carry on. Maccy is free, open source and very well built. Raycast's clipboard history is free and already running if you use Raycast for anything else. Neither is a compromise you are putting up with until you can afford something better.

Both do have limits, though — and the limits are specific rather than vague. What follows is where each one stops, so you can hold your own annoyance up against the list and see whether it is on it.

Start by naming the thing that annoyed you

Describe the moment before you compare anything. Not "I want something better", but the actual failure: the item you went looking for and could not find, the setting you opened the preferences for and it was not there, the copy that came back as the wrong kind of thing.

That description does most of the work. Quite often it turns out to be a hotkey you never set, or a preference sitting two clicks away — and the alternative you were about to install would have needed the same five minutes of setup.

The rest of the time it is a decision the app made on purpose, which no future release will reverse. Those are the ones worth knowing about in advance, because they are the only ones switching apps can fix.

If you are earlier than this and the real question is why the Mac forgets what you copied at all, that is the piece to read first.

Where Maccy stops

Maccy stops at text, and at one machine. Both are deliberate.

It keeps text, by design

Maccy is text-focused on purpose. Copy an image expecting to find it in the history an hour later and it will not be there, and that is not an oversight waiting on a release. It is a decision about what the tool is — and a defensible one. A text-only history is smaller, faster and much easier to reason about, because you always know what kind of thing is in it.

The mismatch is still real if your work is visual. Designers, people assembling documents, anyone moving screenshots between apps all day: you will meet this on the first afternoon and keep meeting it. That is a genuine reason to use something else. It is not a fault in Maccy — and choosing a different app over it does not mean the app you leave was bad.

It is local only, with no sync

Maccy keeps the history on the Mac it is running on. For most people that is the feature rather than the limit. Think about what passes through a clipboard in a week: passwords on the way from a password manager to a login form, two-factor codes, private links that grant access to whoever holds them. Maccy respects the concealed-content flag password managers set, so those copies are declined rather than stored, and everything it does keep stays on one disk.

You hit the limit only if you genuinely work across two Macs and expect the history to follow you between them. That is a smaller group than it sounds — and worth being straight about: no local-first tool solves it, free or paid, because solving it means putting your clipboard on a server.

On price, checked 13 August 2026: Maccy is free and open source, with a $9.99 App Store build that exists as a way to support the work. Paying does not unlock anything. If you have been holding off on the paid version expecting features, that is the answer.

Where Raycast's clipboard stops

Raycast's clipboard stops at three months of history on the free tier — and at the fact that you cannot take the clipboard without taking the launcher.

Three months, and then it is gone

Checked 13 August 2026: Raycast is free, with Pro from $8 a month billed annually, and the free tier retains three months of clipboard history. Longer retention is part of what Pro buys.

Three months is a long time for a buffer. Almost everything you search a clipboard history for is minutes or days old: the paragraph you copied over, the code from a text message, the reference you paste twice a week. Those never come close to the limit.

The people who do hit it know the feeling. It is "what was that address I copied in the spring", or going back to a project from last year and wanting the snippets you were pasting at the time. If that is you, the thing you want is not a clipboard manager with a longer buffer. It is somewhere permanent to put things — a different problem, and the subject of the next section.

Before you assume you need it, check. Search your history for something from six weeks ago and see whether you ever actually reach for anything that old.

The clipboard comes with the launcher

Raycast's clipboard history is one surface inside a launcher. If you already run Raycast, that is entirely a benefit: nothing extra to install, nothing extra in the menu bar, one hotkey vocabulary instead of two.

If you do not want the launcher, you cannot have only the clipboard part. That is architecture rather than a fault — but it does mean "I want a clipboard manager" and "I want Raycast running all day" are one decision, not two. Some people install Raycast for the clipboard, find they use nothing else in it, and quietly resent the size of what they are running. If that describes you, a small dedicated tool is the fix, and Maccy is the obvious one.

The limit they both share

Your clipboard history and the place you keep things permanently are two different applications, and you are the bridge between them.

Something worth keeping arrives in the history. You open the history, copy the item, switch to your notes app, paste it, give it a title, and go back to what you were doing. Each crossing is small. You make several a day, and the ones you forget to make are the reason you are searching a clipboard buffer for something from March.

Neither Maccy nor Raycast is trying to solve this, and it would be odd if they were. A clipboard history is a buffer by definition, and a buffer that never forgets is just an unsorted archive of everything you have ever copied, including the things you would rather it had dropped. The question is only whether the boundary sits where you want it — and for plenty of people it does: copied things are temporary, kept things are typed on purpose, and the separation is doing useful work.

If you are shopping across the category generally rather than diagnosing one annoyance, the wider set of Mac clipboard managers is laid out here, prices included.

If none of this describes you

Then stay where you are. A free tool that does what you need is not a problem to be solved, and there is no version of this argument where you should pay to replace software that is already working. The limits above are narrow on purpose: text only, one machine, three months, one launcher. If you read all four and recognised none of them, you have not hit a limit. You have hit a Tuesday.

And if you did recognise one, the fix is usually smaller than a whole new workflow. An image-heavy day wants a manager that holds images. A launcher you resent wants a smaller tool beside it. Match the change to the thing that actually broke.

Cyanote is the option where the clipboard and the place things get kept are the same app — which removes the crossing described above — and it costs $10 once with no subscription and no account. The limitations are worth stating plainly: macOS only, one Mac, no sync, and a clipboard that lives alongside notes and to-dos rather than being the entire product. If you copy across two machines, or you want the best possible clipboard manager and nothing else, it is the wrong buy. Staying on Maccy or Raycast is a perfectly good decision, and for most people reading this it is the correct one.

It is not the whole arrangement, though. Buying once means the developer is paid once for software they then have to keep maintaining while macOS changes underneath it every autumn. That constraint does not go away because the pricing page is tidy. It shows up later, and it is worth understanding before you pay rather than after.

What a one-time payment genuinely buys

Three things, and each of them is worth having.

The software keeps working if the company disappears. This is the one that matters most — and it is a question about architecture rather than goodwill. An app that stores your work on your own disk and does not phone home to check your licence will still open the morning after its developer walks away. An app that validates against a server every launch will not, however sincerely anyone promised otherwise.

There is no renewal date. Nothing expires on a Tuesday. No card to update, no dunning email when the bank reissues it, no quiet price rise applied to you three years into using something you had stopped thinking about.

Nothing is taken away for lapsing. With most subscription software, stopping payment means the app locks or drops to read-only — and you export on the way out if the export is any good. With a purchase, stopping payment is not an event. There is nothing to stop.

That third one is the difference people underrate. A subscription is a decision you make once and then stop making — and the bank keeps making it for you. A purchase is a decision that stays made.

What it cannot buy

It cannot buy a guarantee of indefinite development.

"Lifetime updates" is the phrase you will see — and it is a promise about a term the person making it does not control. The lifetime in question is the app's, not yours. Nobody can honestly commit to shipping compatibility fixes for an operating system that has not been designed yet, funded by money that was spent years earlier.

So one-time apps tend to end in one of three ordinary ways. Some become subscriptions, usually with the old licence honoured and new work gated behind the new model. Some are quietly abandoned, still installable, slowly drifting out of step with the OS until an update breaks them. Some start charging for major versions, which is upgrade pricing under a friendlier name.

The third is arguably the most honest of the three, even though it is the one that annoys people most. Paying again for version 2 is at least a re-decision: you get to look at what the app has become and say no. It is only a bad deal when it is sold as something else.

None of this is an argument against buying once. It is an argument for buying once with your eyes open, from a developer whose costs the price plausibly covers.

Subscriptions are not the villain here

For a great deal of software, a subscription is the honest model.

If an app syncs your work between devices, someone pays for storage and bandwidth every month you keep using it. If it hosts shared documents, someone runs the servers that resolve two people editing the same paragraph. If it indexes ten years of your notes on the server side, that index costs money to keep warm. Those are recurring costs — and a payment that happened in 2023 cannot fund them in 2027. An app that tried would degrade or vanish.

So the question is not whether subscriptions are fair. It is whether the specific software in front of you has recurring costs at all. A clipboard manager running on one Mac largely does not. A sync service does. The pricing model should follow the shape of the thing — and when it does not, you are paying rent on software that runs entirely on your own laptop. I have written about how to tell those two apart in more detail.

What the prices actually look like

Worth setting out, because "you buy it once" is not unusual in this corner of the Mac market, and the spread is wider than most people expect.

Prices checked 13 August 2026, quoted for one person on macOS.

Two things fall out of that table. The first is that one-time pricing is neither rare nor cheap by nature. Things 3 asks $49.99 for tasks alone and has been a well-regarded app for years at that price. Paste sells both ways — and its one-time option at $89.99 is roughly thirty times the cheapest dedicated clipboard manager on the same list. Price in this category is not tracking function very closely.

The second is that Notion is free for one person with unlimited pages, so for a solo reader it is not a money argument at all. If you are weighing Notion, weigh it on whether the app suits you. The paid tiers exist for teams, and if you are not a team they are not aimed at you.

The comparison is rarely one app against one app

The question people actually face is not "this app or that app". It is one app against the four or five they would otherwise be paying for.

That changes the arithmetic in a way single-app comparisons hide. A clipboard manager, a task app, a calendar layer, a habit tracker and somewhere to write things down are five separate purchases or five separate line items, and each one looks small on its own. Two of them under five dollars a month is exactly why nobody adds them up. I did add mine up once, and the five subscriptions I was carrying came to roughly $2,600 over ten years, which is a number I would never have agreed to as a number.

The honest version of this comparison also has to include what the bundled app does worse. Fantastical is better at calendars than a calendar view inside something else. Things 3 is better at tasks than most task lists bolted onto a notes app. A stack of specialists usually beats a generalist at each individual job. What it loses on is the seams between them — and whether that trade is worth it depends entirely on how much of your work lives in the seams.

Three questions before you pay once

If you have decided a purchase is the right shape, these are the ones that separate a good one from a regret.

Does it need a server to start? Turn off the wifi, quit the app, open it again. If it wants the network to let you in, then the promise that it keeps working forever is only as durable as somebody else's hosting bill.

Where is the file? A real answer is a path you can open in Finder, in a format another program could read. Your work will outlive the app, including if the app is good. Whether that is a migration or a loss is decided by the format underneath.

What has the developer actually shipped? Not what they promise. A version history showing years of free updates is evidence. A line on a pricing page saying "lifetime updates" is a sentence. Check the changelog, check the dates, and see whether the pattern you are being promised has already happened.

Cyanote is $10 once — and the honest limitations are that it is macOS only, runs on a single Mac, and has no sync, so two machines means two separate sets of notes. If you work across a laptop and a desktop, or capture things on your phone, a subscription that pays for real sync infrastructure is the better arrangement — and I would rather say so here than have you find out a week in. If one Mac is where your work actually happens, the price is one number and that is the end of it.

That is the ordinary case, and it works. The interesting case is the one just past it: you copy something and, halfway through pasting it, realise you are going to want it next month too. Now you are doing paperwork. Open the clipboard history, find the item, put it back on the clipboard, switch to the notes app, make a note, paste, give it a title so you can find it again.

Nothing there is difficult. It is just a border crossing — and you are the border guard.

A clipboard manager and a notes app are solving the same problem

Both exist because you noticed something and could not use it yet. That is the whole job: catch it now, use it later. The only difference between the two tools is how long "later" is.

A clipboard manager assumes minutes. It captures everything automatically, asks you nothing, and lets the old stuff fall off the end. A notes app assumes months. It captures nothing automatically, asks you for a title and a place to put it, and keeps things until you delete them.

Neither is wrong. They are two settings on one dial. The problem is that in most setups the dial is not a dial — it is a wall, and moving anything across it is a manual act you perform by hand, several times a day, forever.

What the wall actually costs

Not much, on any single occasion. That is why it survives. The costs are the kind you only see when you go looking for them.

Things you meant to keep, that scrolled away

Every clipboard history has a limit. A few hundred items sounds enormous until you count what an ordinary day puts through the clipboard: file paths, URLs, half-sentences you moved between two documents, a code from a text message, someone's phone number, the same boilerplate reply four times.

At that rate a fortnight-old item is not old — it is gone. And the ones you lose are not random. They are the ones you copied, used, and thought "I should save that" about while doing something else more urgent. The intention to keep something almost never arrives at a convenient moment.

Things you kept, but without their context

The other failure runs the opposite way. You do save it. You paste the snippet into a note, and because you were mid-task you paste it into whatever note was open, or a new untitled one, with no sentence explaining what it is.

Three weeks later you have a note containing a bare URL, or a serial number, or four lines of configuration, and no idea what any of it was for. It is technically kept and practically lost. A clipboard history at least tells you when you copied something, which is often enough to reconstruct why.

The tax of two of everything

Two hotkeys. Two windows. Two search boxes — one of which sees only the last few hundred things you copied, the other only the things you wrote down.

The search box is the one that stings. When you half-remember an address and cannot recall whether you saved it properly or merely copied it once, you have to look in both places, in order.

What a single window changes

Less than the pitch usually implies — and something specific.

When the history and the notes are in one app, the border crossing becomes a decision instead of an errand. You find the item in the history, you keep it, and it becomes a note. There is no second window, no re-copying, no titling ritual performed under time pressure. You are still choosing what is worth keeping, which is the part that should stay manual, but you are not also doing the clerical work of the move.

The other change is the search box. One box that looks at both what you wrote and what you copied removes an entire category of question — the "did I save that or just copy it" question — because the answer no longer determines where you look.

If you want the mechanics of the capture side on its own, how clipboard history works on a Mac covers what the system does and does not give you, and why there is a gap to fill in the first place.

Two separate apps is a perfectly good answer

I would rather say this plainly than bury it.

A dedicated clipboard manager will be better at being a clipboard manager. That is what it spends all of its attention on: paste stacks, plain-text pasting, rules per application, quick-look previews, keyboard behaviour tuned over years. As of 13 August 2026, Paste is $2.49 a month, $29.99 a year, or $89.99 once, and Maccy is free and open source with a $9.99 App Store build for people who want to support it. Those are honest prices for tools that do one job carefully.

If you already have a launcher you like, the argument is even weaker. Raycast is free, with Pro from $8 a month billed annually as of the same date, and its clipboard history sits behind a key you already press fifty times a day. Muscle memory is worth more than architecture. Replacing a hotkey you have already learned is a real cost — and it does not show up on any comparison table.

And there is a version of the combined app that is worse than two apps: the one where the clipboard part is a checkbox on a feature list, kept only because it made the list longer. A history you cannot search, cannot pin to, and cannot switch off is not a clipboard manager. It is a liability with an icon.

The intersection is genuinely thin

This is the part I found surprising when I went looking. As of 13 August 2026, none of the established all-in-one Mac productivity apps includes a clipboard manager, and none of the dedicated Mac clipboard managers does notes, tasks, calendar and habits.

So the choice is not usually between two good combined apps. It is between two specialists and one generalist — and the generalists are few.

There is a reason for the gap — and it is not laziness. A clipboard manager sees everything you copy, so shipping one inside a larger app means taking on that responsibility for a feature most of your users will never open. Plenty of good software has looked at that and declined, which is a defensible call.

What to check before you combine them

If you do want the two halves in one place, the questions are about the clipboard half, because that is the one that gets neglected.

Can you set how many items it keeps, and can you turn it off entirely? An off switch that also clears what has already been saved is the difference between a setting and a promise.

Does it decline to record what your password manager marks as concealed? This is the baseline, not a bonus.

Is the history searchable and can you pin things? Without those two, the combined app is a worse clipboard manager than the free ones, and the integration will not make up for it. It is worth reading how the app describes what its clipboard manager on a Mac actually keeps rather than trusting the feature list, and where it stores it.

And ask the boring question about storage. A history on your own disk and a history on somebody's server are different products wearing the same word.

The honest version of the choice

If your clipboard is a scratch space and nothing more, if what you copy is used within the minute and never wanted again, then a good dedicated manager, or a launcher you already own, is the right tool and the rest of this is not your problem.

The combined app earns its place in one specific situation: when you keep finding that the things you copy and the things you write down are the same things at different ages — and you are tired of moving them across by hand.

Cyanote sits on that side — notes and a clipboard history in one window with one search box, on a single Mac, in a local database, with no sync and no second device. That last part is a real cost, not a rounding error, and if you work across two machines it is disqualifying on its own. Two well-chosen apps will beat one badly-fitting one every time, and there is no argument here that says otherwise.

Here is a real one. On 31 July 2013, Catch.com — then a credible Evernote competitor — announced it was shutting down its note-taking apps. The service went off on 30 August. Users had roughly a month to find the export tool and pull down a CSV or ZIP archive of everything they had written.

That is a company behaving well. Notice given, tool provided, formats that other apps could read. And it still required every single user to open one particular email during one particular month, understand what it meant, and act.

The three ways it actually goes

The orderly shutdown. Notice, an export tool, a readable format, a deadline. Catch.com is the model. You lose nothing if you are paying attention, and everything if you are not.

The acquisition. Nobody switches anything off. The app stops getting updates, then stops working on the next macOS release, then one morning will not open at all. There is no email, because from the company's point of view nothing happened. This is more common than a shutdown and much harder to plan for, because there is no date to react to.

The quiet one. A small app from a developer who stopped. The website still resolves, the download link still works, and the last release was four years ago. Nothing announces itself. You find out when you upgrade your Mac.

Only the first of these sends you an email. The other two are the reason "they will let me know" is not a plan.

What does an export actually give you?

Getting a file out is not the same as keeping your notes, and this is where most people are disappointed.

The text usually survives. Plain prose comes through nearly every export intact. If all you have is paragraphs, you are mostly fine.

The structure usually does not. Nesting, links between notes, tags, folder hierarchies, and the relationships you built are the first thing lost in translation. Notion, for instance, exports to PDF, HTML, or Markdown and CSV — and a database of linked pages becomes a directory of files with the links rewritten or broken, depending on the format you picked.

Attachments are a coin toss. Images and files may come down alongside the text, may come as a separate archive, or may turn out to have been links to a server that is about to stop answering.

Dates and metadata rarely survive. Created and modified timestamps, which are how you find anything from four years ago, are commonly flattened to the export date.

So the honest way to think about an export is not "my notes are safe" but "my sentences are safe, and I will be rebuilding the shape of them by hand".

How do you know whether you could actually leave?

There is one question that sorts every notes app into two piles, and you can answer it in a minute:

If the company vanished tonight — no notice, no email, no export tool — could you still read what you wrote tomorrow?

If the answer depends on the company doing something for you, the answer is no.

Some cloud apps have thought hard about this and engineered around it. Standard Notes, for example, publishes an offline decryption script you can download and run in a browser precisely so that its own disappearance is survivable. That is a serious answer to a serious question, and it is rarer than it should be.

For a local-first app, the question is close to meaningless. The company vanishing changes nothing about the file on your disk. The app stops getting updates — which is a real loss, and worth being honest about — but your notes do not stop existing, because they were never anywhere else.

What to do this week, whichever kind of app you use

Run the export once, now, while nothing is wrong. Not to keep the file. To find out what your app's export actually produces, which is a thing you want to learn on a calm Tuesday rather than during a thirty-day countdown. Open the result. Look at whether the structure survived. Apple Notes, for instance, exports a copy of a note as a PDF — useful for reading, useless for moving into another app and editing.

Find out where the data physically is. For a local app this is a path on your disk. For a cloud app it is somebody's server, and the export is the only door. Either answer is fine. Not knowing which one you have is not.

Put the export somewhere your backups already reach. An export sitting in Downloads is not a copy of anything; it is one failed SSD away from being nothing.

Repeat it about twice a year. Not because the format changes often, but because this is the only way you find out that the export quietly broke.

The uncomfortable summary

Software you rent has a shutdown date you do not know yet. Software that runs on your own machine has one too — but it is the date you stop being able to run it, which is years of macOS releases away and entirely visible to you.

Neither is permanent. Nothing is. The difference is whether the end of the app is also the end of the notes, and whether you find out by reading an email or by choosing.

Cyanote, the app this blog belongs to, is on the second side of that line: the notes are a database file on your own Mac, and a full export is a single JSON file you can take somewhere else. That does not make it permanent either. It just means nobody else gets to pick the date.

It is worth stopping on that screen for a second, because an account is not a formality. It is a decision about where your writing lives and who else has a copy — made before you have typed a single word.

What the account is actually for

Three things, and they are all genuinely useful:

Your notes on more than one device

This is the big one and it is the honest reason most apps ask. Sync needs somewhere in the middle to sync through, and that somewhere needs to know which notes are yours.

Sharing with other people

A shared page needs a shared truth that two accounts can both reach.

Recovery

Laptop stolen on a Thursday, notes back on the replacement by Friday. That only works if somebody else has a copy.

If you use any of those three, the account is not overhead. It is the product, and the sign-up form is the price of admission to a thing you actually want.

What it costs, stated plainly

An identity attached to your writing

Before the account, your notes were text on a disk. After it, they are text on a disk plus a record on a server saying this person wrote these things. That record is what makes sync possible, and it is also a thing that exists.

A copy you do not control

Once the notes are on a server, the list of parties who can read them is longer than one: the company, anyone it is legally compelled to answer, anyone who breaches it, and whoever owns it after an acquisition nobody consulted you about. None of that requires bad intent. It is just what having a copy means.

Deletion becomes a request

With a local file, deleting is an act you perform. With an account, it is something you ask for and then trust. In Europe the GDPR's right to erasure gives that request real legal weight, which is a genuine protection — and it is still a request, with a response time, made to somebody else.

None of these is a scandal. They are the ordinary mechanics of a service. They are simply not on the pricing page, and they apply whether or not you ever use sync.

The apps that skip it

Plenty of good software has decided the form is optional.

Apple Notes can run entirely locally. Most people never find this, because iCloud is on by default — but Notes has an "On My Mac" account you can enable in its settings, and notes stored there stay on your computer, unreachable from your other devices and from iCloud.com. That is the whole trade in one checkbox: no account, no sync.

Obsidian works on a folder of Markdown files with no account needed to use it, selling sync separately to people who want it. That is the honest shape of this: the account appears when, and only when, you ask for the thing that needs one.

There is a small, healthy category of Mac apps built the same way — open it, write, no form. The pattern is always the same underneath: no sync, therefore no server, therefore no account.

Four questions that settle it in a minute

If you are looking at an app and cannot tell:

1. Can you get to a blank note without typing an email address? If not, something is being created on a server before you have written anything.
2. Where is the file? A real answer is a path you can open in Finder. "In the app" means somebody else knows and you do not.
3. Turn the wifi off and use it for an hour. Everything should work — not most things.
4. What happens if you stop paying, or stop using it? With a local file, nothing happens. With an account, find out before you need to know.

That fourth one is the same question as what happens when the app shuts down, asked earlier and more cheaply.

The part people get backwards

The mistake is not choosing an account. It is choosing one by default and then never using what it bought.

If your notes are on one Mac, you never open them on your phone, you have never shared a page, and your backups are already handled — then the account is doing nothing for you at all. You are carrying the costs of a service you are not consuming, because a sign-up form was the first screen and nobody thinks to close it.

And if you do work across two machines all day, the opposite holds just as firmly: an account-less app will be a daily irritation, and no amount of privacy argument makes single-device sync appear. Choose the one that matches how you actually work, not the one that matches how you would like to feel about your software.

Cyanote is on the account-less side — one Mac, a local database, no sign-up, and consequently no sync. That is a real limitation and I would rather say it here than have you discover it on Tuesday. If it is the wrong trade for you, one of the apps above is a better answer, and there is no hard feeling in that.

That is not a complaint about the developers. Some of these apps are excellent and the people who make them deserve to be paid. It is a complaint about the shape of the deal, which has drifted a long way from what the software does. A clipboard manager watches a system pasteboard and writes to a local database. It is one of the few categories where you can look at the running app and struggle to name the server it needs.

So it is worth being precise about when a subscription is buying you something and when it is buying you nothing.

If you are still at the earlier question — why the Mac forgets what you copied at all — start there.

What the monthly fee is actually for

There are three honest answers, and they are not the same.

Sync. If your clipboard history follows you from a laptop to a desktop to a phone, there is a server in the middle holding it, and somebody pays for that server every month. This is a real cost and a real feature. It is also the one that should give you the longest pause, because it means everything you copy — including the things you copied out of a password manager — is leaving your machine.

Ongoing development. macOS changes every year and breaks things. Somebody has to fix them. This is real work, but it is worth noticing that it argues for charging new customers, not for charging the same customer rent in perpetuity for a version that already works.

Because it worked for everyone else. The least satisfying answer, and frequently the true one. Subscriptions became the default pricing model across all software, and a category that did not need one adopted it anyway.

The first is a genuine trade. The third is not.

What you give up buying once

Being fair to the other side: one-time purchases have failure modes, and pretending otherwise is how people end up disappointed.

The app can be abandoned. A developer who has already been paid has no recurring reason to keep going, and plenty of one-time apps have quietly stopped at the last macOS version that worked. A subscription at least aligns somebody's rent with your software continuing to run.

"Buy once" often means "buy this major version". Paid upgrades every two years are a legitimate model, but they are not the same promise as the one on the marketing page, and the difference tends to surface at version 3.

And the smaller the developer, the more the whole thing rests on one person staying interested. That is true whichever way they charge you — but with a subscription you find out sooner, because you notice when the charges stop being worth it.

What to check before you pay either way

Regardless of the pricing model, the same five questions decide whether a clipboard manager is any good:

Where the history is stored. Local database, or somebody else's server. This is the first question, not the last.

Whether it is searchable. A list of the last ten items is a convenience. A searchable history of everything is a different tool.

What it does with sensitive copies. Recognising a password-manager copy and declining to keep it is the mark of an app that has thought about this.

Whether it holds more than text. Images, files and colours all travel through the clipboard.

What happens on the day it stops. Can you get the history out? For a local app: where is the file, and can you read it without the app?

That last one matters more for a one-time purchase than a subscription, because a one-time purchase is the one you expect to still be using in five years.

The honest version of this page

This blog belongs to Cyanote, which has a clipboard manager in it and costs $10 once. So take the following as an interested party's summary rather than a neutral roundup.

If you want the best clipboard manager on the Mac and nothing else, you should probably buy a dedicated one. Maccy is free and open source and very good. Paste is polished and syncs across devices, and it charges for the servers that make that work — a subscription, or $89.99 once if you would rather not rent it, which is the honest version of the trade described above. Raycast bundles clipboard history into a launcher. Any of those will out-feature a clipboard that sits inside a notes app, because that is their whole product and this is one of five.

Paste is the one people ask about most, so it has a page of its own working through the prices and the cases where it is the better buy.

What a bundled one gets you is the thing you copied out of a note being one hotkey from the note you copied it from, and one purchase covering both. Whether that is worth more than depth is genuinely a matter of what you are trying to stop doing.

The short version

If the app syncs, a subscription is paying for something real, and the question I would ask myself is whether I want that something on a server at all. If it does not sync, ask what the monthly charge is for, and be unsatisfied with a vague answer.

The clipboard is a small tool that you touch two hundred times a day. It is worth paying for. It is not obviously worth renting.

That last translation loses the thing that made it work. What follows is what survives the trip to one person, and what to do instead of the three columns everyone starts with.

The idea that actually transfers

Kanban's core insight is not columns. Columns are how you see it. The insight is limiting how much is in progress at once.

On a factory line the reason is inventory: half-finished work sitting between stations is money doing nothing. For a person, the equivalent is more familiar. Eleven things started, none finished, and a nagging sense of being busy without anything shipping. Every one of those started things costs you something to keep in your head, and the cost is charged whether or not you touch it that day.

A board makes that visible in a way a list cannot. A list of thirty tasks looks the same whether you have started three of them or all thirty. A board with fourteen cards in Doing looks obviously wrong from across the room.

That is the whole benefit, and it is a real one. If you take nothing else from Kanban, take the limit.

Why To Do / Doing / Done disappoints one person

The standard three columns come from team boards, where they answer a genuine question: which stage of a shared process is this in, and who has it now? Design, then build, then review, then ship. The columns are handoffs.

Working alone, you have no handoffs. Everything is yours at every stage. So the middle column stops describing a stage and starts describing "things I have opened", which is not information — you knew that. Meanwhile "To Do" becomes a single undifferentiated wall of forty cards, which is a list with extra scrolling and less detail per line.

The columns are answering a question you don't have.

Columns worth using instead

For one person, the useful axis is usually when, or how much this matters, rather than what stage it is in.

By commitment. Today · This week · Later · Someday. Cards move leftward as they become real. This is the version most people find sticks, because it maps onto the actual decision you make each morning, which is not "what stage is this in" but "am I doing this today or not".

By priority. High · Medium · Low · No priority. Blunter, and genuinely good if your work arrives as a stream of requests from other people and the hard part is triage rather than scheduling.

By energy. Deep work · Shallow · Errands · Waiting on someone. Odd-looking, and effective if your days vary a lot. At 4pm on a Thursday you do not need your most important task, you need one you can actually do, and this is the only layout that answers that.

Whichever you pick, keep Waiting as its own column. Work that is blocked on another person is not done and is not yours to do, and it is the single most common thing to lose track of. A column full of them, reviewed weekly, is worth more than most productivity advice.

Set the limit and make it hurt slightly

Pick a number for how many cards may be in your active column at once. Three is a good starting point for most people; five if your work is genuinely interrupt-driven.

The rule that gives it teeth: to start something new when you are at the limit, something has to come out. Not "finish it" necessarily — you can push a card back to This week, or to Waiting if it is blocked. But you have to make the swap deliberately and see yourself do it.

This is uncomfortable at first, which is the point. The discomfort is information you were previously ignoring. Almost everyone who tries this discovers their real number of simultaneous commitments was somewhere near eleven and that it had been that way for months.

Small things that make a board work

• One card, one outcome. "Website" is not a card; it is a column pretending to be one. If you cannot say what "done" looks like in a sentence, it is a project and its next action is the card.
• Done is not a graveyard. Keep the last week or two visible, then archive. Seeing a fortnight of finished work is one of the few honest counterweights to the feeling of never getting anywhere. Keeping eight months of it is just a slow list.
• A due date is a promise, not a wish. If most cards have dates and most dates pass unremarked, the dates have stopped meaning anything and you have lost the ability to see the ones that are real.
• Review the board weekly. Boards rot faster than lists, because a stale card looks identical to a live one. Ten minutes a week to move things back and delete what you were never going to do.

When a list is simply better

Boards are not universally superior, and the honest limits are worth stating.

If your work is a long, flat queue of similar items — a hundred small edits, a reading list, invoices to send — a list wins. It shows more per screen, sorts instantly, and the spatial layout of a board buys you nothing when every item is the same shape.

If most of your commitments are appointments, a calendar wins. Kanban has no opinion about time and no way to show that two things collide at 3pm on Thursday.

And if you have fewer than about ten live tasks, a board is ceremony. The visualisation earns its keep when there is enough work that you cannot hold the shape of it in your head. Below that, you can, and the cards are just something else to maintain.

The answer I keep coming back to is not one of these. It is the same tasks seen as a list when you are working through them and as a board when you are deciding what to work on — a decision that pairs well with a weekly pass over the whole lot — which is a question about the view, not about the tool.

That is the bet Cyanote makes with its to-dos: one set of tasks, a list when you are working through them and a board when you are deciding what to work on, with priorities and due dates carried between the two.

Here is what each layer actually does on a Mac, in the order they stop working.

The three layers, and what each one stops

Your login password stops someone who walks up to your Mac while it is asleep. It does nothing at all once you are logged in — every app you have is sitting there open, including whatever your notes are in. Useful, and the weakest of the three.

FileVault encrypts the whole disk. It stops someone who has your Mac in their hands and it is powered off — a thief, a lost laptop, a machine sent for repair. Without it, pulling the drive out and reading it on another computer is genuinely trivial. With it, the contents are unreadable without the key.

Its limit is the one people miss: FileVault protects a Mac that is off. Once you have logged in, the disk is decrypted and everything on it is readable by anything running as you. FileVault is not protecting your notes from your own running Mac.

A locked note is the only one of the three that still means something while you are sitting there logged in. It is per-note encryption, and the note stays unreadable until you supply the password — including from someone borrowing your unlocked laptop for five minutes, or looking over your shoulder while you have the app open.

You want all three. They are not alternatives.

How do you lock a note in Apple Notes?

Apple Notes has built-in locking, and for a lot of people it is enough.

Select a note, then File → Lock Note, or right-click the note in the list and choose Lock Note. macOS will ask you to set things up the first time. Recent versions let you use your Mac's login password rather than a separate Notes password, which is a meaningful improvement — a separate Notes password was the single biggest cause of permanently lost notes in that app.

Two things about it are worth knowing before you rely on it:

If you forget the password, the note is gone. This is not Apple being unhelpful; it is what encryption means. There is no reset that recovers the contents, and support cannot open it for you. If you set a Notes-specific password, put it in your password manager the same minute you create it.

Locking is per-note and you have to remember to do it. The sensitive thing usually gets written first and locked later, if at all. The note that needed protecting is often the quick one you typed in a hurry.

What "encrypted" should mean when an app claims it

Any note app can put a password prompt in front of a note. That is a UI, and on its own it protects against nothing — if the text is still sitting in plain form in the app's database, anybody who opens that file with the right tool reads it without ever seeing your prompt.

The question to ask is whether the note is encrypted at rest: unreadable in storage, decrypted only when you supply the key. The tell is the one described above — if the app can show you a preview of a locked note, or search inside it while locked, then it is not encrypted, it is hidden.

A quick, genuinely useful check for any app that claims per-note locking:

• Lock a note containing a distinctive phrase.
• Quit the app.
• Search the app's data folder for that phrase from the Terminal.

If the phrase turns up, the lock is decoration. If it does not, the encryption is real.

Where are your notes actually stored?

This part is worth knowing regardless of which app you use, because it determines who else can read them.

A note in a cloud-synced app exists in at least three places: your Mac, the provider's servers, and every other device signed in. Locking on your Mac does not necessarily mean the copy on the server is locked, and the provider's privacy policy — not your password — is what governs that copy. Apple encrypts locked Notes end-to-end, so the server copy is genuinely unreadable to Apple; not every provider does the same, and most are vague about it.

A note in a local-first app exists in one place: a database on your own disk. There is no server copy to reason about, which removes an entire category of question. The trade is that there is also no server copy to restore from, which makes backups your job rather than someone else's.

Neither is automatically safer. They fail differently, and the failure you should plan for is the one you can actually imagine happening to you.

The setup I would actually use

If you want a short version:

1. Turn on FileVault. System Settings → Privacy & Security → FileVault. Store the recovery key somewhere that is not the Mac. This is the highest-value fifteen minutes of security work available on a Mac and most people have never opened that screen.
2. Set the screen to lock quickly. A screen that locks after an hour is a screen that does not lock.
3. Lock the handful of notes that genuinely warrant it — recovery codes, medical details, anything about other people who did not choose to be in your notes app.
4. Put the password in your password manager, immediately, before you close the dialog.
5. Back up. Encryption increases the number of ways you can lose things permanently. Time Machine, or an export somewhere else, is what makes that recoverable.

If you are choosing an app for this rather than staying with Apple Notes: Cyanote can lock any individual note behind a password, on top of FileVault rather than instead of it — the layers in the first section are not alternatives.

The point of locking a note is not that your notes are a secret. It is that a few of them are somebody else's secret, and those deserve better than being one open laptop away.

This is not a post about subscriptions being a scam. Some of them are entirely fair, and I will make that case below before making the other one. It is a post about what you are actually paying for in each model, and what a one-time purchase has to include before it means anything.

Why note apps went to subscriptions

The honest reason is that most of them run servers.

If an app syncs your notes between devices, somebody is paying for storage, for bandwidth, and for the engineers who keep it all running at 3am. That cost recurs every month you keep using it, whether or not the app gained a single feature. A one-time payment cannot fund an ongoing cost — the maths simply doesn't work, and an app that tried would either degrade or disappear.

There is a second reason, less often stated: subscriptions produce predictable revenue, and predictable revenue is what lets a company plan. A one-time-purchase app has to keep finding new customers forever to pay yesterday's salaries. That pressure is real, and it is why so many apps that started as a purchase ended up as a rental.

So if an app genuinely runs infrastructure for you, a subscription is the honest price of it. The question worth asking is whether it runs infrastructure for you.

What you are renting

The uncomfortable part of the model is what happens when you stop paying.

With most subscription note apps, the answer is that you lose access to the app but your notes are still "yours" in the sense that you can export them. That is better than nothing. It is also less reassuring than it sounds, because export quality varies enormously — a folder of Markdown files with your structure intact is a real escape route, and a single JSON blob with proprietary block references in it is a hostage note.

Worth knowing before you commit, not after:

• Can you export everything, including attachments, in a format something else can open?
• Does the export keep your links between notes working, or does it flatten them?
• If you stop paying, is the app read-only, or does it lock you out entirely?
• Is the export a feature of the free tier, or does cancelling remove the tool you need to leave?

An app that answers all four well is one you can leave, which is the only thing that makes staying a choice.

What "buy once" has to include to mean anything

The one-time purchase has its own failure modes, and they are worth naming, because "pay once" on a pricing page can hide several different deals.

Free updates, not just free patches

The oldest trick in the category is selling version 1, then selling version 2 eighteen months later to the same people. That is a subscription with extra steps and worse communication. The version that means something is the one where updates keep coming and keep being included.

No feature gates

If the purchase unlocks the app but the interesting parts are separate purchases, you did not buy the app. Check whether the price on the page is the price of everything.

It keeps working if the company stops

This is the one that actually matters, and it is a question about architecture rather than intent. An app that stores your notes on your own machine and does not check in with a server keeps working the day after its developer walks away. An app that phones home to validate your licence every launch stops working the day that endpoint goes dark, no matter how sincerely the developer promised otherwise.

Ask specifically: does it need the internet to start? Does it check my licence more than once? Where exactly are my notes on this disk?

A plain data format underneath

Your notes will outlive the app you write them in — that is true of every app, including good ones. The thing that determines whether that is a migration or a loss is whether the format underneath is something another program can read.

The two models, side by side

Set out together, they differ in ways that have nothing to do with which one is better:

Neither column is the winning one. The top row is the whole argument: if the money is buying servers you actually use, the left column is a fair deal. If it isn't, you are paying rent on software that runs on your laptop.

The case for buying, when the app is local

Here is where the two halves of this join up.

An app that keeps everything on your own computer — the local-first model — has no servers to pay for. There is no per-user monthly cost to recover, because there is no per-user monthly cost. The development work is real and ongoing, but that is funded by new customers, not by charging the existing ones rent for storage that doesn't exist.

That is why the local-first corner of the market still sells one-time licences while the cloud corner mostly cannot. It is not a moral difference between the developers. It is a difference in what the software actually costs to run.

So here is the test I apply when I am comparing two apps and one is $8 a month and the other is a single payment: ask what the monthly one is doing with a server. (What it means for an app to not need one is worth understanding before you decide.) If the answer is "syncing across my devices, sharing with my team, and running search across ten years of notes", the subscription is buying you something. If the answer is "not much, really", you are paying rent on software that lives on your laptop.

For the sake of declaring it: Cyanote, the app this blog belongs to, is one of the one-time ones — $10, local, no account, no server to pay for. That is the argument above applied to itself, and you should hold it to the same test.

Both models can be honest. Only one of them should be the default, and it isn't the one that became one.

That is worth saying up front, because most advice about organising notes assumes the goal is a tidy structure. It isn't. The goal is that in eight months, when you half-remember something, you can find it in under a minute. Every system below should be judged against that and nothing else.

There are three tools, and they are not competing versions of the same thing.

Folders: one home, one decision

A folder puts each note in exactly one place. That constraint is the entire feature — it is what makes a folder tree navigable, and it is what makes it painful.

Folders are genuinely good when a note belongs to something with a beginning and an end. A client, a trip, a house move, a course. The project starts, notes accumulate, the project finishes and the whole folder goes quiet. You will never wonder whether the plumber's quote belongs under "House" — that is not a hard call.

Folders go wrong the moment a note honestly belongs in two places. A note about pricing your freelance work is both "Freelance" and "Money". You will file it in one, look for it in the other, and conclude the system is broken. It isn't; you asked a filing cabinet to hold something in two drawers.

The failure mode to watch for: a folder tree more than about three levels deep. Deep trees are a sign you are encoding facets — status, topic, year — as nesting, and facets are what tags are for.

Tags: many labels, one note

Tags invert the constraint. A note can carry as many as you like, so the two-places problem goes away.

The cost is that tags require you to be consistent with yourself over years, which is a genuinely hard thing to be. You tag something #finance in March and #money in September. Neither is wrong, and now half your notes are invisible to each search. Tag lists sprawl, and a tag list with two hundred entries is not an index, it is a second problem.

Tags work best when you keep the vocabulary small enough to hold in your head — somewhere under about fifteen. That usually means using them for one axis and one only. Status is the classic good use: #waiting, #someday, #reference. These are things a note is right now, they change over time, and there are only a few of them.

Using tags for topic is where people drown, because topics are unbounded. Every new subject you encounter is a candidate tag, and nothing ever tells you to stop.

Is search on its own enough?

Full-text search across everything you have ever written is the reason all of this is less important than it used to be. If you can type a distinctive phrase and land on the note, the folder it sits in stops mattering very much.

This genuinely changes the correct answer. Most of the elaborate systems people inherit were designed for tools where finding things was expensive. When retrieval is nearly free, the effort belongs at the moment of writing, not the moment of filing.

The limit of search is precise: it only finds words you actually wrote. If you search for "the thing the accountant said about the car" and the note says "vehicle expense, business use proportion", you will not find it. Search does not know what you meant.

There is also a stubborn human limit, and it is worth knowing before you throw your folders away. Researchers studying how people retrieve their own files have found repeatedly that, even when the search engine is good, people navigate to a known location first and search only as a last resort — and that when they do search, it takes them longer and fails more often. One neuroimaging study found that moving through a folder tree recruits the same brain structures used for navigating physical space, which is a fair explanation for why the habit outlives every improvement to search. So the honest version of this section is not "search replaced folders". It is that search removed the penalty for filing badly, while most people still reach for a place before they reach for a query.

Which points at the highest-leverage habit in this entire post, and it has nothing to do with structure.

The reason this blog's app leads with full-text search across every note rather than a folder tree is the same one: Cyanote assumes you will search, and treats folders as somewhere to put things afterwards.

What should you name a note?

The title is the one piece of metadata you fill in every single time, without deciding to. It is free. And most people waste it.

A note called Meeting is unfindable. Notes is worse. Untitled 47 is a small future tax you have chosen to pay.

Write the title as the sentence you would say to someone describing the note eight months from now. Not "Insurance" but "Why we switched car insurers and what it cost". Not "Ideas" but "Ideas for the workshop, from the walk in February". The second version contains the distinctive words you will actually type into a search box, because they are the words your memory kept.

This one change does more for retrieval than any folder structure, and it costs four extra seconds.

Links: the option people forget

The fourth tool is pointing one note at another. Where folders and tags describe categories, links describe relationships — this note came out of that meeting, this decision replaced that one.

Links are strongest for material that grows over time: an ongoing topic where notes refer back to each other, a decision log, anything where the connection between two notes is more informative than the category both sit in. They are overkill for a receipt.

A word of caution, since this is where note-taking gets faddish: an elaborate web of links is the most enjoyable form of the procrastination this post opened with. Link things when the connection is real and you would want to follow it. Do not link things to build a graph.

A setup that survives contact with real life

If you want something concrete:

• Search is the primary way you find things. Assume it, and write titles accordingly.
• A shallow folder for each live project, plus one for reference and one for archive. Two levels. When a project ends, move the folder to archive rather than tidying it.
• Tags for status only — the handful of states a note can be in. Not topics.
• Links where a relationship genuinely exists, and nowhere else.
• Back the archive up. An archive you cannot recover is not an archive; the backup side of this takes an afternoon once.
• Archive rather than delete. Search makes an archive cheap; a note you cannot find is already effectively deleted, and one you deleted is not coming back.

The test I hold any of this to is not whether it looks organised. It is whether, in eight months, you find the thing. Everything that does not serve that is a hobby, and it is fine to have hobbies — just don't confuse one with a system.

If you came here from Windows this is genuinely surprising. Windows has had Win + V since 2018, and it shows a scrollable list of recent copies. There is no macOS equivalent, and there never has been.

What follows is what the system actually gives you, why the gap exists, and what to do about it.

Does macOS have a clipboard history?

There are three things people mistake for clipboard history. None of them is.

Finder's clipboard viewer

Open Finder, then Edit → Show Clipboard. A small window appears showing what is on the clipboard right now. That is the whole feature. It is a window onto the single current item, useful for checking whether a copy worked and useless for getting back anything older.

Universal Clipboard

Copy on your Mac, paste on your iPhone. It is genuinely good and it is not history — it moves the one current item between your devices and expires it after a short while. There is no list, and nothing is stored.

Undo

Cmd + Z will bring back text you deleted in a document. It has nothing to do with the clipboard and will not help you recover something you copied over.

Why the gap exists

The clipboard is a system-wide scratch space that every app can read. That is what makes it useful, and it is also why keeping a history of it is a genuinely uncomfortable feature to ship by default.

Think about what passes through your clipboard in an ordinary week. Passwords, on the way from a password manager to a login form. A two-factor code. Your address. A card number. An API key. A private link that grants access to whoever holds it. All of it, sitting in the same buffer as the URL you copied to send to a friend.

A clipboard history turns that stream into a record. That is exactly what makes it useful and exactly what makes it a liability, and how a given tool handles that distinction is the thing worth paying attention to.

The moments where it actually bites

Nobody wants clipboard history in the abstract. People want it because of specific, recurring, small disasters:

• You copy a paragraph, then copy something else to look it up, and the paragraph is gone.
• You paste the same three snippets — an address, a bank reference, a boilerplate reply — thirty times a week, and each one means going and finding it again.
• You copy a code from a text message, get distracted, copy a link, and now you need the code again and it has expired.
• You are moving content between two documents and every single trip is one copy and one paste, because you cannot carry more than one thing at a time.

None of these is a crisis. Together they are one of those small frictions that is invisible until it stops.

What does a clipboard manager actually do?

A clipboard manager is a small background app that watches the clipboard and keeps what passes through it. When you want something back, you open it with a hotkey, find the item, and it goes back on the clipboard ready to paste.

That is the whole idea. The differences between them are the things worth checking:

Where the history is stored

This is the first question, not the last. A clipboard manager sees everything you copy. If it syncs that to a server, everything you copy is now on somebody else's computer. If it keeps the history in a local database on your own machine, it isn't. Both designs exist and the marketing rarely leads with which one you are getting.

Whether it is searchable

A list of the last few items is a convenience. A searchable history of everything is a different tool — you stop thinking of it as "undo for copying" and start using it as a place things can be found later.

What it does with sensitive copies

Good behaviour: recognising when a password manager put something on the clipboard and declining to keep it. Also good: letting you delete an individual item, and clear the lot in one action.

Pinned items

The three snippets you paste constantly should not scroll away under a week of ordinary copying. Pinning is what turns a history into a set of shortcuts.

Whether it holds more than text

Images, files and colours all travel through the clipboard. A manager that keeps only text quietly drops the rest.

Disclosure, since this blog belongs to one: Cyanote keeps its clipboard history in a local database on your Mac, searchable, with pinning for the snippets you paste constantly. It is one of five things it does rather than the only one — which is either the point or the drawback, depending on what you came for.

If the subscription question is what is actually holding you up, that is its own decision. And if you are weighing this against Paste specifically, the two are compared here, prices included.

Before you install one

Two things I would do regardless of which tool you choose.

Check what it wants access to. A clipboard manager needs to read the clipboard, and that is a reasonable thing for it to ask. It does not need an account, and it does not need to send anything anywhere. If it wants both, ask what for.

And decide what you want it to forget. The most useful setting in any clipboard manager is the one that stops it keeping the things you would rather it didn't — whether that is a password-manager exclusion, an app blocklist, or a history that expires.

The gap in macOS is real and it is not closing. But it is one of the few missing features where the fix is genuinely small, sits out of the way, and pays you back the first afternoon you use it.

This is that job, and it is smaller than it sounds.

Is sync the same thing as a backup?

Worth getting out of the way first, because it is the single most common mistake in this area, and it catches people who thought they were being careful.

Sync propagates changes. That is its purpose and it is very good at it. Which means when you delete a note, sync faithfully deletes it everywhere, immediately. When a file is corrupted, sync distributes the corruption. When you paste over three paragraphs and quit, sync ensures all your devices agree on the wrong version.

A backup is different in one specific way: it can give you back a state from before the thing you regret. If a system has no notion of "yesterday", it is not a backup, whatever it is called.

Cloud note apps blur this because most of them do keep version history, which is a backup — of the note contents, on their servers, subject to their retention policy. Useful. Just not the same thing as sync, and worth knowing which one you are relying on.

Does Time Machine back up my notes?

On a Mac, Time Machine is most of the answer, and it is already built in.

It keeps hourly snapshots for the last 24 hours, daily for the past month, and weekly beyond that, until the disk fills and it starts dropping the oldest. That's a real answer to "get me the version from before Tuesday". Turn it on, point it at an external disk, and the majority of this problem is solved by a single setting.

Two limits are worth knowing.

It is one disk in one building. A Time Machine drive sitting next to the Mac protects against a dead SSD and a bad afternoon. It does not protect against theft, fire or flood, because it is in the room. That is what the offsite copy below is for.

It is only as recent as the last time you plugged it in. A backup drive in a drawer contains a snapshot of whenever you last remembered. If your backup disk is not permanently attached, the honest question is not whether you have a backup but how old it is.

The rule worth actually following

The 3-2-1 rule has survived decades because it is simple: three copies of anything you care about, on two different kinds of storage, one of them somewhere else.

For notes on a Mac that translates to something quite ordinary:

1. The working copy on your Mac.
2. Time Machine on an external disk.
3. Something offsite — a cloud backup service, an encrypted copy in whatever cloud storage you already pay for, or a second drive you keep at work or a relative's house and swap occasionally.

The third one is the one people skip, and it is the one that covers the scenarios where you lose the building rather than the file.

If the offsite copy goes to a cloud service and the whole point of keeping notes local was privacy, encrypt it before it leaves. Disk Utility can make an encrypted disk image; several backup tools will do it for you. An encrypted archive in someone else's cloud is a different proposition from your notes in someone else's app.

Export and backup are not the same thing

Any note app worth using can export. It is worth understanding what that gets you, because it is not the same as a snapshot.

A backup restores the app to a previous state — structure, links, attachments, the lot. It is what you want after a mistake.

An export produces files something else can read. It is what you want when you leave the app, or when the app is no longer available to restore into. It is the difference between recovering and escaping.

You want both, for different days. A backup is worthless if the software it restores into no longer exists; an export is a poor recovery tool because it usually loses structure.

So: whatever your app's export produces, run it once, now, and look at the output. Can another program open it? Are the attachments there, or just links to files that live inside the app? Do notes still reference each other, or has the structure been flattened into a folder of text? Ten minutes spent finding this out while everything is fine is worth a great deal more than finding out during a recovery.

Test the restore

A backup you have never restored is not a backup. It is a hypothesis.

The failure mode is boringly common: the drive was full, the job silently stopped months ago, the encryption password was never written down, the export was producing empty files the whole time. Every one of these is invisible until you need the thing, at which point it is also unfixable.

The test does not need to be elaborate:

• Restore a single note from a week ago into a scratch location. Open it. Confirm it is the note.
• Check the date of the most recent backup. If it surprises you, that is the finding.
• Confirm you can actually get in — the recovery key, the encryption password, the account. Store them somewhere that is not the machine being backed up. A recovery key saved only in the notes app you are trying to recover is a joke you only get to hear once.

Twice a year is plenty. I keep it on the calendar, because it is exactly the kind of task nothing will ever remind you to do.

The short version

Turn on Time Machine today; it is fifteen minutes and covers most of it. Add one offsite copy, encrypted if the contents are private. Run your app's export once so you know what it produces before you need it. And restore something, twice a year, so that you know.

Cyanote, the app this blog belongs to, exports to a single JSON file, and a restore replaces what is there rather than merging into it, after writing a rescue snapshot first. Worth knowing which of those two your own app does before the day you need it.

The point of keeping your notes on your own computer is that nobody else can lose them. The corollary is that nobody else can save them either.

Here is the plain version. In a cloud app, the server holds the truth. Your device holds a cache of it. When you type, the change is sent somewhere, accepted, and sent back. In a local-first app, your computer holds the truth. The app reads and writes it directly. The network, if there is one at all, is a convenience layered on top.

That sounds like an implementation detail. It is not. It changes how the app behaves on a bad train, what happens when the company folds, who can read what you wrote, and whether your notes still exist in ten years. It also takes some things away, and I will get to those, because a post that only lists the upsides is an advert.

What it changes, concretely

The app is fast in a way that is hard to fake

When you press a key in a cloud-first editor, something has to go over a network eventually. Good apps hide this well — optimistic updates, local caches, careful loading states. But the seams show under load: a long note that takes a second to open, a search that spins, a list that arrives a beat after the window does.

A local-first app reading a file on your own disk has no network to hide. Opening a note is a disk read measured in single-digit milliseconds. Search across everything you have written is a local index query. There is no clever engineering here — the latency is simply not there to begin with.

Offline is not a mode

Cloud apps have an offline mode, which is a set of behaviours that switch on when the network goes. It works, mostly, and then you find the edge: the note that will not open because it was never cached, the sync conflict when you land, the file that quietly reverted.

For a local-first app, offline is not a mode. It is the normal condition. A plane, a basement, a hotel with a captive-portal wifi that never quite lets you through — none of these are events. Nothing behaves differently because nothing was depending on the network in the first place.

Nobody else has a copy

This is the part people care about most and describe least precisely. It is not really about trusting or distrusting a particular company. It is about the number of places your writing exists.

If your notes are on a server, then your notes are readable by: the company, anyone the company is legally compelled to answer, anyone who breaches the company, and any future owner of the company after an acquisition you were not consulted about. None of those require bad intent. They are just what having a copy means.

If your notes are on your disk, that list is: you, and anyone with your computer.

It outlives the company

Cloud apps die badly. The service shuts down, you get ninety days' notice and a zip file export in a format nothing else reads, and the structure — the links, the nesting, the dates — arrives as mush.

A local-first app that shuts down leaves you exactly where you were. The files are still on your disk, in whatever format they were in yesterday. The app stops getting updates; your notes do not stop existing. This is the least discussed advantage and, on a ten-year horizon, probably the largest.

The costs, honestly

Here is what you are actually giving up. I would rather you read this now than discover it a week after buying something.

No sync between machines

This is the big one and it is not a small inconvenience.

If your notes are on your MacBook, they are on your MacBook. Sit down at a desktop and they are not there. There is no "log in and everything appears", because there is no account and nothing to appear from.

Some local-first apps solve this with peer-to-peer sync or by putting the data folder in iCloud Drive or Dropbox, which works but reintroduces a cloud service and, with it, conflicts when two machines edit the same thing. Others, Cyanote included, do not solve it at all yet: one computer, one set of notes.

If you genuinely work across two machines all day, this is disqualifying, and you should choose a cloud app with a clear conscience. Being honest about that is more useful to both of us than pretending single-device is a lifestyle choice.

No phone

Related, and equally real. Local-first on a Mac means the thought you have on a bus does not go into the same place as everything else. Plenty of people run a small capture app on their phone and move things over weekly — that works, and it is an extra step you did not previously have.

Backups become your job

With no server there is nobody keeping a spare copy for you. A cloud app's genuine advantage is that a stolen laptop is an inconvenience rather than a loss.

Local-first moves that responsibility across the line to you. This is manageable — Time Machine, or an occasional export to an external disk, covers it entirely — but it only works if you actually do it. Set it up on day one, not after the first scare.

No collaboration

Shared documents, comments, someone else's cursor in your paragraph: these need a server, because they need a shared truth that two people can both reach. Local-first apps are for one person's own thinking. That is a genuine limitation and not a philosophy.

How can you tell whether an app is actually local-first?

The label is easy to claim. Three questions settle it:

1. Can you create an account-less install? If signing up is mandatory, the server holds something. That may be fine, but it is not local-first.
2. Where is the data, and can you open the folder? A real answer is a path. If the answer is "in the app", ask again.
3. Turn the wifi off and use it for an hour. Everything should work. Not "most things" — everything.

A fourth, softer test: what happens when you cancel? If there is nothing to cancel, that tells you where the data was.

Where Cyanote sits

Cyanote stores everything in a SQLite database on your own Mac. There is no account, no server holding your notes, and no telemetry. The app makes two network requests of its own and no others. A new install sends the licence key from your purchase email to Lemon Squeezy, once, to confirm the purchase — that is the only moment the app needs a network at all, and there is nothing to sign in to. After that it checks for a new version, about every six hours while it is open, carrying no key, no account and no identifier. Neither request carries a word you have written. Individual notes can be locked with a password on top of that.

It takes the trade-offs above rather than dodging them. There is no sync and no iOS app. What it offers in exchange is that the whole thing — notes, tasks, calendar, habits, clipboard history — opens instantly, works in a basement, and cannot be read by me or anyone else. Backup and restore is a single JSON file you can write anywhere you like, and a restore always takes a rescue snapshot of what it is about to replace before it does anything.

Optional network features exist and are opt-in: you can subscribe to a Google Calendar so events appear alongside your tasks. That is a deliberate exception, and it is a read of a calendar you already publish — nothing goes the other way.

Who should choose a local-first app?

Choose local-first if you work mostly at one machine, if you write things you would rather not have on someone else's server, and if you would like the tool you learn this year to still be there in five.

Do not choose it if you move between machines constantly, if capture on a phone is central to how you think, or if you would rather someone else be responsible for your backups. Those are real requirements and cloud apps meet them properly.

If the first description fits, Cyanote is a $10 one-time purchase with no subscription behind it — I wrote about why it exists in I replaced five subscriptions with one $10 app, and about the routine I use to keep a week in order in the weekly review, in 20 minutes.

The reason is not discipline. It is that the version people are taught takes ninety minutes, requires you to be calm and unhurried, and asks you to face every loose end in your life at once. That is a wonderful thing to do occasionally and an impossible thing to do weekly.

What follows is the short version. Twenty minutes, four passes, a timer running the whole way. It is deliberately less thorough than the full ritual, and it is the one that survives contact with an ordinary Friday.

Why twenty minutes is the point

Two things go wrong with the long review.

It gets scheduled at a time when you are tired, because ninety minutes only fits at the end of the week, which is when you have least left. And it is open-ended, so it expands: you start reviewing tasks and finish reorganising your entire folder structure at 7pm on a Friday, feeling productive and having decided nothing.

A timer fixes both. Twenty minutes fits in the gap before a meeting. And a hard stop forces the review to do the thing it is for — deciding — rather than the thing that feels like it — tidying.

The bar is not "my system is perfect". The bar is "I know what is true and I know what I am doing on Monday."

The four passes

Set a timer for each one. When it goes off, move on even if you are not finished, because unfinished is the normal state and the next review will catch it.

1. Clear — 5 minutes

Empty every place things land, without doing any of the work you find.

• Your inbox, down to whatever counts as empty for you. Reply only to anything under two minutes; everything else becomes a task and gets archived.
• The notes app you scribble into during meetings. Every scrap either becomes a task, gets filed into a real note, or gets deleted. Most of them get deleted, and that is the point.
• Physical: the pile on the desk, the receipts in your bag, the notebook.
• Your camera roll, if you photograph whiteboards and posters. Half a weekly review's worth of loose ends lives there.

The rule that makes this pass work: capture, do not act. The moment you start actually doing one of the things you find, the five minutes are gone and you have reviewed nothing. Write it down. Move on.

2. Read — 5 minutes

Now look at the week that just happened, honestly.

• Last week's calendar, day by day. Not for nostalgia — for the meetings that produced a commitment you never wrote down. There is almost always one.
• Anything you marked done. Read it. This sounds sentimental and is not; it is calibration data for how much you can actually get through in a week, which is nearly always less than you plan for.
• Anything that was due and is not done. Do not fix it yet. Just notice it.

This is the pass people skip, and skipping it is why plans stay unrealistic. You cannot plan a week accurately if you never look at what happened to the last one.

3. Decide — 7 minutes

The longest pass, and the only one that matters. Go through everything outstanding and give each item one of four verdicts:

1. Do it this week. It gets a date, not just a tick box. A task with no date is a wish.
2. Do it later. It goes on a someday list you genuinely never look at except in this pass.
3. Delegate it. Write down who and when you will chase.
4. Drop it. Delete it, without ceremony.

The fourth verdict is the one that keeps the system alive. If nothing was dropped, you were not deciding, you were re-reading. Aim to delete something every single week. An item you have carried forward four weeks running is not a task; it is a decision you keep declining to make, and the honest move is either to schedule it now or to admit it is never happening.

4. Set — 3 minutes

Pick the shape of the week ahead.

• Name three outcomes for the week. Not thirty. Three. Written as things that will be true by Friday, not as activities: "the pricing page is live", not "work on pricing page".
• Put them in the calendar as actual blocks of time. An outcome without a slot is competing with everything else in your week and will lose.
• Look at what is already scheduled. If Wednesday has six hours of meetings, your three outcomes are not landing on Wednesday, and knowing that on Friday is worth more than discovering it on Wednesday morning.

Then stop. The timer went off. You are done.

The three mistakes

Doing the work during the review. It feels productive and it destroys the review. The review is for deciding what the work is. Keep a scratch list of the small things you are tempted to do, and do them after the timer.

Reviewing everything. Every project, every note, every reference folder. That is a quarterly job, not a weekly one. The weekly review only touches things that are live.

Missing one and quitting. You will miss weeks. A review done every second week is worth roughly ten times one done never. There is no streak to protect and nothing to catch up on — the next review just has a slightly fuller inbox.

The checklist, as one block

CLEAR (5 min)
  [ ] email inbox to zero-ish
  [ ] meeting notes / scratch pad emptied
  [ ] desk, bag, notebook
  [ ] camera roll
CAPTURE ONLY — do not do the work

READ (5 min)
  [ ] last week's calendar, day by day
  [ ] what got done
  [ ] what was due and did not

DECIDE (7 min)
  [ ] every open item: do / later / delegate / drop
  [ ] anything this-week gets a date
  [ ] delete at least one thing

SET (3 min)
  [ ] three outcomes for the week
  [ ] each one blocked in the calendar
  [ ] sanity-check against what is already booked

Copy it wherever you keep things. It does not matter where, as long as it is somewhere you will meet it again on Friday.

Doing it in Cyanote

I built this into the app I use, because a checklist you have to rebuild every week does not survive either.

Cyanote ships a Weekly review note template — it opens dated, with sections for Wins, Didn't get to, Lessons and Next week, so the Read and Set passes have somewhere to land. The Decide pass happens in the task list itself, where due dates and priorities live. And because tasks, calendar and notes are the same data rather than three synced copies, "what was due and did not get done" is something you look at rather than something you reconstruct.

If you prefer the timer to run itself, the four passes also work as a routine: a timed checklist that moves you along, which is the version I use, because I cannot be trusted to leave the Decide pass after seven minutes on my own.

None of that is necessary. The method is the method; a pen and a Friday afternoon will do. But if you are already looking for one place to keep the week, Cyanote is a $10 one-time purchase that runs entirely on your own Mac — I wrote about why it exists at all in I replaced five subscriptions with one $10 app.

Start with a bad one

Your first weekly review will be poor. The inbox will take fifteen minutes on its own, you will not get to the Set pass, and you will finish it feeling like it did not work.

Do it anyway, and then do the next one. By the third or fourth, Clear takes four minutes because there is less to clear, Read is quick because you remember the week, and the whole thing lands inside twenty minutes with room to spare. The review gets shorter precisely because you keep doing it, which is a rare and pleasant property in a habit.

I had gone looking for a single charge I did not recognise. What I found instead was a small, quiet stack of them: Notion for notes, Todoist for tasks, Fantastical for the calendar, Streaks for habits, and Paste for the clipboard. None of them was expensive. Two were under five dollars a month. That is exactly why I had never looked at them together.

Added up, they came to roughly $260 a year. For software I had already decided I wanted, years ago, and had been re-buying every month since without ever making the decision again.

Written out, the stack was this:

Five line items, about $260 a year between them, against $10 once. The money is the least interesting column, though — the next section is about the other one.

The bit that annoyed me was not the money

$260 is a real number but it is not a crisis. What actually bothered me was what I got for it.

A Tuesday looked like this. A thought arrives during a meeting, so it goes in Notion. It turns out to have a deadline, so a task goes in Todoist. The deadline is a Thursday, so I put a block in Fantastical. Later I want the meeting link I had copied twenty minutes earlier, so I open Paste. That evening Streaks asks whether I did the thing I said I would do daily, and I have no idea, because the evidence is spread across four other apps.

Five apps, five windows, five search boxes. Nothing was lost inside any one of them. Things were lost between them — in the seams, where the note about the project and the task for the project and the hour set aside for the project all existed, separately, and none of them knew about the others.

Every one of those apps was well made — Fantastical in particular is better at calendars than anything I have built or will build. That is the strange part. The failure was not in the software; it was in the shape of the arrangement. Five good apps do not add up to one good system, because the connective tissue is you, doing it by hand, several times a day, forever.

Two things I noticed about how they were priced

The first: I had never re-decided. A subscription is a decision you make once and then stop making. The bank makes it for you every month after that. I had chosen a habit tracker in 2022 based on what I needed in 2022, and I was still paying for that choice three years later, having never once asked whether it was still true.

The second is subtler, and it took me longer to see. When the money arrives monthly whether or not anything ships, the pressure on the software changes. It has to keep looking like it is worth the recurring charge. So features arrive — a team space, an AI assistant, an integrations directory, a web clipper — and the app gets bigger and slower and a little further from the thing you originally opened it for.

I do not think anyone is being cynical. It is just what the shape of the business rewards. But my notes app took four seconds to open a note, and I was paying every month for the privilege.

What I actually needed

So I wrote it down, honestly, rather than aspirationally. Not the features I might one day want — the ones I had actually used in the previous month:

• somewhere to write things down that opened instantly
• a list of what is due, with dates and priorities
• a calendar showing what is due next to what is scheduled
• a light way to track a handful of daily habits
• clipboard history, because I copy things and then need them again ten minutes later

That is a modest list. It is nowhere near the union of what those five apps offered. It is close to the intersection of what I used.

The gap between those two things — everything the apps could do, and the small part I actually touched — is roughly the whole story of why productivity software feels heavy.

So I built it

Cyanote is what came out. Notes, to-dos and a board, a calendar, habits, routines and a Pomodoro timer, and a system-wide clipboard manager, in one window, with one search box that looks across all of it.

The unification is not decorative. A task with a due date shows up in the calendar because it is the same task, not a copy synced across a boundary. A note can link to another note, and the note being linked to says so. When you finish a focus session against a task, the app can tell you later where the day actually went. None of that is clever engineering. It is just what stops being hard once the data is not living in five separate accounts.

It costs $10. Once. There is no subscription, no account and no upsell later. A new install asks once for the licence key from your purchase email; there is nothing to sign in to, and the key is not checked again after that. Updates are free for as long as the app exists — the changelog is the whole record of what that has meant so far.

The honest economics of $10, once

I want to be straight about this, because "pay once" is often sold as pure virtue and it is really a trade.

What you get: no recurring charge, and an app with no structural reason to grow features you did not ask for. My income does not depend on this month looking busy. It depends on the app being good enough that someone recommends it. Those pressures point in a much better direction.

What I give up: predictable revenue. That means Cyanote will never have a large team, a support desk with shift rotas, or a five-year roadmap underwritten by investors. It is one person, shipping steadily. If you need enterprise SSO and a service-level agreement, this is honestly not the software for you, and I would rather say so on a blog post than in a refund email.

What you give up, specifically

There are three real costs and I would rather you know them now.

No sync between machines. Your data lives on your Mac and stays there. Two Macs means two separate sets of notes. This follows directly from the local-first design and I have written about the whole trade in what local-first actually means for your notes — it is a genuine cost, not a feature in disguise.

No mobile app. If capturing a thought on your phone at a bus stop is central to how you work, Cyanote covers the desk half of your life and something else covers the other half.

No collaboration. No shared documents, no comments, no team spaces. This is a tool for one person's own thinking.

Backups are yours. With no server, nobody is quietly keeping a copy for you. Cyanote exports everything to a single JSON file and Time Machine covers the rest, but the responsibility moved to your side of the line.

Was it worth it?

For me, obviously — I have been using it every day for a year and I no longer pay $260 for the privilege of copying things between windows.

The more useful answer is the general one. Most people do not need five productivity subscriptions. They need one place that opens fast, holds the week, and does not ask anything of them again. If that is you, the audit is worth doing even if you never install anything I made: open your bank statement, find every recurring software charge under ten dollars, and ask which ones you would buy again today.

You will cancel at least one. Possibly five.

If you want somewhere for it all to land afterwards, Cyanote is $10 and that is the last time it asks you for money. If you want to see the routine I use to keep a week from drifting, that is the weekly review, in 20 minutes.

Two of the five have pages of their own, weighed properly rather than in passing: Notion, which is free for one person and so is not really a money argument at all, and Paste, which is the better clipboard manager.