Notion as a Personal Operating System

Notion is a single-app workspace for notes, structured data, project tracking, calendar, and a writing surface. Everything in it is built from two primitives – blocks (text, image, embed, code, toggle, etc.) and databases (a block whose rows are themselves pages, queryable and viewable as tables, boards, calendars, timelines, or galleries). Once you internalize those two ideas, the rest of the product is variations on combining them.

This article is a practical playbook for using Notion across six concrete areas: kitesurfing and exercise, sleep, building WorkingAgents, marketing WorkingAgents, managing a personal and professional network, and running a content pipeline across LinkedIn, Medium, and YouTube blog posts. It is not a feature tour.

Why Notion specifically

There are sharper tools for any single job. A spreadsheet beats Notion for heavy math. Linear beats it for engineering ticket flow. Things or Todoist beats it for raw GTD speed. Obsidian beats it for offline-first knowledge graphs.

Notion’s advantage is that the same workspace holds all of them with one syntax, one URL space, and one search bar. When your bottleneck is coordination between notes, tasks, contacts, drafts, and calendar – not raw speed in any one of them – Notion is the tool that removes the friction.

The downsides are real and worth naming up front:

• It is online-first. Offline works for a single page but unreliable for cross-database queries.
• Mobile is functional but slower than native iOS/Android note apps.
• Performance degrades when a database crosses ~10,000 rows or a page has hundreds of embedded blocks.
• Vendor lock-in is real. Export options exist (Markdown, CSV, HTML) but lose the database relationships.

If those trade-offs are acceptable, the rest of this article is the playbook.

The mental model: one database for each repeating thing

Everything that repeats should be a database, not a page. The pattern is the same regardless of subject:

• One database = one kind of thing (a workout, a night of sleep, a blog post, a contact, a feature ticket).
• Each row = one instance of that thing.
• Properties on the row = the metadata you’d want to filter, sort, or roll up.
• The row’s body = the freeform notes specific to that instance.

The win is that the same database renders different ways depending on what you need: a table for editing, a calendar for “when did this happen,” a board for “what state is this in,” a timeline for “how long did this run.”

The mistake to avoid: making every database too clever before you’ve used it. Start with three or four properties. Add more once you find yourself filtering on something three times in a week.

Daily areas

Exercise: kitesurfing and conditioning

One database, Sessions. Properties worth having:

• Date (date) – the obvious one. Powers the calendar view.
• Type (select) – Kite, Run, Strength, Mobility, Rest.
• Duration (number, minutes).
• Conditions (text or multi-select) – wind in knots, water state, gear used. Only relevant for kite sessions; leave blank otherwise.
• Rating (1-5) – subjective “was that a good session” number. The data is in the trend, not any single row.
• Notes (rich text) – in the page body: what worked, what didn’t, what to fix next time.

Views to add immediately:

• Table view, sorted by Date descending. Default for logging.
• Calendar view. Useful for spotting consistency gaps.
• Board view by Type. Useful for seeing balance (are you skipping mobility?).

What Notion does not do: read your heart rate, capture GPS tracks, or pull from Strava/Garmin natively. You can paste a screenshot from your watch into a session row, or use the Web Clipper to grab a Strava URL, but the auto-import path is via Zapier or Make as a middleman. For most kitesurfers, manual logging in 30 seconds after the session is fine.

Sleep

A second database, Sleep. Three properties suffice to start:

• Date (date) – when you woke up, not when you went to bed (less ambiguous).
• Hours (number).
• Quality (1-5).

Optional add-ons once you’ve used it for a month:

• Caffeine cutoff (time).
• Screen cutoff (time).
• Wind-down (multi-select: read, stretched, hot shower, none).

Notion’s value here is not the logging itself – there are better sleep apps. The value is correlation. With Sessions and Sleep both as databases, you can build a third page that pulls both in side-by-side and ask: “On days I kited 3+ hours, what’s my sleep look like that night?” or “After a strength session, do I sleep better than after a run?” The answers reveal what works for your body.

