> I think few people would argue that the upfront cost of rolling your own docs site could possibly be lower than the cost of deploying an off-the-shelf solution like Hugo.

I'm not convinced. At some point, you will have to debug something weird in your docs system.

If you deploy Hugo, that means understanding Go. Docusaurus--Javascript, Node, and that entire ecosystem. With this, it's Zig all the way down.

Zig users tend to be (possibly notoriously) anti-dependency.

For a docs site with no special requirements, I'd be surprised if Hugo or another SSG can't do what they need out of the box. So, it's the cost of implementing your own SSG vs. the cost of figuring out how to use an existing one.

Also, just as a datapoint, I've been using Hugo on multiple sites for about five years, and I don't recall ever having to drop into Go to fix an issue. Hugo might be unique in this regard, as it ships as a single-file binary. You have to learn Go templates, but you don't have to learn anything about Go the language or standard library.

Before Go, I used Jekyll, and I don't recall ever having to learn Ruby, but I did have to work within the Ruby ecosystem because Jekyll required a Ruby environment.

Incidentally, TigerBeetle seems to have rolled their own rudimentary templating language, too.[0] I think that has potential to either limit the functionality they need or cause a lot of bugs.

[0] https://github.com/tigerbeetle/tigerbeetle/blob/0.16.29/src/...

> Zig users tend to be (possibly notoriously) anti-dependency.

I don't get anti-dependency, to be honest. Like say you want REGEX support in your database. You code a REGEX parser from scratch? What are the odds your parser doesn't have a vulnerability?

I think over zealous dependency usage is also bad, but it cuts both ways