---
# === IDENTITY ===
id: business/startup-operations/knowledge-management-setup/2026
canonical_question: "How do I set up knowledge management — internal wiki, decision log, lessons learned, tool selection by team size?"
aliases:
  - "Startup knowledge management setup 2026"
  - "Internal wiki and decision log design"
  - "Knowledge base tool selection for startups"
entity_type: execution_recipe
domain: business > startup-operations > knowledge management setup
region: global
jurisdiction: global
temporal_scope: 2025-2026

# === VERIFICATION ===
last_verified: 2026-03-12
confidence: 0.87
version: 1.0
first_published: 2026-03-12

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: evolving
  last_breaking_change: "Notion AI features bundled into Plus/Business plans (late 2025); Confluence AI (Rovo) added to Standard tier with 25 credits/user/month; Guru raised minimum to 10 seats ($250/mo floor)"
  next_review: 2026-09-08
  change_sensitivity: high

# === CONSTRAINTS ===
constraints:
  - "Tool choice must match team size — free tiers cap at 10 users (Confluence) or degrade features (Notion blocks limit on free). Plan for growth beyond current headcount."
  - "Information architecture must be designed before content migration — dumping documents without taxonomy creates an unsearchable knowledge graveyard within 3 months"
  - "Every knowledge page needs a single designated owner — unowned pages decay to irrelevance within 60-90 days"
  - "Decision logs must be written within 48 hours of the decision — reconstructing rationale after the fact produces unreliable records"
  - "Review cycles must be enforced through tooling (automated reminders), not willpower — manual review processes have <20% compliance rates"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "User needs overall operations strategy, not knowledge management execution"
    use_instead: "business/startup-operations/startup-operations-stack/2026"
  - condition: "User already has a wiki and needs to fix adoption or search problems"
    use_instead: "business/startup-operations/startup-operations-stack/2026"
  - condition: "User needs engineering documentation (API docs, runbooks), not company-wide knowledge management"
    use_instead: "Search knowledgelib.io for docs-as-code engineering documentation — no dedicated unit yet"

# === AGENT HINTS ===
inputs_needed:
  - key: tool_preference
    question: "Which wiki/knowledge base platform should be used?"
    type: choice
    options: ["Notion", "Confluence", "Slite", "Tettra", "Almanac", "no preference — auto-select"]
  - key: team_size
    question: "What is the current team size?"
    type: choice
    options: ["1-5 (founding team)", "6-15 (early stage)", "16-50 (scaling)", "50+ (growth stage)"]
  - key: technical_skill
    question: "What is the team's technical skill level?"
    type: choice
    options: ["non-technical (no-code only)", "semi-technical (can edit templates)", "developer (can customize integrations)"]
  - key: budget_for_tools
    question: "What's the tool budget for knowledge management?"
    type: choice
    options: ["free tier only", "up to $50/month", "up to $200/month", "no limit"]

# === EXECUTION METADATA ===
execution:
  required_inputs:
    - name: "Team size and projected growth"
      source: "founder or operations lead"
      format: "current headcount + 12-month hiring plan"
    - name: "Existing documentation inventory"
      source: "all team members"
      format: "list of where knowledge currently lives (Google Docs, Slack, email, heads)"
    - name: "Top 10 questions new hires ask in first week"
      source: "recent hires or hiring manager"
      format: "list of frequently asked questions"
  outputs:
    - name: "Configured wiki platform with information architecture"
      format: "live wiki with workspace structure, templates, and permissions"
      description: "Organized workspace with top-level spaces, nested pages, and navigation sidebar ready for content"
    - name: "Decision log system"
      format: "structured template in wiki"
      description: "Standardized format for recording decisions with context, rationale, alternatives considered, and outcome tracking"
    - name: "Lessons learned repository"
      format: "structured template in wiki"
      description: "Post-mortem and retrospective capture system with categorization and searchable tags"
    - name: "Content ownership map and review schedule"
      format: "spreadsheet or wiki page"
      description: "Every knowledge area assigned an owner with quarterly review dates and automated reminder configuration"
  tools_required:
    - name: "Wiki/knowledge base platform"
      purpose: "Central repository for all company knowledge"
      tier: "free-to-paid"
      cost: "$0 (free tier) to $10-15/user/mo"
      alternatives: ["Notion", "Confluence", "Slite", "Tettra", "Almanac", "GitBook"]
    - name: "Slack or Teams"
      purpose: "Integration for search, notifications, and knowledge capture from conversations"
      tier: "free-to-paid"
      cost: "$0 (free tier) to $8.75/user/mo"
      alternatives: ["Slack", "Microsoft Teams", "Discord"]
  credentials_needed:
    - service: "Wiki platform account"
      type: "email + password or SSO"
      where_to_get: "https://notion.so or https://atlassian.com/software/confluence or https://slite.com"
      free_tier_limits: "Notion: unlimited pages, 10 guests. Confluence: 10 users, 2GB. Slite: 50 docs. Tettra: N/A (paid only, $250/mo min via Guru)."
  estimated_duration: "4-8 hours initial setup, then 2-4 weeks for adoption and content seeding"
  estimated_cost: "$0 (free tier) to $150/mo for 10-person team depending on platform"

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/business/startup-operations/knowledge-management-setup/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-03-12)"

