Why we moved our own site off the CMS

A friend’s site got compromised recently - not through anything clever, just an unpatched plugin. Cleaning it up took longer than building the site in the first place.

That made us look at our own CMS install: a handful of plugins, a theme, a contact form. Exactly the surface automated scanners pick apart within hours of a CVE going public. Did a mostly-static site - About, Services, Contact - really need an application runtime, a database, and an admin login? No.

What we did

We rebuilt on Hugo: static HTML, generated at build time, served off disk. No app server, no database, no admin panel, no plugins to patch.

The whole rebuild took less than two working days, with an LLM handling most of the first-draft layout and CSS.

A few things needed solving:

• Contact form - posts to a SaaS form handler instead of a server-side mail script.
• Analytics - self-hosted, no tracking cookies, no cookie banner.
• Content editing - Markdown files in git instead of a database and admin UI. Every change is a reviewable diff.

What disappeared

• The application runtime and its patch treadmill.
• The database, and SQL-injection/backup concerns with it.
• The admin login as a permanent credential-stuffing target.
• The monthly plugin-update ritual.

What we gained

Fast pages - just files, no per-request computation. No cookies, so no cookie banner. And the attack surface is now “a static file server.”

We also stopped hunting for a plugin every time we needed a different layout - we just write it, with an LLM doing the first pass.

Some older blog posts and landing pages are still queued for migration, but the core site is off the CMS for good.

The bigger point

Same advice we’d give a client running a brochure site on a CMS: weigh the cost of migrating to a static site against the cost of ongoing patching - or of getting compromised.