Building in Public with Obsidian as a Second Brain

Two Jobs, One Brain

I run a direct-to-consumer seafood company and I build software tools for the fishing industry. These sound like separate jobs, but in practice they feed each other constantly. A conversation with a fisherman about dock pricing leads to a feature idea for the cost calculator. A regulatory change at the North Pacific Fishery Management Council affects both our sourcing strategy and the data models in our traceability system. A customer complaint about packaging becomes a note on cold-chain logistics that eventually shapes a blog post.

The problem is that these connections happen in my head, and my head is not a reliable storage medium. For two years I used a combination of Apple Notes, Google Docs, scattered text files, and the worst knowledge management system ever invented: remembering things. Important insights fell through the cracks. I would have the same realization twice, three months apart, because I never wrote it down properly the first time.

Obsidian fixed this. Not because it is the best note-taking app — that debate is endless and pointless — but because its core design principle matches how my work actually functions: everything is connected to everything else.

The Vault Structure

My Obsidian vault is organized by function, not by topic. The top-level folders are:

• Daily/ — One note per day, auto-created from a template
• Projects/ — Active projects with status, next actions, and linked references
• People/ — Notes on fishermen, buyers, regulators, collaborators
• Policy/ — Fisheries regulations, council meeting notes, public comment drafts
• Technical/ — Architecture decisions, code patterns, API documentation
• Business/ — Financial models, pricing strategy, market analysis
• Content/ — Blog drafts, social media ideas, newsletter outlines

The folders provide loose organization, but the real structure comes from links. Every note links to related notes across folders. A daily note about a council meeting links to the relevant policy note, the fisherman who testified, the project that would be affected, and the technical spec that needs updating.

Daily Notes as the Entry Point

The daily note is where everything starts. Every morning, the template generates a note with sections for priorities, meetings, observations, and end-of-day review. Throughout the day, I dump everything into it: a phone call summary, a code snippet that solved a problem, a price quote from a supplier, a thought about a blog post.

The discipline is not in organizing these entries — it is in linking them. When I write about a conversation with a fisherman, I link to their People note and any relevant Project notes. When I jot down a technical idea, I link to the Technical spec it relates to. This takes five extra seconds per entry and creates a web of connections that compounds over months.

At the end of the day, I spend ten minutes reviewing the daily note. Anything that represents a decision, a commitment, or a significant insight gets extracted into its own note or added to an existing one. The daily note becomes a timestamped record of what happened. The linked notes become the living knowledge base.

The Graph View Parallel

Obsidian has a graph view that visualizes your notes as nodes connected by links. The first time I looked at mine after three months of consistent use, I saw something that looked remarkably like the knowledge graph on my website.

That was not a coincidence. The knowledge graph on ryan-h.org was inspired directly by the Obsidian graph. Both represent the same idea: my work does not exist in silos. Seafood, technology, policy, and sustainability are not separate interests — they are facets of one integrated practice. The graph makes that visible.

The Obsidian graph also reveals gaps. If a project note has no links to policy notes, that is a signal that I have not thought through the regulatory implications. If a technical spec has no links to business notes, it might mean I am building something without a clear business case. The structure of the graph is diagnostic.

Plugins That Matter

I keep my plugin list short. Every plugin adds complexity and potential for breakage. These are the ones that earned their place:

Templater. The daily note template, project template, and people template all use Templater for dynamic content — dates, cursors, and conditional sections. It saves a few minutes per day and ensures consistency across hundreds of notes.

Dataview. This turns Obsidian into a queryable database. I use it to generate project dashboards — tables of all active projects with their status, last-updated date, and next action. I also use it to surface stale notes that have not been touched in sixty days, which usually means something fell through the cracks.

Tasks. Simple task management that works across notes. When I create a task in a daily note, it shows up in a global task list. When I check it off, it is marked complete in the original note. Nothing fancy. It works.

Git. Automatic version control for the vault. Every change is committed and pushed to a private repository. This is my backup strategy and my history. I can see exactly what I was thinking and writing on any given day, going back to when I started the vault.

Connecting Policy to Code

The most valuable pattern in my vault is the chain from policy to implementation. Here is a real example:

1. A daily note captures that the NPFMC is considering changes to halibut bycatch limits in the Gulf of Alaska.
2. That links to a policy note tracking the proposal, its timeline, and potential impacts.
3. The policy note links to a business note analyzing how reduced bycatch limits could affect halibut supply and pricing.
4. The business note links to a project note for updating the Fish Cost Calculator to model the new pricing scenarios.
5. The project note links to a technical spec for the calculator's pricing module.

Five notes across five folders, all connected. When the council makes its decision, I can trace the implications from regulation to revenue to code in seconds. Without Obsidian, those connections exist only in my memory, and memory is lossy.

Building in Public

I publish selectively from my vault. Blog posts start as Content notes, get drafted and revised with links to supporting research, and eventually get exported as MDX files for the website. The knowledge graph on the site is a curated view of the graph in Obsidian — same structure, public-facing subset.

Building in public does not mean sharing everything. It means showing enough of your process that people can see the thinking behind the output. The Obsidian vault is the full picture. The website is the edited version. The relationship between them is intentional.

The Compound Effect

The vault has been running for about fourteen months now. The compound effect is real. Early notes were sparse and poorly linked. Recent notes are dense with connections because there is more to connect to. Searching for any topic returns a rich web of related notes, past decisions, and historical context.

When I sit down to write a blog post, the research is already done — it is scattered across months of daily notes and linked references. When I start a new project, the relevant policy, business, and technical context is already in the vault waiting to be surfaced. When someone asks me a question about our operations, I can find the answer in seconds instead of reconstructing it from memory.

The tool is not magic. The discipline of writing daily, linking consistently, and reviewing regularly is what makes it work. Obsidian is just the medium. But it is a very good medium, and it has changed how I think about the relationship between my two jobs — which, it turns out, was always one job with two expressions.