TL;DR: Obsidian plus Claude Code is the best solo second brain for FDE work we've seen, and this article describes the setup honestly. It breaks in four places once a team exists: sharing (all collaborators get the vault owner's permissions), the second editor (sync-merge conflicts), readers who aren't in Obsidian (sales, managers), and drift (nobody's job to reconcile). Knowledge workers already waste 5.3 hours every week waiting for or recreating knowledge. Teams that moved account state to a shared brain got 3 weeks shorter from kickoff to go-live at Spendesk.

The Obsidian second brain is the closest thing FDE work has to a folk tradition. A vault, a folder per account, Granola transcripts piped in, Claude Code reading and writing the markdown. The people running this setup are not tinkering for its own sake. They ship faster because of it, and when we talk to forward deployed engineers, it comes up unprompted more than any other stack.

So this isn't a takedown. Solo, the setup works, and we'll describe why before we describe anything else. The trouble starts at exactly the moment the trouble always starts: when a second person needs what's in your vault. A founding FDE at a vertical fintech put it to us without hedging: "the number one thing is I cannot share the Obsidian brain with other people."

What follows is the setup as it really is, the four places it breaks for teams, with Obsidian's own documentation on each, and what a team-grade version of the same workflow looks like.

The solo setup that actually works

Before the break points, the recipe. If you're a solo FDE and you stop reading after this section, you'll still be better off.

  • One vault, one folder per account. Every commitment, decision, and open question for a client lives in its folder. Daily notes act as the ledger of what happened when.
  • Pipe the transcripts in. Granola or your recorder of choice drops call transcripts into the account folder, so the raw record is next to your interpretation of it.
  • Let Claude Code read and write the vault. Point it at the markdown and it summarizes calls, drafts follow-ups, and answers "what did we tell them about the API migration" from your own notes.
  • Compact before you run out of context. Session learnings get written back to the vault as migration notes, so the next session starts warm.

Local-first, plain markdown, no vendor in the loop. Those are real properties and they're why people love it. Every one of them is also single-player by construction, which is where the four breaks come from. This is the personal-brain stack the shared context problem grows out of.

Break one: does sharing an Obsidian vault with a team work?

Obsidian Sync has a shared-vault feature, and its own documentation is candid about the limits. Per the collaboration docs, fine-grained permissions are not supported yet, and all collaborators receive the same permissions as the vault owner. Everyone you invite can edit, rename, or delete anything. The same page caps shared vaults at 20 collaborators.

For a personal knowledge base that's a reasonable trade. For the record of what was promised to a paying client, all-or-nothing write access to every note is a different proposition. There's no way to let sales read the commitments without also letting sales edit them. Most teams respond by not sharing the vault at all, which is how the brain stays personal.

Break two: the second editor

Suppose you share it anyway. The second FDE joins the account, opens the vault, and starts writing. Obsidian Sync offers no real-time editing, and concurrent changes are merged when the vault syncs. Two people in the same account note during the same afternoon produce a merge, and merged prose about account state is nobody's statement of the truth.

The deeper issue isn't the merge mechanics. It's ownership. In a solo vault, every sentence is yours, so you trust all of it. The moment there are two authors and no reconciliation step, you trust none of it fully. An FDE team lead at a roughly 50-person AI company described where this road ends: "I've set up, like, Obsidian, a Wiki, and Git […] That comes with now a maintenance cost." The build-vs-buy math on a shared context layer is mostly this cost, counted honestly.

Break three: the reader who isn't in Obsidian

Your manager doesn't have your vault. Sales doesn't have Obsidian. The engineer picking up a build has the repo, not your daily notes. The same fintech FDE who couldn't share the brain added the other half of the problem: the salespeople don't use Claude Code, so anything that lives behind your tooling might as well not exist for them.

Claude Code's own memory model doesn't rescue this. The docs are explicit that auto memory is machine-local, and files are not shared across machines or cloud environments. What your sessions learned about the account stays on your laptop, a limit we take apart in Claude Code memory for teams. And there's an open feature request asking Anthropic for a shared layer across Claude Code, Cowork, and Claude.ai Projects precisely because none exists. The result is that every reader outside your setup routes their questions through you. The 5.3 hours a week the 2018 Panopto research counts as waiting for or recreating knowledge is, on an FDE team, mostly this routing.

Break four: drift, or the vault versus reality

The quietest break. Notes describe the implementation as it was when you wrote them. The implementation moves on. An FDE at an insurance-claims platform described it from inside: "the obsidian kinda and what the real implementation represents start drifting apart."

Nothing flags this. Retrieval keeps working, in the sense that Claude Code keeps confidently answering from the vault. A practitioner analysis of RAG systems found that 60 percent of post-proof-of-concept failures come down to data freshness, not retrieval quality, and that a system can score well on standard metrics while returning information superseded for weeks. A vault has the same failure mode with fewer metrics.

Our own observation, from the teams we work with: a regular brain (Obsidian and the like) drifts somewhere between 500 and 1,000 facts. Below that, one person can hold the delta between notes and reality in their head. Above it, they can't, and nobody notices the moment it happens. We wrote up the mechanics in context drift in home-built brains.