WorkingAgents development

This is where Notion competes most directly with engineering-specific tools. Two databases will get you 80% of the way:

• Features (board view, columns: Backlog / Designing / Building / Testing / Shipped). One row per feature. Properties for priority, customer, target ship date, and a relation to a contact (who asked for it).
• Bugs (table or board). One row per bug. Properties for severity, reported-by, status, and a relation to the feature it affects.

Plus a Specs page tree, not a database. Each non-trivial feature gets a spec page linked from its Features row. The spec is freeform – problem, approach, open questions, decisions. The Features row says what and when; the spec says how and why.

The reason this is worth doing in Notion rather than a “real” ticket tracker:

• You already have your contacts, your sales notes, and your prospect conversations in the same workspace. A Features row can relate directly to the Contact who asked for it. That relationship is invisible in Linear.
• The same page can mix structured fields (priority, status) with long-form thinking (why are we building this).
• One workspace search hits specs and ticket bodies together.

If WA grows past ~3 engineers, this stops working and you graduate to Linear. Until then, it’s fine.

WorkingAgents marketing

A third database, Marketing. Each row is one outreach surface: a blog post, a LinkedIn post, a Medium article, a YouTube video, a podcast appearance, a conference talk. Properties:

• Channel (select: LinkedIn, Medium, YouTube, Blog, Podcast, Talk).
• Status (Idea / Draft / Ready / Scheduled / Published).
• Publish date (date).
• Topic / Audience (multi-select).
• Reach (number, manually updated weekly with the platform’s analytics).
• Linked feature (relation to Features database – so the marketing piece can be tied to the thing it’s promoting).

The point isn’t to track marketing metrics inside Notion to compete with HubSpot. The point is to have a single Kanban view of “what am I shipping to the world this week” alongside “what am I building.” When marketing and product live in separate apps, marketing always lags. When they live in the same workspace, marketing posts are queued the same day the feature ships.

Network and contacts

Contacts database. Properties:

• Name.
• Company / Role.
• Relationship (select: Customer, Prospect, Investor, Engineer Network, Personal, Family).
• Last touch (date).
• Cadence (select: weekly, monthly, quarterly, annual) – how often you’d like to talk to this person.
• Next touch due (formula: Last touch + cadence interval). Notion’s formula engine handles this.
• Notes (in the page body: meeting notes, context, kid’s names, what they’re working on).

Views:

• Filtered table: “Due to reach out” (next-touch < today).
• Board by Relationship.

Every 1:1 conversation becomes a date-stamped block in that person’s page. After three years you have a private CRM that no SaaS pricing change can take away from you. The mechanics aren’t sophisticated. The discipline is what compounds.

Content pipeline

A fourth database, Drafts. One row per piece of writing. Properties:

• Title (or working title).
• Channel (select, same options as Marketing).
• Status (Idea / Researching / Drafting / Editing / Ready / Published).
• Word target and Word count (number).
• Linked Marketing row (relation – so each Draft is tied to the surface it ships on).

The page body is the draft itself. Notion is genuinely good as a writing surface – it has decent typography, hits Markdown without trying, supports embedded images and code blocks cleanly, and the “/“ command for inserting blocks is fast once muscle memory kicks in.

What it is not good for: heavy collaborative editing with live cursors (Google Docs wins there) and final-layout formatting (you’ll move to LinkedIn’s editor, Medium’s editor, or your blog’s CMS for the publish step). Notion is the drafting layer, not the final publish layer.

The crucial habit: every published piece comes back as a row in Marketing with its publish URL and reach metric. That closes the loop between “I wrote this” and “did anyone read it.”

Notion AI: where it actually helps

Notion AI is a paid add-on. Honest assessment of where it earns its cost in your specific use cases:

