Two releases in, and I have not touched the demo content once

September 21, 2026resolves JRN 26-019

The demo content is not a placeholder to delete. It is the test fixture.

I want to show you something that went right, because I’ve spent most of this journal so far writing down things that broke.

Pulse is a new Hugo theme — the design layer for status26.com, where Spectrum is the one this site runs on. Two releases in as of this morning. And here is the thing I’m pleased about:

Every word on that page came out of the generator. “My New Hugo Project” is the default title. Post 3, Post 2, Post 1 and all that lorem ipsum are the sample posts hugo new theme writes for you. I have not edited a single character of it.

What I’d normally have done

Started by deleting it.

That’s the reflex, right? You scaffold a project, the generator leaves you a pile of obviously fake placeholder junk, and step one is clearing it out so you can put something real in. I’ve done that on every project I can remember. The sample content is embarrassing — it’s got lorem ipsum in it — and getting rid of it feels like the first honest bit of work.

Which is exactly backwards, and I only noticed because this time I didn’t get round to it.

Two releases, and what was actually in them

v0.0.0 was the boring one, and it shipped the generator’s output untouched. Thirteen layout files, six content files, four stylesheets, all straight from hugo new theme. The only things I wrote by hand were the things the generator doesn’t give you: a CONTRIBUTING.md fixing Conventional Commits as the standard, Release Please wired up to read those commits and cut versions from them, and a netlify.toml.

So release zero contains no design and no content. It’s the conventions and the machinery, committed on top of a scaffold nobody touched.

v0.1.0 was the design pass. Fourteen layouts, fourteen stylesheets, tokens, dark mode, a theme toggle, a numbered index.

Content files changed: zero.

That last command asks git what changed inside content/ between the two releases. It prints nothing, because nothing did.

Two releases in, and the demo content has never been edited.

Why this turns out to matter

The sample content isn’t a placeholder. It’s a test fixture, and it’s a better one than anything I’d have written myself.

Think about what’s in it. A post with a long title and a post with a short one. Three posts, so the index has to handle a list rather than one row. Dates in different months, so the date column has to align. Tags, so the taxonomy pages have something to render. A page with body copy long enough to wrap and reveal your line-height. Someone thought about that set.

If I’d deleted it and written “Test Post” three times, I’d have built a theme that looks fine on my three identical fake posts and falls over on a real one. Because I left it alone, every layout got exercised by content I didn’t design for, which is the only kind of test that tells you anything.

And the second benefit is the one I’ll actually feel later. Because content and presentation never mixed in the same commit, the history reads cleanly: a commit that changes only assets/ and layouts/ cannot have broken the content, and a future commit that changes only content/ cannot have broken the design. The diff tells the truth about what a change could possibly have affected.

What this is for, outside Hugo

Whatever your generator hands you, look at it before you throw it away. Somebody who had built the thing many times chose that example, and the choice usually encodes the edge cases they got tired of hitting.

More generally: the fake data you’d write yourself is shaped like your assumptions. That’s the whole problem with it. Real-shaped input you didn’t choose — the awkward invoice, the customer with no surname, the three sample posts with unhelpfully different title lengths — is the only thing that pushes back on you.

Keep the ugly fixture. Style around it. Delete it last, if ever.

Next: Netlify, if Netlify is willing

The deploy config has been sitting in the repo since release zero. Everything is ready to go live.

Errors accessing Netlify-hosted sites. Investigating. Posted at 15:12 UTC — which, going back through the timestamps, was already live while I was cutting v0.1.0 at 15:39. The outage and the release were happening at the same time and neither knew about the other.

The incident record runs eighty-five minutes:

I was writing this section at 16:37, which is a slightly absurd thing to discover mid-sentence. Checked it rather than assumed: a Netlify-hosted site returns 200 again. So the blocker is gone, and the only lasting artefact of it is this entry.

This is a species of blocker I have no clever response to, and I want to record how unfamiliar that is. Everything else in this journal has turned out to be my fault on inspection — the unsaved buffer, the impossible CSS rule, the config directory nothing reads, the screenshot of a bug that didn’t exist. I’ve built up a reflex that says when something doesn’t work, you did it. It’s served me well.

And then occasionally the honest answer is: the build is fine, the config is fine, and somebody else’s engineering team is actively investigating.

The thing worth keeping from a day when the blocker is on somebody else’s status page: write down that you checked, and link the record. Not for anyone else — for the version of you who comes back in a month, finds an undeployed theme, and assumes it was something you forgot to do. A permalink and a timestamp settle in four seconds an argument you would otherwise have with yourself for twenty minutes.

Deploy’s unblocked. That’s tomorrow’s entry.