TL;DR: Build the shared context layer and you own a second product. Buy it and you own a vendor decision. The success data leans one way: purchased specialized AI tools succeed about 67% of the time, against roughly a third for internal builds. Aircall tried the build first, then bought, and now runs 3x rollouts per engineer. Build when control of the stack is the real requirement. Buy when the requirement is account context that stays current past the first few hundred facts.

Somewhere around the second or third forward deployed engineer, every deployment team has the same meeting. The personal setups work. One engineer keeps an Obsidian vault, another pipes call transcripts through Claude Code, and none of it is visible to anyone else. So someone proposes the obvious fix: a Supabase table, a custom save command, a weekend of work. We'll build our own shared context layer.

The proposal is rational. The team has engineers, and the first version genuinely takes a weekend. The problem arrives in months two through six, when the context layer turns out to be a product with users, pipelines, auth, and a data-quality backlog, and the person maintaining it is your most senior FDE. The shared context problem doesn't go away because you wrote code at it. It moves.

This article walks through the build patterns we keep meeting, where the months actually go, the point where home-built brains quietly fail, and the honest case for each side. The argument for buying comes from builders' own words, not vendor fear.

The builds we keep meeting

Three patterns cover most of what deployment teams construct in-house. All three work at first, which is exactly what makes them expensive.

The Supabase store with a save-and-compact command

The most common 2026 pattern: a Postgres store (usually Supabase), fed by a custom slash command in Claude Code that summarizes the session and writes the useful facts before compacting. It's a clever answer to a real gap, because session learnings otherwise die with the terminal. A head of FDEs at a workflow-automation platform showed us his version and said, "I actually called it, like, FTE operating system." He also admitted the build had been sitting neglected for months, stalled on multi-user Gmail auth, while the accounts kept moving. The pattern shows up so often that teams now name it, and we wrote about what an FDE operating system actually contains separately.

Transcripts into a vector database

The second pattern pushes every call transcript into a vector database (Turbopuffer, pgvector, take your pick) and puts retrieval on top. Day one is impressive. You ask about the Acme integration and get a relevant chunk back. The trouble is that retrieval quality was never the hard part. One practitioner's analysis of production RAG systems found that 60% of projects failing after proof-of-concept fail on data freshness, not retrieval. The store returns what was said in March. Nobody built the part that notices April contradicted it.

The Obsidian, Git, and wiki stack

The third pattern skips databases entirely: markdown vaults, a Git repo, sometimes a wiki on top. An FDE team lead at a ~50-person AI company described his: "I've set up, like, Obsidian, a Wiki, and Git [...] That comes with now a maintenance cost." Obsidian's own docs are candid about the collaboration ceiling, with no fine-grained permissions, no real-time editing, and conflicts merged at sync. We covered where the Obsidian second brain breaks for FDE teams in detail, and the short version is that it breaks at the second person.

Where do the months actually go?

The weekend estimate covers the schema and the save command. It never covers the three workstreams that follow, and those are where internal builds go to sit in the backlog.

One pipeline per source

Account context doesn't come from one place. It comes from calls, Slack threads, tickets, email, the CRM, and coding sessions. Every source needs its own ingestion pipeline, its own dedupe logic, and its own failure handling. An FDE at a vision-AI company, mid-build, told us: "the data pipelines, that multiuser stuff has been something that already kind of been a pain point." That's the build at week six, not the build at year one.

Multi-user auth is the wall

A single-user brain needs no permissions model. The moment a second person reads or writes, you need auth against Google Workspace, per-source credentials, and a decision about who sees which account. This is the exact point where the workflow-automation team's build stalled. It's unglamorous work with no customer-visible payoff, so it loses every prioritization fight against actual delivery work.

Reconciliation never gets an owner

The store fills, and new facts contradict old ones. The go-live moved, the sponsor changed, the scope got cut on a call nobody synced. Someone has to decide which version is true, and that job is on no one's calendar. Stripe's 2018 developer research found the average developer already spends more than 17 hours a week on maintenance work like debugging and refactoring. The internal brain adds a new maintenance surface on top, staffed by the people you hired to be with customers.

