building the docs site

Gitbook was the obvious choice. It was fast to spin up, it handled versioning, the default output looked professional enough, and the crypto ecosystem had converged on it as a standard. If you needed docs in the first weeks of a protocol launch, Gitbook was the answer that required the least explanation to anyone on the team. The tradeoff was visible from the beginning but easy to defer: the docs site looked like every other Gitbook docs site. The navigation, the typography, the visual language — all inherited from a template that had been designed to work for everyone and therefore captured the specific character of no one.

The decision to rebuild in Hugo wasn't made because Gitbook stopped working. It was made because the protocol had developed a visual identity — specific typographic choices, a particular aesthetic in the interfaces and the product itself — and the docs site was the one surface that didn't participate in it. The site was functional but disconnected. Visitors who arrived from the product landed in a space that didn't continue the argument the product had been making. The docs documented. They didn't make a case.

The first site was fine. Looking back from the second one, it's clear the second was always where we should have been. The Hugo site felt more apropos — more considered, more aligned with what the protocol actually was, more exciting to navigate. The difference wasn't in the content, which was substantially the same. It was in whether the container believed in what it was holding. A docs site that has been designed to match the product communicates something about the team before the reader has processed a single sentence of documentation: that the people who built this cared about the whole surface, not just the parts that had direct technical function.

The lesson generalizes. The docs site is often treated as a pure utility — a necessary artifact, but not a product surface. That's a mistake that costs less than it seems in the short run and more than it seems once you're living with it. Every entry point into the product is an argument for the product. The docs site reaches developers, potential hires, curious observers, people deciding whether to build on the protocol. What it says before it says anything explicit — through its typography, its structure, its sense of considered design — is part of the argument. Gitbook says: we are a new protocol getting started. Hugo, done carefully, says: we have a point of view about what this should be, and that point of view extends all the way down to how we wrote the documentation.