Why we picked Hugo for this site

We rebuilt this site this spring. The brief was short: it should be fast, it should be easy to edit, and it should look like us — not like a theme we bought. We picked Hugo and don’t regret it.

What we wanted to avoid

Three things, all from prior experience:

• A CMS we’d need to keep alive. WordPress, Strapi, Ghost — all great, none of them want to be ignored for a year.
• A JS framework for a content site. Next.js can absolutely render a marketing page, but we’d be paying its tax forever.
• Themes. Buying a theme means shipping someone else’s design language. We wanted to derive ours from the actual work.

What we got

A handful of HTML templates, a content/ directory of Markdown, and a single hugo command that produces a static directory. The whole site builds in under 50 ms on a laptop.

$ hugo --gc --minify
                   | EN
-------------------+-----
  Pages            |  12
  Static files     |  9
Total in 18 ms

Editing happens in any editor that opens Markdown. Deploys are a file copy. There is no database.

The design system

The CSS is split into a foundation layer (reset, layout, components, accessibility) and two theme files that define the colour, type and decorative tokens — one light/editorial, one dark/technical. The active theme is selected per section: marketing pages use Atelier, these notes use Terminal. Same markup, two voices.

We were tempted to ship a single look. Two felt more honest: we do have two audiences (teachers using Klassenwerk, developers using the tools), and pretending there was one would have meant compromising both. Section-bound themes solve it without a JavaScript toggle for the reader to manage.