Why home-built brains drift

Here's the pattern we've seen across the teams we've onboarded: a regular brain (Obsidian and the like) drifts somewhere between 500 and 1,000 facts. That's our observation, not an industry benchmark. Below that line the builder can hold the whole store in their head and patch errors on sight. Above it, contradictions accumulate faster than anyone reconciles them, and the brain starts confidently returning superseded information.

The failure is silent, which is what makes it dangerous. Retrieval still works. Answers still sound right. The same practitioner analysis notes that a system can score 95% on standard metrics while returning information superseded for weeks. Your engineer quotes a porting date to the customer, and the date is from two calls ago. We unpack the mechanics, and the catch-it playbook, in our piece on context drift in home-built brains.

What the success data says

The build instinct deserves a fair hearing against the numbers, and the numbers are rough on it. MIT's NANDA research, reported by Fortune, found that about 95% of enterprise generative AI pilots produce no measurable P&L impact, and the split inside the survivors is the interesting part: purchased specialized tools succeed about 67% of the time, while internally built tools succeed about a third of the time. Generic tools stall, in the report's words, because they don't learn from or adapt to workflows. An internal build can adapt to your workflow, but only if someone keeps building it.

The 2025 DORA report puts it another way: AI doesn't fix a team, it amplifies what's already there. A context layer amplifies your reconciliation process. If that process is "nobody, eventually," the layer amplifies nothing.

And doing neither has a price too. Panopto's 2018 knowledge-sharing study found knowledge workers waste 5.3 hours every week waiting for or recreating knowledge, which at large-company scale it values at $47 million a year in lost productivity. The status quo of spreadsheets and Slack is not the free option it looks like.

Aircall lived the whole arc. Their engineers wanted one place to ask rollout questions and get the same answer regardless of who asked. Paul Yi, a senior software engineer there, put it plainly: "I ask 'what's blocking the cutover' in Claude and get the actual answer, with sources. Same question, same answer, whoever asks. We tried to build that. It didn't hold." After switching to a bought project brain, the team's summary reads "Connected in minutes with zero engineering resources," and the full Aircall story has the before and after.

