Build vs. Buy vs. Configure

Every knowledge base infrastructure decision starts here: build a custom system, buy a commercial platform, or configure an existing tool the organization already has. The correct answer depends entirely on your constraints — not on what other companies use, not on what the vendor's sales team demonstrates, and not on what the engineering team finds technically interesting.

The 3-layer rule applies directly. Build at the custom layer only when the requirements genuinely cannot be met at a lower layer. Configure first. Buy if configuration is insufficient. Build only if buying fails to meet non-negotiable requirements. Most organizations jump directly to "build" because it feels like control. What it actually delivers is ownership of a maintenance burden.

1. Configure First Assess what the organization already owns. A Notion workspace with structured databases, a Confluence instance with well-designed spaces, a SharePoint with managed metadata columns — these are not inferior options. They are options with zero procurement cost, existing SSO integration, and established user familiarity. The barrier to "configure" is usually not capability; it is the perception that a dedicated tool signals organizational seriousness. That perception is wrong and expensive.
2. Buy When Configuration Hits Real Limits Commercial knowledge base platforms (Guru, Tettra, Document360, Archbee, Obsidian for Teams) address specific capability gaps: AI-assisted search, structured content types, workflow-gated publishing, deep analytics on content usage. Buy when the gap is real and the missing capability has a documented business impact — not because the interface is cleaner. Evaluate against the evaluation matrix in Lesson 2 before any procurement decision.
3. Build Only for Non-Negotiable Custom Requirements Custom-built knowledge infrastructure is appropriate when: the knowledge base needs to be directly embedded in a product, retrieval requirements require a vector search architecture not available in commercial products, or data residency and compliance requirements rule out cloud-based options. Build also requires a long-term maintenance owner — an organization that cannot commit one engineer-equivalent of maintenance capacity should not build.
4. Hybrid Architectures Many mature knowledge systems are hybrid: a commercial platform for human-facing content authoring and navigation, with a custom API layer and vector store for AI-connected retrieval. The commercial platform handles authoring workflow, governance, and user experience. The custom layer handles programmatic access, embedding generation, and RAG integration. Separate the concerns — do not ask a commercial wiki platform to serve as a vector database.