Building an Internal Knowledge Base Your Team Will Actually Use

Every company has tried to build a wiki. Most of those wikis are now ghosts. The reason isn't the tool — it's the structure.

Why most wikis die

They're organised the way the founder thinks, not the way new joiners search. The hierarchy is six layers deep. The search returns 40 results and the right one is buried. Pages haven't been updated since the seed round and nobody knows which ones are still true.

The structure that survives

Three top-level sections. That's it.

Run the company. Anything operational: how we invoice, how we hire, how we run a sales call, how we onboard a client. Updated when the process changes.

Build the product. Architecture decisions, runbooks, on-call playbooks. Owned by the team that does the thing.

Know the company. Founding story, values, comp philosophy, benefits. Updated once a year, not weekly.

Anything that doesn't fit one of these three doesn't belong in the wiki. It belongs in Slack, or a meeting, or someone's inbox.

The maintenance rule

Every page has an owner and a last-reviewed date. Anything older than six months gets auto-flagged for review. Anything older than twelve months without a review gets archived. The wiki shrinks naturally instead of bloating naturally.

The AI layer that helps

A simple chatbot pointed at the wiki — using Supabase pgvector or any RAG setup — turns the whole thing into a question-answering surface. New joiners ask the bot instead of pinging the same person on Slack. The bot is only as good as the wiki, which is the whole point: it creates pressure to keep the wiki good.