# === RELATED UNITS ===
related_kos:
  depends_on:
    - id: "business/startup-operations/startup-operations-stack/2026"
      label: "Startup operations tool stack — project management, docs platform, communication and meeting tooling selected by team size"
  feeds_into:
    - id: "business/startup-operations/employee-onboarding-playbook-for-startups/2026"
      label: "Startup employee onboarding — first day/week/month/quarter, tool provisioning, buddy system, 90-day assessment"
  related_to:
    - id: "business/startup-operations/meeting-cadence-design/2026"
      label: "Meeting notes and action items flow into knowledge base"
  alternative_to: []

# === SOURCES ===
sources:
  - id: src1
    title: "How to Create an Internal Wiki in 2026: Steps, Tools, and Adoption"
    author: Whatfix
    url: https://whatfix.com/blog/internal-wiki/
    type: expert_guide
    published: 2026-01-01
    reliability: high
  - id: src2
    title: "The Complete Knowledge Management Strategy Guide for 2026"
    author: Lindy
    url: https://www.lindy.ai/blog/knowledge-management-strategy
    type: expert_guide
    published: 2026-01-01
    reliability: high
  - id: src3
    title: "Knowledge Base Taxonomy: 10 Principles That Work"
    author: MatrixFlows
    url: https://www.matrixflows.com/blog/knowledge-base-taxonomy-best-practices
    type: expert_guide
    published: 2025-01-01
    reliability: high
  - id: src4
    title: "Decision record: how to initiate and complete decisions for teams"
    author: Joel Parker Henderson
    url: https://github.com/joelparkerhenderson/decision-record
    type: reference
    published: 2025-01-01
    reliability: high
  - id: src5
    title: "Confluence vs Notion: Compare for Knowledge Base"
    author: Tettra
    url: https://tettra.com/article/notion-vs-confluence/
    type: comparison
    published: 2025-01-01
    reliability: high
  - id: src6
    title: "15 Wiki Software Platforms to Consider in 2026"
    author: Document360
    url: https://document360.com/blog/wiki-software/
    type: industry_report
    published: 2026-01-01
    reliability: high
---

# Knowledge Management Setup

## Purpose

This recipe builds a complete knowledge management system for a startup — from wiki platform selection and information architecture design through decision log templates, lessons learned capture, content ownership assignment, and automated review cycles. The output is a fully configured wiki with structured navigation, standardized templates for decisions and retrospectives, designated page owners, and search/discovery optimized for a growing team. [src1]

## Prerequisites

