The Four Layers of Startup Knowledge

Before choosing a tool, define what you are actually trying to store and who needs to find it. Most startups conflate four distinct knowledge layers into one messy folder structure, which is why searches never return what you need.

• Strategic Knowledge: Company vision, product strategy, OKRs, investor materials, competitive positioning, fundraising decks. Audience: leadership, board, investors.
• Operational Knowledge: SOPs, onboarding checklists, vendor lists, process playbooks, escalation paths, HR policies. Audience: all employees, especially new hires.
• Project Knowledge: Project briefs, meeting notes, sprint retrospectives, decision logs, post-mortems. Audience: relevant teams and cross-functional stakeholders.
• Domain Knowledge: Market research, competitive intelligence, customer research, technical architecture docs, legal templates. Audience: function-specific, but searchable by all.

Organising by Function

For startups with 10–50 employees, organise your knowledge base by functional area with a global Home page and a Getting Started guide every new hire sees first:

• Company HQ — Mission, values, org chart, key contacts, company-wide announcements, investor updates
• Product & Engineering — Roadmap, architecture decisions, API docs, sprint notes, post-mortems, coding standards
• Sales & Revenue — ICP definition, battle cards, pricing guide, proposal templates, CRM SOP, deal review notes
• Marketing — Brand guidelines, messaging framework, campaign playbooks, content calendar SOPs, SEO docs
• People & Culture — Hiring process, onboarding playbook, ESOP policy, leave policy, performance review framework
• Finance & Legal — Budget template, vendor payment SOP, legal template library, GST compliance checklist, cap table notes
• Customer Success — Onboarding playbook, escalation process, QBR template, renewal tracking SOP

Organising by Stage

Alternatively, for very early-stage teams (under 15 people), a stage-based structure works well — grouping everything by what the company is currently focused on:

• Phase: Ideation → validation research, assumption logs, early customer interviews
• Phase: Build → product specs, engineering architecture, design decisions
• Phase: Launch → GTM playbook, pricing rationale, launch checklist, PR templates
• Phase: Scale → hiring plan, sales playbooks, unit economics model, investor update templates

Week 1 — Foundation

• Choose your tool and set up the top-level structure (no more than 7 sections at the root)
• Create the Company HQ page with: mission statement, values, org chart (link to HRIS), key contacts, and a "What We Do" one-pager
• Write the Getting Started guide — the single most important document in your wiki; every new hire reads this on day one
• Migrate any existing Google Docs that more than one person references weekly

Week 2 — Operations Core

• Document your top 5 most-repeated processes as SOPs (onboarding a new hire, deploying to production, processing a vendor invoice, handling a customer escalation, running a weekly team meeting)
• Create the Legal Template Library section — collect all templates into one place even if they need updating later
• Set permissions — who can edit vs. who can view in each section

Week 3 — Team Adoption

• Assign a Knowledge Owner per functional section — this person is responsible for keeping that section up to date
• Run a 30-minute team session: "Here's our wiki, here's how to use it, here's where to add things"
• Replace all verbal Slack answers with a link — "I just documented this, see [link]" builds the habit fast
• Set up a recurring 15-minute Wiki Review meeting for knowledge owners monthly

Week 4 — Quality and Discoverability

• Add metadata to all major documents: Owner, Last Updated, Status (Draft / Current / Archived), Audience
• Create a Search Guide page explaining your naming conventions so new hires know what to search for
• Archive outdated content into an /Archive section rather than deleting it — old decisions have context value
• Add your wiki to your company onboarding checklist as the first thing new hires access on Day 1

Search and Discoverability Best Practices

• Consistent naming: Use a template like [Team]-[Type]-[Name]-[YYYY-QQ] e.g., "Sales-SOP-Demo-Call-Script-2025-Q2"
• Tags and labels: Tag documents by status, team, and content type so filters work across the whole wiki
• Link liberally: Every SOP should link to related SOPs, templates, and the team's home page — knowledge is a graph, not a folder
• Redirect old links: When you reorganise, set up redirects from old page locations to new ones — broken links kill wiki adoption
• Surface it in Slack: Pin the wiki Home page in every Slack channel; use Slack bots (Tettra or Guru integrations) to surface relevant pages when questions are asked

