why I built our internal wiki instead of buying one

For a while, our docs lived in three places. Workspace docs were in one location. Two of our product repos each had their own separate GitHub Pages site. Anyone on the team who needed to find something had to know which surface to check before they could even start looking.

The information drift was the predictable consequence. People stopped checking because the answer to "where is this documented" was often "I am not sure." When the cost of looking goes up, people guess instead. Guesses become assumptions. Assumptions become bugs.

I decided to fix it.

The build-versus-buy moment

The standard move at this point is to pay for a wiki. Notion, Confluence, GitBook, any of them. Paid tiers run from about $5 to $20 per seat per month depending on the vendor and the tier. Each takes a week to configure into something usable. Each locks you into a vendor whose roadmap is not yours.

I looked at our actual workflow and asked the question I now ask whenever a SaaS subscription comes up. What would this cost us to build on the stack we already use, and how does that compare to the cumulative cost of subscribing over a year?

In our case, we already run Next.js, Supabase, and Vercel for product work. The team is four people. The wiki only needs to do three things: federate docs from a handful of repos, gate access to the team, and let people search. None of that is differentiated work.

I built it instead.

What it actually is

The stack is Next.js, Supabase, and Vercel. Same tools we already use for everything else.

Docs federate from three sources at build time: the workspace docs repo and two of our product repos. When someone pushes documentation to any of those, the wiki rebuilds and pulls the latest. Nobody has to remember to copy anything anywhere. The docs live where the work lives. The wiki is just the surface.

Access is gated by magic-link login. Four invites for four people. Search runs locally via Pagefind, indexed at build time. No external services in the loop after the build runs.

Two pieces of texture worth mentioning. First, the wiki renders Mermaid diagrams with proper fit, zoom, pan, and fullscreen controls. We use Mermaid heavily across our planning. Most wiki tools render Mermaid as a thumbnail you cannot zoom into. Ours treats diagrams as first-class content because that is how we actually use them. Second, the whole thing is themed in our NORD palette. Internal tools deserve the same care as client work. Looking at something well-designed every day costs nothing extra to build and changes how the team feels about the tool.

Total time from decision to production: about a week.

Why this matters

The principle I keep coming back to is: minimize SaaS dependencies.

Pay for differentiated value. Pay for things you cannot build, or that are not worth your time to build, or where the vendor is genuinely better at it than you would be. Stripe, for example. Linear, in our case.

Do not pay for things the stack you already run does. Do not pay for "we have a place to put docs" when "a place to put docs" is a build that takes a week. Take the middle of that range. $10 per seat per month, four people, twelve months, is $480 a year. The build I am describing took about a week of my time. At the end of the year, the build is mine. The subscription is still recurring.

The other thing you get from building, which is harder to put a number on, is that the tool fits your workflow. Generic wiki tools are designed for the average team. Your team is not the average team. Building means the tool can know what your repos are, how your docs are organized, what your design language is, and what your team actually does with diagrams. None of that is possible with a generic subscription.

When this calculus flips

I am not arguing against SaaS. I run on SaaS for plenty of things. The point is to ask the question every time, instead of defaulting to subscribe.

Build the thing yourself when:

• The capability is generic (storage, display, search) and you already have the stack.
• The team is small enough that per-seat pricing is most of the cost.
• The vendor's roadmap is not aligned with your specific needs.

Subscribe when:

• The vendor is doing work you genuinely cannot replicate (payment processing, transcription, model hosting).
• Switching cost later is low because the data is portable.
• You need the tool live in a day, not a week.

This is the kind of internal-tooling work we take on for clients who realize their stack already does most of what they are paying a SaaS for. The math usually surprises them.