This site has had two lives. First it was a hand-built Go static site generator. Then it moved to a Go CMS — one I wrote myself. This is the honest story of why, because it is the opposite of the usual "just use a static generator" advice.

What the static version got right

The static generator gave me three things I valued:

  1. Perfectly consistent design — every page rendered through one base template and one stylesheet. Content could not drift.
  2. Native calculators — data-driven tool pages that used the same tested Go math as the build, mirrored in JS for the browser.
  3. Free, fast hosting — push public/ anywhere, done.

For the first few articles, it was great.

Where it started to hurt

  • Adding content was a build pipeline. Write a Markdown file, run the generator, redeploy. Fine for me, painful the moment I want to publish from a web page.
  • Operational features became bolt-ons. Comments, analytics, ad slots, media, drafts, revisions — every one was something I would have to build into the generator myself.
  • The purity stopped paying for itself. Static is wonderful when the content is the whole product. Once you want a CMS's operations (drafts, media, comments, ad slots, scheduled publishing), you are rebuilding one.

Why a CMS — and why my own

A CMS gives the operations layer for free: a web editor, drafts, media, comments, ad slots, user management, sitemaps. But a generic CMS fights a site whose differentiator is data-driven calculators.

I wrote my own Go CMS, so I could have both: the operations of a CMS and the ability to add a tools subsystem that reads calculator definitions from YAML and renders them with the same tested math. Adding a calculator is now a config entry, not a code change.

The honest tradeoff

  • Cost: static was free to host; a CMS is a running service on a VPS. Modest, but real.
  • Speed: static pages are marginally faster. Go-rendered pages are fast enough that the difference rarely matters.
  • Maintenance: a CMS you wrote is maintenance you own. That is a feature if you want the control, a cost if you do not.

The rule I ended up with: if your site is articles with no operations needs, keep it static. The moment you want drafts, comments, media, ads, and a web editor — plus custom data-driven pages — a CMS earns its keep. Writing your own makes sense exactly when your differentiator lives in custom code, as the calculators do here.