The day the wiki decision stops being about taste
Here is the scene I walk into roughly once a quarter. A B2B SaaS company has crossed $15M ARR. The new VP of Operations opens the company "knowledge base" and finds the product spec for the current release in a Google Doc owned by a PM who left in 2024, the API authentication flow described in a pinned Slack thread, the on-call escalation policy living in someone's Notion personal space, and a Confluence instance that engineering set up in year two and abandoned in year three. Four sources of truth, zero of them trusted. Onboarding a new hire takes three weeks of asking around.
The cost of this is not vague. McKinsey's research on the social economy found knowledge workers spend close to a full day each week just hunting for information. At a 100-person software company carrying a typical loaded salary, that lost day is a low-seven-figure line item you never see on a P&L because it hides inside everyone's billable time. You are not paying it to a vendor. You are paying it to entropy.
What makes this a real decision—rather than an IT ticket—is that for a SaaS business, the documentation IS part of the asset. When you sell, a buyer's technical diligence team is going to ask for your architecture decision records, your data-handling procedures, your incident postmortems, and your runbooks. The condition of your documentation directly moves your valuation. So the choice between Confluence, Notion, and a custom Docs-as-Code stack is not a stylistic preference. It is a bet on whether your operational memory survives scrutiny.
Notion scales beautifully until it doesn't, and Confluence is ugly until it matters
Let me be fair to Notion, because I like it. Under 50 people, its block model is genuinely a force multiplier: one workspace holds your handbook, your roadmap, and your meeting notes, all cross-linked, all editable by anyone. That openness is the feature. The problem is that the exact property that makes Notion great at 40 people—anyone can spin up a database, anyone can restructure a page—is what eats it alive at 150. Departments fork their own nested databases, someone duplicates a "source of truth" view to tweak it for a meeting, and six months later nobody can tell which version of the security policy is canonical.
The market has already voted on where Notion lives. G2's comparison data shows the overwhelming majority of Notion users are small businesses, with only a thin single-digit slice in the enterprise segment. That is not a knock on the product; it is a signal about which problems it was built to solve. When you hand a diligence team a Notion workspace, the recurring failure I see is the absence of an auditable trail—because pages can be freely duplicated and reshaped, "who approved this and when" is often unanswerable.
Confluence is the opposite trade. Engineers hate the editor; I have never met one who didn't. But it enforces hierarchy, ships with group-based permissions, and binds documentation to Jira work natively—which is why Atlassian tools are entrenched across the Fortune 500. When an auditor asks for proof of your incident-response protocol, Confluence hands back a version-controlled, timestamped page instead of a shrug. Its native failure mode is the other extreme: it becomes a graveyard. Highly structured spaces full of deprecated specs that nobody prunes and nobody can find by search. The 2026 escape hatch is AI retrieval layered on top—Gartner projects the large majority of organizations will be running AI-powered knowledge retrieval by year-end, and tools like Atlassian's Rovo agents are aimed squarely at turning a dead archive into something that can actually answer "how do we rotate a leaked key" across tickets and docs. Confluence's discipline is the point; the AI overlay is what makes that discipline livable. By the time you reach diligence, your architecture documentation has to be centralized, versioned, and auditable—and Confluence forces that whether your team likes it or not.
The custom stack is the seductive one—kill it anyway
The third option always arrives wrapped in a strong engineering argument. Your best senior engineers want to build it themselves: Markdown files in the repo, reviewed through pull requests, published with Docusaurus or Hugo. Docs live next to code, version with code, ship with code. It is intellectually clean and, for a pure engineering org, occasionally right.
For a B2B SaaS company, it is a trap, and the reason is one sentence: your sales reps, CSMs, and HR coordinators do not write Markdown and will never open a pull request. The moment your knowledge base requires a Git workflow to contribute, you have not built one knowledge base—you have built an engineering wiki and silently exiled every other function back to Google Docs and Slack. Now you have the fragmentation problem you started with, plus a static-site generator to maintain. The maintenance is not free either; for a mid-market firm I'd put the fully loaded cost of senior engineers babysitting an internal docs toolchain in the low-six-figures a year—real product-roadmap capacity spent debugging a build pipeline that ships zero customer value.
So here is the decision, made simple. Three buckets, one question each. Under ~50 people and not raising institutional capital soon? Notion is fine—enjoy it, and revisit before your next round. Crossing $15M ARR, multiple functions writing docs, an exit on a 24-to-36-month horizon? Confluence, with hierarchical permissions turned on from day one and an AI retrieval layer to keep it out of the graveyard. Tempted by Docs-as-Code? Allow it only for API reference and developer-facing docs that genuinely belong next to the code—never as the company's operational system of record. The goal was never a pretty wiki. Moving from tribal knowledge to turnkey operations means building an asset a buyer can audit. On Monday, do one thing: list your top ten "if this person quit, we'd be in trouble" processes and find out which of the four scattered places each one actually lives. That inventory tells you exactly how exposed you are.
