Why We Built a Faster Wiki
I first tried to build a wiki in 2010. Working prototype, decent idea, abandoned prematurely. Sixteen years later, the market has barely moved. The tools got heavier, the page loads got slower, and everyone just... accepted it.
I didn't accept it. So I built Raccoon Page.
The problem nobody fixed
Here's what happens in most companies: someone writes documentation. It goes into the wiki. A week later, a new hire needs that documentation. They open the wiki. They wait. The page loads in three, four, five seconds. They try search. The results are irrelevant. They close the tab and walk over to a coworker's desk.
The wiki is now a graveyard. The knowledge is there, technically, but nobody uses it because the tool is slower than asking Dave.
This isn't a people problem. It's a tools problem. And it affects more than just software teams — every industry that relies on documentation feels this. Financial analysts looking up compliance docs during live calls. Operations managers referencing SOPs in a warehouse on a mediocre tablet. Support agents pulling up knowledge articles while a customer waits in silence.
The wiki market has been stagnant for fifteen years. The dominant tools are either slow and enterprise-bloated, or flexible-but-sluggish all-in-one workspaces that treat the wiki as an afterthought. Nobody shipped a wiki that's both fast and pleasant to use.
What Raccoon Page is
Raccoon Page is a wiki. Not a workspace, not a database, not a project management tool that also has pages. A wiki. It does what your current wiki does — pages, hierarchy, search, comments, version history, permissions — except it doesn't waste your time doing it.
Pages load near-instantly. There are no spinners on basic navigation. Search is fast and typo-tolerant. If you're a keyboard person, there's a command palette, shortcuts for everything, and slash commands in the editor. If you're not a keyboard person, it's still just a clean, fast wiki — no learning curve required.
The speed isn't an accident. It's the first architectural decision I made and the one that shaped everything after it. PostgreSQL with careful query design instead of an ORM that generates page-long joins. Server-side rendering of the critical path. No client-side data fetching waterfalls on page load. Every technical choice was filtered through: "Does this keep the page load fast?"
Why import matters more than features
I've watched enough SaaS launches to know the pattern: team evaluates new tool, likes it, starts a trial, realizes migrating their existing content would take weeks, abandons the trial. The switching cost kills adoption, not the product quality.
So I built import before I built templates, before threaded comments, before half the features on my roadmap. Raccoon Page imports from Confluence (XML export), Notion (Markdown/CSV export), and Obsidian (vault zip). The whole process takes about ten minutes for a typical team wiki. You also export to Obsidian-compatible Markdown, so you're never locked in.
This was originally a month-two feature. I moved it to launch because I realized the import story changes the entire sales pitch. It's not "try our wiki and rebuild your content." It's "bring your content and see it load faster."
What we built, what we deferred
Real-time co-editing shipped at launch. Multiple people can work on the same page simultaneously — cursors, selections, and edits all sync live. This was originally deferred, but we pulled it forward because every competitor has it and it's table-stakes for team adoption. No whiteboards yet — that's still on the roadmap.
Authentication supports both email/password and OAuth (Google, GitHub), so your team can sign in the way they already work. Dark theme is the default, with a light mode toggle for those who prefer it.
There's no AI search yet. I deliberately deferred it. AI-powered search sounds impressive in a feature matrix, but it costs real money per query — money that eats margin at $8/user/month. Raccoon Page ships with PostgreSQL full-text search that's fast and actually works. AI synthesis will come later as a premium feature, once there's revenue to fund it.
There are no Slack integrations, no API, no SAML SSO. All planned. None necessary for the first ten teams to get value.
Every feature we shipped or deferred was a deliberate trade. The filter was simple: does it reduce churn, drive conversion, or remove a barrier to adoption? If not, it can wait.
The honest competitive picture
Confluence is the market leader and it deserves respect. Deep Jira integration, enterprise compliance, decades of trust. If your organization runs on Jira and has a formal procurement process, Confluence is probably staying. I'm not here for that fight.
Notion is beautiful and flexible. If you need a workspace that does everything — databases, projects, docs, wikis — Notion is genuinely good at being everything. It's less good at being a fast wiki specifically, and the performance at scale is a known pain point, but it earns its 100 million users.
Outline is the closest thing to what I'm building — open-source, fast, clean. If you want to self-host your wiki and have the infrastructure skills to do it, Outline is a solid choice. Raccoon Page is for teams who want the speed without the operational overhead — managed SaaS, one-click import, ready to go.
I'm not building the wiki for everyone. I'm building it for teams where the documentation is supposed to help but the tool gets in the way instead.
The boring technical details (for those who care)
The backend is C# on .NET, which surprises people who expect a wiki startup to be written in TypeScript or Go. I have eight years of Go experience and chose C# anyway — better AI code generation quality, a richer type system for the kind of dynamic content a wiki handles, and a more stable package ecosystem. The right tool for the job isn't always the familiar one.
The editor is TipTap, built on ProseMirror. Headless, extensible, battle-tested. Headings, lists, code blocks with syntax highlighting, callouts, tables, images, slash commands. It's not trying to be Google Docs — it's trying to be a good wiki editor that stays out of the way.
The database is PostgreSQL. Not because it's trendy, but because 80% of a wiki's data model is relational (users, permissions, spaces, memberships) and the remaining 20% (page content) fits perfectly in JSONB columns. MongoDB would have meant reinventing relational integrity for the majority of the schema.
The whole thing runs on DigitalOcean for about $100/month. No Kubernetes cluster, no microservices, no distributed systems. One process, one database, one server. It's enough for thousands of users and it's simple enough for one person to operate at 3 AM when something breaks.
A small team, one bet
We're two co-founders. No funding, no investors. The code is roughly 80-90% generated by AI (Claude Code, specifically), which is the only reason a tiny team can ship a full-featured wiki in a few months. I write the architecture and make the technical decisions. My co-founder handles testing, and increasingly the legal and marketing side. The AI writes the bulk of the implementation. It's a force multiplier that didn't exist when I first tried this in 2010.
This is a bootstrapped bet with a 12-18 month competitive window. AI-native wiki tools are coming — probably dozens of them. The question is whether a fast, focused, well-imported wiki can establish a foothold before the market gets crowded.
We think it can. Not because the technology is revolutionary, but because the problem is so obvious and so neglected that even a competent solution wins. Your wiki should not be slower than asking a coworker. That's it. That's the whole pitch.
Try it
Raccoon Page is live at raccoon.page. Free tier: 3 users, 1 space, 100 pages. Enough to decide if speed matters to you.
If you're on Confluence, Notion, or Obsidian, bring your content. A typical team wiki imports in about ten minutes. See your own pages load fast, not a demo with cherry-picked content.
If it's not for you, the export button is right there. No lock-in, no tricks.