Why second Notions fail
Your work already has places where the truth lives. Tickets, pull requests, project docs, client folders. A personal wiki built alongside them starts as a good idea and turns into a shelf of outlines nobody opens again, including the person who wrote them.
The failure is not laziness. It is structural, and it happens in three predictable ways.
It competes with the real home. You paste a paragraph into your private notes "for later." The ticket description stops being updated. Now two versions exist, and the stale one is the one you can find fastest.
It creates a retrieval question that did not exist before. Was the billing decision in the ticket, the meeting note, the personal wiki, or a chat thread? Every extra home multiplies that question. A note system earns its place by reducing the number of places worth searching, not by adding attractive ones.
It absorbs the best hour of the day. Designing databases, properties, and tags feels like progress and produces nothing. Setup work is the most convincing form of avoidance available to people who enjoy organising things.
A blunt test: if a note is not attached to a ticket, doc, or PR you will open again this week, it is clutter.
Three homes, and nothing else
1. Scratchpad, for today only
Links, half sentences, commands you ran, the staging URL, a permalink you will need in an hour. It lives in one place: quick notes on your shutdown note, or a single daily note. Throwaway by design, cleared weekly.
2. Decisions, next to the project
Only the ones that would be expensive to rediscover. "Monthly billing only for launch." "API v1 stays until September." "Refund copy approved as written."
These go where the work is. A Decision heading in the project doc, a line in the architecture record, or a comment on the issue beats a personal knowledge base every time, because the next person to need it will not have access to yours.
3. Next actions, always
One clear next action per active thread, written where you will see it when you sit down. This is the layer that makes the other two optional (why remote workers need a clear next action).
The filing rule underneath all three is proximity. Put the note where the work it affects already lives:
- A decision about code goes in the issue, the pull request, or the architecture record
- A client approval goes in the shared folder or the project thread
- A meeting action goes in the task system with an owner and a date
- A temporary URL or command stays in today's scratchpad and dies there
Link rather than copy when another system owns the truth, and add one sentence saying why the link matters. Refund copy approved by the client: [proposal section 4] is more useful than four pasted paragraphs that will quietly go out of date while still looking authoritative.
Capture during a focus block is a separate skill with different rules. Mid-block, the goal is speed: one scratch line with the next physical step, not a polished paragraph. Filing happens on the break.
Ten minutes a week, and no longer
Once a week, read the scratchpad from top to bottom. Every surviving line gets exactly one of four outcomes:
- Delete it, because the work is done
- Move it to the project's durable home, if it is a real decision
- Turn it into a clear next action, if it is an unfinished thought
- Keep it one more week, with a reason
Ten minutes is the limit, and it is a diagnostic as much as a deadline. If the review needs an afternoon, the fix is capturing less, not reviewing harder.
Do not spend the review making headings prettier; the goal is removing ambiguity before Monday. And look hard at copied status information. If a ticket has moved on, update the ticket and delete your copy. Private notes should never quietly outrank the place your colleagues actually read.
The same discipline is what makes handoffs short. Notes that stayed close to the work are already most of a handoff (leaving work someone else can continue), and the end-of-day write-up becomes a summary rather than an archaeology project (end-of-day status update).
When to refuse a new tool
New note tools are easy to justify and hard to abandon. Before adopting one, name the retrieval problem it solves. Real ones exist: onboarding people, passing an audit, maintaining a service for years, coordinating decisions across teams that do not talk daily.
If the answer is closer to "it would be nice to have everything in one place," refuse it. That is a feeling, not a requirement, and the tool will not resolve it.
When a bigger system genuinely is justified, it needs the things that keep documentation alive: named owners, review dates, and links from the places people already open. Documentation with none of those is a graveyard with better typography. Two limits hold regardless of tooling: personal notes stay temporary, and they never hold credentials, contract terms, or customer data that belongs in a controlled system.
The working version of all this is smaller than it sounds. A scratchpad you delete, decisions filed where the project can see them, and one next action per thread. That is a note system. Everything else is a product you have volunteered to maintain. ## Example: notes that help Monday-you
Example: Friday you stop mid-refactor with "TODO fix tests." Monday you spend forty minutes finding which tests and which branch.
Better park note in the ticket: "Branch feat/tax-line, failing CheckoutTest::eur_vat, suspect rounding in TaxCalculator.php line 112, next: dump $order->lines before apply."
That note lives where the work lives. A personal notebook duplicate is optional, not required.
Chat is not a note system
Threads scroll away. Decisions buried in Slack become folklore. When a chat resolves something, paste the conclusion into the ticket or doc in three lines.
Turn a chat thread into a durable document is the team habit; this article is the solo version.
Notes should answer pick-up questions
Before you stop, ask what a stranger would need: where, how to verify, what not to redo. Same bar as leaving work someone else can continue.
Search beats taxonomy
Personal wikis tempt elaborate tag systems. Tickets and repos already have search. A decision in the issue title or first comment is findable; a decision on page seventeen of your notebook is not.
Example: Title the ticket "Decision: monthly billing only at launch" instead of adding a Notion property called BillingPhase.
Meeting notes that die in chat
If a call resolves something, three lines in the ticket beat five pages in a private doc. Who decided, what option, what changes Monday.
When the meeting was the whole point, still paste conclusions where the work lives. Attendees forget; search does not.
Mobile capture without a second app
Voice memo or one-line note to self is fine for scratchpad tier. Sync it into the ticket at shutdown, not into a parallel system you will never organize.
The weekly ten-minute review is where mobile crumbs get promoted or deleted.
Security and client data
Work notes are not a vault. Credentials, personal data, and unsigned contract terms belong in approved systems. Scratchpads get shared screens and accidental forwards.
If you cannot paste it in the client folder, do not paste it in personal notes.
When the team wants a wiki anyway
Sometimes compliance or onboarding truly needs a hub. Make it small: five pages max, named owners, review dates, links out to tickets for detail.
The hub points to truth; it does not duplicate truth. Everything else stays scratchpad or ticket.
Notes are infrastructure. Keep them boring, local to the work, and small enough that Monday-you actually reads them.
Scenario: three clients, one notebook
Example: You juggle three client codebases. A second Notion workspace becomes a fourth job: tagging, syncing, searching across databases.
Instead, keep one note file per client repo in the repo or client folder: env quirks, deploy commands, approver names, last staging URL. Open the repo, open the note. No cross-client search theater.
When the engagement ends, archive the folder. The note travels with the work history instead of living forever in a personal wiki graveyard.
Myth: one tool will finally organize everything
Organization fantasies sell software. Work notes succeed when they are small, proximate, and deleted when the ticket closes.
If a note has not been opened in thirty days, it probably belongs in the ticket archive or the trash. Promotion to wiki is rare and deliberate.
Mobile capture without a second brain
Phone notes for work should funnel to one inbox doc you clear weekly. Each line links or names a ticket when you process it. Unprocessed phone notes become anxiety, not memory.
Operating rule: write scratch next to the work, promote only what earns a home, delete or archive when the ticket closes, and clear the phone inbox in one ten-minute weekly pass. No second Notion.