• Summarizing meeting notes – you paste a 30-minute transcript, ask for a one-paragraph summary plus an action-item list. Reliable.
• Drafting first-pass content from a few bullet points. Useful for breaking blank-page paralysis. Always rewrite. The first draft sounds like a marketing intern.
• Translating between formats – “rewrite this blog post as a LinkedIn post” or “turn this into a 90-second video script.” Reasonable starting point, again always rewrite.
• Search-with-context across your workspace. When you have hundreds of pages, “where did I write about the kitesurfing trip to Mui Ne?” is faster than scrolling.

Where it does not earn the cost:

• Anything requiring deep technical accuracy. You’ll spend longer fact-checking than you would have spent writing from scratch.
• Generating content that has a distinctive voice. The output is correct, bland, and generic.
• Replacing a CRM, a calendar, or a project manager. It’s a writing assistant, not an agent.

The decision rule: if you write 5+ pieces a week and spend 20 minutes per piece on “first draft from notes,” it pays for itself in time. If you write 1-2 thoughtful pieces a month, you don’t need it – write them yourself.

Notion Calendar

Notion ships a separate calendar app (originally Cron, now Notion Calendar) that hooks into Google Calendar. The integration with the rest of Notion is that you can drop a Notion link onto a calendar event, and Notion database rows with a date property can be surfaced as events.

Practical use: keep your time blocks in Notion Calendar, link each block to the relevant Notion page (a session you’re planning, a meeting agenda, a writing session for a specific Draft). The calendar becomes the “what” – where you focus on every block. Notion is the “how” – the actual material you work on during that block.

The Apple/Outlook user can skip this and stay on the calendar they already have. There is no critical Notion functionality locked behind the Notion Calendar app.

Templates worth starting from

You do not have to build every database from scratch. Notion has a public template gallery (and a community gallery with thousands more) covering:

• Personal CRM (almost exactly the Contacts pattern above).
• Habit tracker (workable for sleep + exercise; you can split it into two later).
• Content calendar.
• Project management (overkill for a one-person team, useful at WA’s stage).
• Reading list, meal planning, finances, travel logs.

Pick the one closest to what you described, duplicate it, then strip out every property you won’t use in the first week. The default templates are over-engineered. Yours should be smaller until you outgrow it.

Limits and gotchas

• Database relations can get tangled. If a Feature has a relation to a Contact who has a relation to a Marketing row that has a relation back to the Feature, you’ve built a graph. That’s fine until you want to refactor one of the databases and discover three pages break. Refactor slowly.
• Notion does not have proper formulas across databases. A formula on one row can use properties of that row’s relations, but you cannot easily compute “average rating of all Sessions in the same week as this Sleep row.” The workaround is to add a Week property on both sides and filter manually.
• Sync conflicts on mobile are rare but real. If you edit the same page on phone and laptop while offline, one wins. Don’t write irreplaceable content (the first draft of the only copy of an article) without committing to one device.
• Pricing scales with collaborators, not pages. Solo use is cheap (Free or Plus). When you invite a teammate to edit, you’re on Business. For WorkingAgents partner work, plan for that.
• Export is best-effort. Markdown export loses databases, embeds, and relations. If you might leave Notion in 2-3 years, periodically export a CSV of your most-precious databases (Contacts, Sleep, Sessions) so you have a portable archive.

A minimal week-one setup

If this whole article feels like too much to set up at once, the smallest useful version:

1. Create one workspace.
2. Build four databases: Sessions, Sleep, Contacts, Drafts.
3. Start logging into them daily. Five minutes a day, not an hour on Sunday.
4. After two weeks, look at the data. Add views and properties where you find yourself wishing for them.
5. After six weeks, add Features and Marketing for WorkingAgents work.
6. After three months, decide whether Notion AI is worth turning on.

The trap with Notion is spending a Saturday designing the perfect workspace and never using it. The discipline is the opposite: build the smallest scaffolding that captures the data, then let your actual usage tell you what to add. Most powerful Notion setups in the wild grew over a year. None of them were architected upfront.