Obsidian, shared vaults, and a project brain, compared

  • Who can read it. Spreadsheets + Slack: Everyone, in theory. Obsidian, solo vault: You. Obsidian shared vault (Sync): Up to 20 collaborators. Project brain (e.g. Tandem): Whole team, plus agents via Tandem MCP.
  • Permissions. Spreadsheets + Slack: Chaotic but familiar. Obsidian, solo vault: Yours alone. Obsidian shared vault (Sync): Same permissions as the owner for everyone. Project brain (e.g. Tandem): Configurable, multiplayer by design.
  • Concurrent editing. Spreadsheets + Slack: Slack threads fork instead. Obsidian, solo vault: Not needed. Obsidian shared vault (Sync): No real-time editing, merged at sync. Project brain (e.g. Tandem): Several people push to one brain.
  • Readers outside the tool. Spreadsheets + Slack: Yes, that's the appeal. Obsidian, solo vault: No. Obsidian shared vault (Sync): No. Project brain (e.g. Tandem): Claude chat, Slack, brief delivery anywhere.
  • Freshness. Spreadsheets + Slack: Stale between manual updates, varies by team. Obsidian, solo vault: As fresh as your discipline. Obsidian shared vault (Sync): Nobody's job to reconcile. Project brain (e.g. Tandem): Synced from calls, Slack, sessions, drift surfaced as risks.
  • Cost of upkeep. Spreadsheets + Slack: Hidden in everyone's time. Obsidian, solo vault: Yours, unquantified. Obsidian shared vault (Sync): Yours plus merge cleanup. Project brain (e.g. Tandem): Maintained by the product, you review.

Fair notes on the table. Spreadsheets plus Slack requires no adoption at all, which is a genuine strength no tool matches. Obsidian's local-first, plain-markdown model gives you portability and privacy nothing hosted matches, and for a solo practitioner those can outweigh every break above. A DIY brain on Notion or Airtable sits somewhere between the columns.

What the team-grade version keeps

The workflow you've built has the right instincts: capture everything, keep interpretation next to evidence, query it from where you work. A project brain keeps those instincts and changes the storage. In Tandem's account brain, facts are source-linked, several people push to one brain with configurable alerts, and the brain is edited through an AI chat interface rather than by hand-tending markdown. Claude Code stays in the loop, since sync pushes whatever you choose from a session, and the risk check reads the same memory back as a list of risks, each with an explanation, the reason, and sources.

The difference shows up in other people's mornings. At Spendesk, an engineer picks up any account and knows in five minutes what was promised and what's at risk, and in Mathilde Hamy's words, "Nobody maintains anything". At Aircall, the engineering side had lived the home-built version first. Senior engineer Paul Yi: "We tried to build that. It didn't hold." That story, including what held instead, is at how Aircall runs rollouts on a shared brain.

What stays manual

An honest accounting, because the vault people are rightly allergic to magic claims.

You still choose what enters the brain. Sync from a Claude Code session pushes what you select, and agent-proposed updates wait for human approval before they land in the record. Your reading of the client, the judgment call about whether a delay is a risk or a rhythm, doesn't transfer from any system, ours included. If you keep a personal vault for thinking, nothing about a team brain replaces it, and plenty of our users keep both. And migrating an existing vault is curation, not import. The durable facts move in a week or two of normal account work, the two hundred daily notes stay yours.

Keep the second brain, give the team one too

Obsidian earned its place in the FDE stack, and solo it may still be the right call. The four breaks are all one break seen from different sides: a brain built for one person answers to one person. Once a second FDE, a manager, or an engineer needs the account's state, the answer is a shared, source-linked memory they can query without you in the loop, which is what Tandem builds for FDE teams. See Tandem flag the risk on one of your live implementations in a demo.

FAQs

Can I share an Obsidian vault with my team for client work?

Technically yes, up to 20 people through Obsidian Sync. Practically, everyone gets the vault owner's full permissions, there's no real-time editing, and concurrent edits merge at sync. For client account state, where read access and write access need to differ and two people edit the same account, most teams find the limits disqualifying. Obsidian's docs state these limits themselves.

Do I have to give up Obsidian to get team memory?

No. The pattern we see work is vault for personal thinking, shared brain for account state. Claude Code can push chosen session outcomes to the team brain, and the vault stays your private working space. What changes is that commitments, decisions, and risks stop living only in your markdown.

How do I know when my vault has drifted?

Mostly you don't, which is the problem. The tell is behavioral: you start double-checking the vault's answers against Slack before repeating them to a client. In our experience that starts somewhere between 500 and 1,000 facts. A team brain surfaces drift as ranked risks with sources instead of waiting for you to notice.

Is this setup worth building at all if I'm the only FDE?

Yes, and we'd say so even though we sell the alternative. Solo, the Obsidian and Claude Code setup is fast, private, and yours. The time to reconsider is when the second FDE is hired, an engineer needs your context, or a manager starts asking for status, because retrofitting sharing onto a personal vault is the part that doesn't hold.

Key terms

Second brain: a personal knowledge system, in this context an Obsidian vault holding an FDE's account notes, transcripts, and decisions.

Shared context: the account knowledge a whole team and its agents can query. Team memory is the same idea. The personal second brain is its single-player predecessor.

Forward deployed engineer: a forward deployed engineer is an engineer who spends roughly half their time with customers understanding the problem and half building the solution for that specific customer.

Context drift: the growing gap between what a knowledge store says and what's currently true, dangerous because retrieval keeps working while the answers go stale.

Project brain: a reconciled, source-linked record of an account's state (promised, decided, at risk, next), maintained by a team rather than a person.

Tandem MCP: Tandem's MCP server, which lets Claude, Claude Code, or ChatGPT query the account brain, so the vault workflow's best habit (asking your notes from where you work) survives the move to team memory.