The Version Control Problem

The biggest failure mode in startup knowledge bases is outdated content that looks current. An SOP written in January 2024 and never updated, still appearing as "current" in August 2025, is worse than no SOP — it actively misleads teams.

Version Control Practices

• Document Status Header: Every document must have a visible status: Draft | In Review | Current | Deprecated | Archived. Make it the first thing on the page.
• Last Reviewed Date: Mandatory field on every operational document. If a document has not been reviewed in 90 days, it is automatically flagged for review by the knowledge owner.
• Change Log Section: At the bottom of every SOP, maintain a simple change log: Date | What Changed | Who Changed It. Three lines are enough.
• Quarterly Knowledge Audit: Every quarter, run a 60-minute wiki audit: each knowledge owner reviews their section's documents and either re-confirms currency or updates. Log the audit date on the section home page.
• Use native version history: Corpfy Knowledge Hub, Notion, and Slab all maintain full version history. Use it during post-mortems to understand what the documented process was at the time of an incident.
• Never delete — archive: Move deprecated content to an /Archive section with a note on why it was superseded. Decision context from 12 months ago is often critical when revisiting strategy.

Integration with Document Vault

Your knowledge base and document vault serve different purposes and should be kept distinct:

• Knowledge Base: Living operational knowledge — SOPs, playbooks, research. Updated frequently. Internal audience. Searchable and collaborative.
• Document Vault: Final, signed, legally binding documents — contracts, incorporation certificates, board resolutions, signed term sheets. Immutable archive. Access-controlled. Retrieved for due diligence.
• Link from your Knowledge Base to your Document Vault for reference (e.g., "See the signed MSA with [Vendor] in the Document Vault → Contracts → Vendor Agreements") but never store legal documents in your wiki directly.

The Contribution Problem

Building a wiki is 20% of the work. Getting your team to actually update it is 80%. Indian startup teams — especially engineering teams — default to Slack and WhatsApp for knowledge sharing. Changing this requires deliberate culture design, not just tool implementation.

Tactics That Work

• "Document It" as a Team Habit: When any process question comes up in Slack, the responder links to or creates a wiki page. Never answer the same question twice in Slack — that's a knowledge base entry waiting to happen.
• New Hire Contribution Ritual: Every new hire's 30-day goal includes updating or improving one wiki page based on their fresh eyes. New hires are the best quality checkers — they find gaps that experienced team members are blind to.
• Knowledge Owner Programme: Assign one knowledge owner per section, rotate ownership annually. Make it part of their performance goals — "Section currency rate above 90%" is a measurable target.
• Monthly Wiki Highlights: In your all-hands, highlight one great new wiki contribution. Recognition in front of the team drives behaviour far more than any mandate.
• Wiki Link in PR Reviews: For engineering teams, require that non-trivial architectural decisions include a link to a new or updated ADR in the wiki. Gate merges on documentation for critical systems.
• No Slack Encyclopaedia Answers: If a Slack answer is longer than 3 sentences, it belongs in the wiki. Link to the newly created doc in Slack. This naturally builds the knowledge base through normal work.

Onboarding Use Case — The Wiki as Day 1 Infrastructure

The highest-ROI application of a knowledge base is new hire onboarding. Indian startups that onboard well retain talent longer — particularly important given the competitive talent market in Bengaluru, Hyderabad, Pune, and Mumbai tech hubs.

• Day 1 wiki checklist: Company HQ → Getting Started → [Their Team] Home → Tool Access SOP → First Week Guide
• Each role should have a role-specific onboarding page: "30-60-90 Day Plan for a [Role] at [Company]"
• Include an FAQ for new hires: "What does [acronym] mean?", "Who do I talk to about X?", "Where is the office?", "How do I submit expenses?"
• Link from the offer letter and welcome email directly to the Getting Started page — the wiki is the first company touchpoint before Day 1

Corpfy's Knowledge Base is a structured company wiki — Browse, Write, Search, and Templates in one place — with 8 India-startup-specific templates pre-loaded and automatic stale-content detection (articles not updated in 90+ days are flagged). Natively connected to Decision Tracking (decision records auto-saved here) and Product Management (spec documents stored and searchable).

What you get in the dashboard