Build vs buy, side by side

  • Spreadsheets + Slack (the real incumbent). Time to first value: Already deployed. Who maintains it: Everyone, so no one. Drift handling: None, you re-ask in Slack. Where it wins: Nothing to build, nothing to learn.
  • Home-built layer (Supabase + Claude Code, vault + Git). Time to first value: A weekend for v1, months for multi-user. Who maintains it: Your most senior FDE, unbudgeted. Drift handling: Manual, unquantified, usually skipped. Where it wins: Full control, no vendor risk, exact fit to your stack.
  • Bought project brain (Tandem's account brain). Time to first value: Days, varies by team. Who maintains it: The vendor. Drift handling: Reconciliation built in, drift surfaced as ranked risks a human reviews. Where it wins: Context stays current while FDEs do FDE work.

The hedged cells are deliberate. Build-side maintenance cost is real but unquantified, because almost nobody tracks it.

When building is the right call

Buying isn't always the answer, and pretending otherwise would repeat the vendor FUD this article promised to avoid. Build when:

  • The context layer is your product. If you sell memory infrastructure or your differentiation depends on a proprietary data pipeline, own it fully.
  • You have platform engineers whose actual job it is. The builds that survive have a named owner with roadmap time. The builds that die were side projects of delivery engineers.
  • Data residency or policy rules out vendors. Some regulated environments make an external store a non-starter. Full control and zero vendor risk are genuine advantages, and they stay true no matter what the success statistics say.
  • You're one person with three accounts. Below the drift threshold, a personal vault plus discipline works fine. Our guide to creating a project brain covers what to capture whichever tool holds it, and the Notion and Airtable DIY route is a reasonable middle step.

Buy when the requirement is that account context stays current across people and tools while your engineers stay on accounts. That's a service level, not a schema, and service levels are what vendors are for.

How to run the decision

  • Price the maintainer, not the prototype. The weekend build is nearly free. Estimate the ongoing hours for pipelines, auth, and reconciliation, then name the person who'll spend them and what account work they'll drop.
  • Count your sources. Calls, Slack, tickets, email, CRM, coding sessions. Each one is a pipeline you'll build and babysit. Fewer than two, build is plausible. More than three, be suspicious of your own estimate.
  • Name the reconciler. Who decides which of two contradicting facts is true, and when do they do it? If the answer is "the model" or "later," you've found your failure mode.
  • Set a drift tripwire before you start. Pick a check you'll run monthly, such as sampling ten facts and verifying them against reality. If you won't commit to the check, you're choosing drift.
  • Run the ROI on hires avoided, not tool cost. The money question is whether current context lets the same team carry more accounts, and only then how much faster projects close.

What stays manual

Whichever way you go, some work stays human. Judgment doesn't transfer through any store, built or bought. In Tandem, you choose what syncs from a Claude Code session into the brain, and nothing is pushed without you triggering it. The risk check returns a list of risks, each with an explanation, the reason, and the sources behind it, and a human decides what to do about every one. Evaluating whether any memory system is telling the truth about your accounts remains an open discipline, and it's a question engineers should put to every vendor, us included.

The decision, priced

The build gets you control and an unbudgeted second product. The buy gets you a service level on context freshness. For the business case, the cleanest model we can share is Qonto's: "Qonto's onboarding org runs about 90 specialists. Tandem's automated coordination and day-three delay detection let the team absorb 34% more volume and avoid roughly 23 hires. At €80K to €100K fully loaded per specialist, that is €1.8M to €2.3M in avoided payroll against a Tandem cost of about €0.85M a year, a 2 to 2.7x return in year one." The Qonto story has the detail.

If your team is mid-build, or mid-argument about one, the fastest way to compare is on your own accounts. See Tandem flag the risk on one of your live implementations in a demo, then decide whether that's a thing you want to keep building.

FAQs

How long does it really take to build an internal shared context layer?

The single-user prototype takes days. Multi-user auth, per-source pipelines, and reconciliation take months of intermittent work, and that's where the builds we meet stall. Budget for an ongoing owner, not a project with an end date.

What does a home-built context layer cost to run?

Mostly senior FDE time, which is why it rarely shows up in the estimate. Developers already spend 17-plus hours a week on maintenance work, and the brain adds pipelines, auth, and data-quality triage to the pile. Infrastructure cost is trivial by comparison.

Is the 500 to 1,000 fact drift threshold a hard rule?

No. It's our observation across teams we've onboarded, not a sourced benchmark, and it varies with account count and discipline. The shape is the consistent part: below it one person patches errors on sight, above it contradictions outrun reconciliation.

When is building clearly the right choice?

When the context layer is your actual product, when a platform team owns it with roadmap time, or when policy rules out external vendors. Solo FDEs under a handful of accounts also do fine with a personal vault and discipline.

Can we keep the Supabase store we already built?

Yes, and teams often do, as an archive. The switch that matters is where new context lands and where questions get asked. Tandem's brain is queried from Claude, Claude Code, or ChatGPT via Tandem MCP, so the day-to-day moves there while the old store stays put.

Key terms

Shared context: the account-level state (what was promised, decided, at risk, and next) that a whole team and its AI tools can query and trust. The problem it solves is context living in one person's head or vault.

Project brain: the category artifact, a maintained, queryable store of reconciled project facts with sources. See what is a project brain.

Account brain: Tandem's version of the project brain, with risk detection, Tandem agents acting with human approval, and a customer workspace. Part of the AI workspace for implementation and deployment teams.

Context drift: the widening gap between what a knowledge store says and what's true on the account. Silent by nature, because retrieval keeps working while answers go stale.

Build vs buy threshold: the point where maintaining an internal tool costs more than buying the service level, usually crossed when pipelines, auth, and reconciliation outgrow one owner's spare time.

Tandem MCP: Tandem's Model Context Protocol server, which lets Claude, Claude Code, or ChatGPT query the account brain and sync chosen session facts back to it.