This page is the pillar. It describes the system that produces XD Studio Lab, and it is the same system I build for clients who publish regularly and do not want to maintain a CMS.

Problem

A traditional CMS solves a real problem: non-technical people need to publish. It creates three new ones. It needs patching, it needs a database, and it makes performance someone’s ongoing job. For a publication with one author and a few hundred articles, that trade is bad.

Context

The requirements are simple and slightly unfashionable: fast pages, no dashboard, no plugin updates, no monthly security chore, and the ability to write in a desktop editor on a plane. That points at a static site, which in practice means a generator plus a deployment pipeline.

My System

Typora

My preferred environment for distraction-free Markdown writing.

Details

Hugo

The static site generator that carries this entire publication.

Details

GitHub

Version history, deployment trigger and safety net for every article.

Details

Cloudflare

Pages for deployment, R2 for assets. Cheap, fast, boring in a good way.

Details

Workflow

  1. Write in Typora. Markdown files, one per article, front matter filled at the top. Typora renders as I type and never shows me a settings panel.
  2. Preview locally. hugo server rebuilds in milliseconds, so I check the real templates rather than a Markdown preview.
  3. Commit and push. Every article is a commit. The git log doubles as an editorial history, and a bad decision is reversible in one command.
  4. Deploy on push. Cloudflare Pages builds the site and publishes it. No FTP, no manual build, no forgotten step.
  5. Search separately. Pagefind indexes the built HTML after the build and produces a static index. No search service, no API key.
# the entire deployment routine
hugo --minify
npx pagefind --site public
git add -A && git commit -m "article: zero-cms stack" && git push

Why It Works

  • Performance is structural. HTML files on a CDN beat any dynamically rendered page. There is no query to optimise.
  • Maintenance approaches zero. No database, no plugins, no patch Tuesday.
  • Content is portable. Markdown in a git repository outlives any generator. Switching tools later is a template job, not a migration project.
  • Failure is boring. If the build breaks, the previous deploy is still serving. Nobody is locked out of a dashboard.

What works well

  • Pages load from a CDN with no database round trip
  • Content is plain text in git and portable for decades
  • No plugin or security update cycle
  • Hugo builds a 300-page site in under a second

What does not

  • No browser-based editor for non-technical contributors
  • Preview environments need Cloudflare or a second host
  • Anything dynamic needs a third-party service
  • New authors must learn Markdown and git

Limitations

This stack is wrong for multi-author newsrooms, paywalled content, or anything requiring user accounts. It is also wrong if the person publishing will not touch a terminal. I have made that mistake once: the client loved the result and never wrote a second article.

Improvements

Two things are on the list. The first is an image pipeline that generates responsive formats at build time instead of relying on my discipline. The second is a scheduled build that republishes updated “lastmod” dates so evergreen pages stay fresh without a manual push.

Xiaodong Wang
Xiaodong Wang
Founder & Writer · XD Studio Lab
Publishing Hugo Writing Web Production GitHub

Related reading

All