- [ ] **Team size and growth plan** — current headcount and 12-month hiring projection (determines tool tier and architecture complexity)
- [ ] **Existing documentation inventory** — list of where knowledge currently lives (Google Docs, Slack, email, individual notes, nowhere)
- [ ] **Top 10 new-hire questions** — the questions asked most often in the first week (these seed the initial wiki content)
- [ ] **Wiki platform account** created — [Notion](https://notion.so), [Confluence](https://atlassian.com/software/confluence), [Slite](https://slite.com), or [Almanac](https://almanac.io)
- [ ] **Slack or Teams workspace** — for wiki integration (search, notifications, knowledge capture from conversations)
- [ ] **Admin access** to create workspaces, set permissions, and install integrations

## Constraints

- Information architecture must be designed before any content migration. Unstructured document dumps create unsearchable knowledge graveyards within 3 months. [src3]
- Every wiki page needs exactly one designated owner. Unowned pages decay to irrelevance within 60-90 days as products, processes, and teams change. [src1]
- Decision logs must be written within 48 hours of the decision. Reconstructing rationale after the fact produces unreliable records that mislead future decision-makers. [src4]
- Keep taxonomy to 3-4 levels maximum. Deeper hierarchies reduce content discovery and cause authors to misfile documents. [src3]
- Review cycles must be enforced through automated reminders, not manual tracking. Manual review processes achieve less than 20% compliance. [src2]

## Tool Selection Decision

```
Which platform?
├── Team is 1-10 AND wants all-in-one (wiki + projects + databases)
│   └── PATH A: Notion Free/Plus — flexible blocks, databases, multiple views
├── Team is 5-50 AND uses Atlassian stack (Jira, Trello)
│   └── PATH B: Confluence — deep Jira integration, structured spaces, permissions
├── Team is 3-25 AND values simplicity + AI search
│   └── PATH C: Slite — clean interface, AI-powered Ask, doc verification
└── Team is 10-50 AND Slack-first workflow
    └── PATH D: Tettra/Guru — Slack-native Q&A, auto-surfaces answers in channels
```

| Path | Tools | Cost (10 users) | Setup Time | Best For |
|------|-------|-----------------|------------|----------|
| A: Notion | Notion Free or Plus | $0-100/mo | 2-4 hours | Startups wanting one tool for everything [src5] |
| B: Confluence | Confluence Free or Standard | $0-54/mo | 3-5 hours | Atlassian shops, engineering-heavy teams [src5] |
| C: Slite | Slite Free or Standard | $0-67/mo | 1-3 hours | Remote teams wanting simple, searchable docs [src6] |
| D: Tettra/Guru | Guru Self-Serve | $250/mo (10-seat min) | 2-4 hours | Slack-first teams, customer-facing knowledge [src6] |

## Execution Flow

### Step 1: Platform Setup and Workspace Configuration

**Duration**: 30-60 minutes
**Tool**: Chosen wiki platform

Create the workspace and configure basic settings. The workspace structure determines how knowledge is organized and discovered for the life of the company.

```
Workspace Setup:
─────────────────────────────────────────
1. Create workspace (team name, logo, timezone)
2. Configure authentication:
   • Enable SSO/Google Workspace sign-in (if available on tier)
   • Set default member permissions (can edit vs can view)
   • Invite founding team members
3. Install core integrations:
   • Slack: /wiki or /notion commands for quick search
   • Google Drive: embed existing docs (don't migrate yet)
   • Calendar: link meeting notes to events

Permission Model (by team size):
─────────────────────────────────────────
1-10 people:  Everyone can edit everything. Trust > control.
10-25 people: Team-level spaces with edit access. Company-wide read.
25-50 people: Team spaces + private spaces for HR, finance, legal.
50+ people:   Space-level admins, page-level permissions, audit logs.
```

**Verify**: All team members can log in, create pages, and search. Slack integration returns results when querying `/wiki test`.
**If failed**: Check SSO domain matches company email domain. Verify integration OAuth permissions are granted. Retry Slack installation from wiki admin panel.

### Step 2: Design Information Architecture

**Duration**: 1-2 hours
**Tool**: Wiki platform (create top-level structure)

Build the taxonomy before adding content. Research shows 5-9 top-level categories are optimal for navigation, and hierarchy should not exceed 3-4 levels. [src3]

```
Recommended Top-Level Structure (startup):
─────────────────────────────────────────
📋 Company
   ├── Mission, Vision, Values
   ├── Org Chart / Team Directory
   ├── Company OKRs / Goals
   └── Culture & Norms

📖 Handbook (Employee Reference)
   ├── Onboarding Checklist
   ├── Benefits & Perks
   ├── Time Off & Leave Policies
   ├── Tools & Access Setup
   └── Communication Norms

🔨 Engineering (or Product & Engineering)
   ├── Architecture Decisions (ADRs)
   ├── Development Workflow
   ├── Deployment & Runbooks
   ├── Code Review Guidelines
   └── Incident Response

📊 Product
   ├── Roadmap
   ├── Feature Specs / PRDs
   ├── User Research
   └── Release Notes

💰 Sales & Marketing
   ├── ICP & Personas
   ├── Pricing & Packaging
   ├── Competitive Intel
   ├── Case Studies
   └── Brand Guidelines

📝 Decision Log (cross-functional)
   └── All major decisions (see Step 3)

🔄 Lessons Learned (cross-functional)
   └── Post-mortems and retrospectives (see Step 4)

📁 Meeting Notes
   ├── All-Hands
   ├── Leadership
   └── Team Standups

Naming Conventions:
─────────────────────────────────────────
• Pages: "[Type] Title — Date" (e.g., "ADR-017 Switch to Postgres — 2026-03")
• Use lowercase slugs for URLs where supported
• Tag pages with team, status (draft/active/archived), and review date
• Prefix templates with [Template] for discoverability
```

**Verify**: Navigate the sidebar. Can a new hire find the onboarding checklist in under 3 clicks? Can an engineer find the deployment runbook without searching? If either fails, restructure.
**If failed**: If the tree feels too deep, flatten by merging subcategories. If too shallow, split the largest sections. The 3-click rule is the litmus test.

### Step 3: Set Up Decision Log

**Duration**: 30-45 minutes
**Tool**: Wiki platform (create template + first entries)

Create a standardized decision log template. The decision record format ensures every decision captures the context needed to understand it months later. [src4]

```
Decision Log Template:
─────────────────────────────────────────
# [DEC-{NNN}] {Decision Title}

**Date**: YYYY-MM-DD
**Decision Maker(s)**: @name1, @name2
**Status**: Proposed | Accepted | Deprecated | Superseded by DEC-{NNN}

## Context
What is the situation that requires a decision? What problem are we solving?
(2-4 sentences. Include relevant metrics, constraints, or deadlines.)

## Options Considered
| Option | Pros | Cons | Estimated Cost/Effort |
|--------|------|------|----------------------|
| A: {option} | {pros} | {cons} | {cost} |
| B: {option} | {pros} | {cons} | {cost} |
| C: {option} | {pros} | {cons} | {cost} |

## Decision
We chose Option {X} because {rationale in 1-3 sentences}.

## Consequences
- {Expected positive outcome 1}
- {Expected positive outcome 2}
- {Risk or trade-off accepted}

## Review Date
Revisit this decision by YYYY-MM-DD to evaluate if assumptions held.

─────────────────────────────────────────

First Entries to Create:
─────────────────────────────────────────
DEC-001: Choice of wiki platform (document why you picked Notion/Confluence/etc.)
DEC-002: Information architecture structure (document the taxonomy you designed)
DEC-003: Most recent strategic decision the team made (backfill one to set the pattern)
```

**Verify**: The decision log has at least 3 entries. Each entry has all fields populated. The log is linked from the sidebar navigation and findable via search.
**If failed**: If the template feels too heavy, remove the Options table for quick decisions and keep it only for decisions with >$1K impact or cross-team implications.

### Step 4: Create Lessons Learned Repository

**Duration**: 30-45 minutes
**Tool**: Wiki platform (create template + first entry)

Build a structured system for capturing retrospective insights. This prevents the same mistakes from recurring and preserves institutional knowledge when team members leave.

```
Lessons Learned Template:
─────────────────────────────────────────
# [LL-{NNN}] {Title}

**Date**: YYYY-MM-DD
**Author**: @name
**Category**: Incident | Project | Process | Product | Hiring
**Severity**: Minor | Moderate | Major

## What Happened
{Factual summary of the event, project outcome, or process failure. 3-5 sentences.}

## What Went Well
- {Positive outcome or effective practice 1}
- {Positive outcome 2}

## What Went Wrong
- {Failure or missed expectation 1}
- {Root cause if known}
- {Failure 2}

## Action Items
| Action | Owner | Due Date | Status |
|--------|-------|----------|--------|
| {action 1} | @name | YYYY-MM-DD | Open |
| {action 2} | @name | YYYY-MM-DD | Open |

## Key Takeaway
{One sentence that captures the most important lesson. This is what shows up in search results and summaries.}

─────────────────────────────────────────

Trigger Points (when to write a lessons learned):
─────────────────────────────────────────
• After any production incident (mandatory)
• At end of every project or milestone (mandatory)
• After a failed hire or departure (recommended)
• After losing a deal >$10K (recommended)
• After any process change that caused confusion (optional)
• Quarterly: review all open action items
```

**Verify**: Template is saved, tagged as `[Template]`, and linked from the Lessons Learned space. At least one backfilled entry exists (most recent incident or project completion).
**If failed**: If the team resists writing post-mortems, start with a blameless format — remove individual names from the "What Went Wrong" section and focus on systemic causes.

### Step 5: Establish Content Ownership and Review Cycles

**Duration**: 45-60 minutes
**Tool**: Wiki platform + spreadsheet or database

Assign every knowledge area an owner and configure automated review reminders. This is the step most teams skip, and it is the primary reason wikis go stale. [src1] [src2]

```
Content Ownership Map:
─────────────────────────────────────────
| Knowledge Area | Owner | Backup Owner | Review Frequency | Next Review |
|---------------|-------|-------------|-----------------|-------------|
| Onboarding | @hr_lead | @ops_lead | Quarterly | 2026-06-12 |
| Engineering ADRs | @eng_lead | @cto | On change | Ongoing |
| Product Roadmap | @pm_lead | @ceo | Monthly | 2026-04-12 |
| Sales Playbook | @sales_lead | @founder | Quarterly | 2026-06-12 |
| Company Policies | @ops_lead | @founder | Semi-annual | 2026-09-12 |
| Decision Log | @ops_lead | @ceo | Monthly | 2026-04-12 |
| Lessons Learned | Rotating | @ops_lead | On creation | Ongoing |
| Meeting Notes | Meeting owner | N/A | N/A | N/A |

Automated Review Setup:
─────────────────────────────────────────
Notion:   Use database with "Next Review" date property
          → Create filtered view showing overdue pages
          → Set up Slack reminder via Notion integration or Zapier

Confluence: Use page properties macro with "Review Date"
            → Create saved search for overdue reviews
            → Configure Confluence reminder emails

Slite:    Use Slite's built-in doc verification feature
          → Set verification intervals per document
          → Slite sends automated review reminders to owners

All platforms: Create a monthly "Knowledge Health" Slack reminder
               that links to the overdue review dashboard
```

**Verify**: Every top-level section has an assigned owner. Automated reminders are configured and a test reminder has been received. The ownership map is published and linked from the wiki homepage.
**If failed**: If the team is too small for dedicated owners (1-5 people), assign the founder or ops lead as default owner for everything and set quarterly review dates.

### Step 6: Build Search and Discovery Layer

**Duration**: 30-45 minutes
**Tool**: Wiki platform + Slack integration

Optimize for findability. The wiki is only valuable if people can find what they need faster than asking a colleague on Slack.

```
Search Optimization:
─────────────────────────────────────────
1. Enable full-text search (default on all platforms)
2. Add consistent tags to every page:
   • Team: engineering, product, sales, marketing, ops, hr
   • Type: process, decision, reference, template, meeting-notes
   • Status: draft, active, archived, deprecated
3. Create "Start Here" pages for each team:
   • Link to the 5-10 most important pages for that team
   • Include "If you're looking for X, go to Y" shortcuts
4. Pin critical pages in Slack channels:
   • #engineering → link to deployment runbook, ADR log
   • #sales → link to pricing page, competitive intel
   • #general → link to company handbook, decision log

Slack Integration Commands:
─────────────────────────────────────────
Notion:   /notion search {query} — searches workspace
Confluence: /confluence search {query} — searches spaces
Slite:    /slite {query} — AI-powered search
Tettra:   Kai bot answers questions directly in Slack

Anti-Search-Rot Practices:
─────────────────────────────────────────
• Archive (don't delete) outdated pages — maintains URL integrity
• When updating a process, add a "Supersedes: [old page]" link
• Use canonical naming — one page per topic, not five drafts
• Merge duplicate pages monthly (add to review cycle)
```

**Verify**: Search for 3 common questions (onboarding, deployment process, pricing). Each returns the correct page in the top 3 results. Slack integration returns results within 3 seconds.
**If failed**: If search returns irrelevant results, check that page titles are descriptive (not "Untitled" or "Notes from Tuesday"). Add summary/description fields to pages that lack them. Remove or archive stale duplicates.

### Step 7: Seed Initial Content and Prevent Knowledge Rot

**Duration**: 2-4 hours (spread across first week)
**Tool**: Wiki platform

Populate the wiki with the highest-value content first. An empty wiki will not be adopted. A wiki with 20 useful pages will.

```
Priority Content (create in this order):
─────────────────────────────────────────
Week 1 — Critical (must have before declaring wiki "live"):
1. Onboarding checklist (answers top 10 new-hire questions)
2. Tool access guide (how to get accounts for Slack, GitHub, etc.)
3. Company values / how we work
4. Current quarter OKRs / goals
5. Decision log with 3 backfilled entries

Week 2 — High Value:
6. Engineering: deployment process / runbook
7. Product: current roadmap (even if rough)
8. Sales: ICP definition + pricing
9. HR: time-off policy + benefits summary
10. First lessons-learned entry

Week 3 — Growth:
11-15. Team-specific process docs (each team contributes 1-2 pages)
16-20. Templates: PRD template, meeting notes template, 1:1 template

Knowledge Rot Prevention:
─────────────────────────────────────────
• "Last verified" date visible on every page
• Automated Slack alert when any page exceeds its review date
• Quarterly "Wiki Gardening" session (30 min, all-hands):
  - Each team reviews their pages
  - Archive anything outdated
  - Merge duplicates
  - Update ownership if roles changed
• New page creation must use a template (enforces consistency)
• Sunset rule: pages not viewed in 6 months get archived automatically
  (configure via analytics or manual quarterly review)
```

**Verify**: Wiki has at least 10 substantive pages. At least 3 team members have created or edited a page. Slack channel has been notified that the wiki is live with a "Start Here" link.
**If failed**: If adoption is low, identify the 1-2 questions asked most frequently in Slack, answer them in the wiki, and respond to the next Slack question with a wiki link instead of typing the answer again. This demonstrates value through action.

## Output Schema

```json
{
  "output_type": "knowledge_management_system",
  "format": "configured wiki + templates + ownership map",
  "columns": [
    {"name": "wiki_platform", "type": "string", "description": "Platform name (Notion, Confluence, Slite, etc.)", "required": true},
    {"name": "top_level_spaces", "type": "number", "description": "Number of top-level navigation sections", "required": true},
    {"name": "templates_created", "type": "number", "description": "Number of standardized templates (decision log, lessons learned, etc.)", "required": true},
    {"name": "pages_seeded", "type": "number", "description": "Number of initial content pages created", "required": true},
    {"name": "owners_assigned", "type": "number", "description": "Number of knowledge areas with designated owners", "required": true},
    {"name": "review_automation", "type": "boolean", "description": "Automated review reminders configured", "required": true},
    {"name": "slack_integration", "type": "boolean", "description": "Wiki search accessible from Slack", "required": false},
    {"name": "adoption_rate", "type": "number", "description": "Percentage of team members who created or edited a page in first 2 weeks", "required": false}
  ],
  "expected_row_count": "1",
  "sort_order": "N/A (single row)",
  "deduplication_key": "wiki_platform"
}
```

## Quality Benchmarks

| Quality Metric | Minimum Acceptable | Good | Excellent |
|---------------|-------------------|------|-----------|
| Initial pages seeded | > 10 pages | > 20 pages | > 30 pages with templates |
| Content ownership coverage | > 60% of sections have owners | > 80% | 100% with backup owners [src1] |
| Team adoption (2-week) | > 50% of team logged in | > 70% created a page | > 90% active contributors |
| Search success rate | > 60% of searches return useful result | > 80% | > 90% with AI-assisted search [src2] |
| Decision log entries | > 3 backfilled | > 5 with ongoing capture | All decisions logged within 48h [src4] |
| Review cycle compliance | > 30% on schedule | > 60% | > 80% with automated reminders |

**If below minimum**: Focus on adoption first. A wiki with 5 great pages that people actually use beats 50 pages nobody reads. Identify the top 3 Slack questions, write wiki answers, and redirect future questions to wiki links.

## Error Handling

| Error | Likely Cause | Recovery Action |
|-------|-------------|----------------|
| Team ignores wiki, keeps using Slack/email | No clear value demonstrated; content is stale or hard to find | Identify the #1 repeated Slack question, write a definitive wiki answer, redirect all future questions there. Make wiki the source of truth for one high-value topic first. [src1] |
| Wiki becomes a document graveyard (lots of pages, none current) | No ownership or review cycles configured | Run Step 5 immediately. Assign owners, set review dates, archive everything that has not been updated in 6 months. |
| Search returns irrelevant or duplicate results | Poor naming conventions, duplicate pages, no taxonomy | Deduplicate pages (merge, redirect, archive). Enforce naming conventions from Step 2. Add tags and summaries to all pages. [src3] |
| Decision log not being maintained | Too many fields, too much friction | Simplify template to 4 fields: Decision, Date, Rationale, Review Date. Low friction beats comprehensiveness. Add to existing meeting note templates as a section. |
| Information architecture becomes outdated as team grows | Original structure designed for smaller team | Schedule architecture review at every doubling of team size (5→10, 10→20, 20→40). Add new spaces, split overcrowded sections, update permissions. |
| Sensitive information exposed to wrong team members | Flat permissions without access controls | Move sensitive content (HR, finance, legal) to private spaces. Review permissions monthly. Enable audit logs if available on platform tier. |

## Cost Breakdown

| Component | Free Tier | Starter | Growth (25 users) |
|-----------|-----------|---------|-------------------|
| Notion | Free (unlimited pages, 10 guests) | $10/user/mo Plus | $250/mo ($10/user) [src5] |
| Confluence | Free (up to 10 users, 2GB) | $5.42/user/mo Standard | $136/mo ($5.42/user) [src5] |
| Slite | Free (50 docs) | $6.67/user/mo Standard | $167/mo ($6.67/user) [src6] |
| Guru | N/A (10-seat min at $25/seat) | $250/mo minimum | $625/mo ($25/user) [src6] |
| Almanac | Free (limited) | $12/user/mo | $300/mo ($12/user) |
| Slack integration | $0 (included) | $0 | $0 |
| **Total (10 users, recommended)** | **$0 (Notion/Confluence)** | **$50-100/mo** | **$136-250/mo** |

## Anti-Patterns

### Wrong: Dumping all existing documents into the wiki without organizing first
Migrating 500 Google Docs into the wiki with no taxonomy, tagging, or ownership. Result: unsearchable mess that is worse than the original state because now nobody knows which version is current. Team abandons wiki within 30 days. [src3]

### Correct: Design information architecture first, then selectively migrate
Build the taxonomy (Step 2) before importing anything. Migrate only the top 20 most-used documents first. Archive or delete the rest. Every migrated page gets an owner, tags, and a review date.

### Wrong: Requiring consensus on every wiki update
Creating an approval workflow where multiple people must sign off on every page edit. Result: nobody contributes because the friction is too high. Wiki stagnates.

### Correct: Default to open editing with lightweight review
Let everyone edit. Use page history to revert mistakes (all platforms support this). Reserve approval workflows for policies, legal content, and public-facing documentation only.

### Wrong: Building a wiki without Slack integration
Expecting people to open a separate app to search for knowledge. Result: people continue asking questions in Slack because it is faster than context-switching to the wiki. [src1]

### Correct: Make the wiki accessible where work happens
Install Slack integration on day one. When someone asks a question in Slack that is answered in the wiki, reply with the wiki link. Over time, the team learns to search the wiki first.

## When This Matters

Use this recipe when the agent needs to build a knowledge management system from scratch for a startup — including wiki platform selection, information architecture, decision logs, lessons learned capture, and content ownership. Requires team size, existing documentation inventory, and admin access as inputs. This recipe covers the operational setup, not the content creation itself.

## Related Units

- [Operations Infrastructure Setup](/business/startup-operations/operations-infrastructure-setup/2026) — overall operations strategy this executes
- [Employee Onboarding Playbook](/business/startup-hiring/employee-onboarding-playbook/2026) — onboarding uses wiki as primary new-hire reference
- [Meeting Cadence Design](/business/startup-operations/meeting-cadence-design/2026) — meeting notes and action items flow into wiki
- [Internal Comms Setup](/business/startup-operations/internal-comms-setup/2026) — communications strategy determines knowledge distribution
- [Startup Analytics Implementation Guide](/business/startup-metrics/startup-analytics-implementation-guide/2026) — knowledge management metrics feed dashboards