Rolling Your Own: How This Site Gets Built

From a WordPress Install to Twenty-Five Kilobytes of Intent

This site used to be a WordPress installation. Like most WordPress installations, it spent the majority of its life doing nothing — waiting for a monthly blog post while dutifully running a database, a PHP runtime, a theme framework, and a plugin update treadmill. The site you are reading now is the opposite of that: custom HTML, a folder of markdown files, and one small purpose-built program that assembles them. This post walks through how it was made, and why the obvious answer — “just use Hugo” — turned out not to be the answer at all.

Step One: Convert the Wordpress pages to static content.

The rebuild started with the boring part. Every page you can navigate to — the homepage, the styles, and the contact form — was rewritten into plain HTML and CSS, plus one small PHP script for the form, matched against the old theme until the two were indistinguishable. No template framework. A static site is mostly static; it seems obvious once said out loud, but most tooling refuses to believe it.

That left a short list of things that genuinely are dynamic:

• The blog posts themselves, written in markdown and rendered to HTML.
• The list of recent posts on the homepage.
• Responsive image variants, resized once at publish time instead of shipped at full size.
• The RSS feed.

Four features. That list matters, because it is the entire requirements document.

Step Two: Write the Spec, Not the Code

The second step was a written specification — a few pages describing exactly those four features, the content model, the failure behavior, and just as importantly, the non-goals: no themes, no tags, no pagination, no plugins. The spec also pinned down the operational shape: the server polls the repository and rebuilds itself, so nothing on the internet holds a credential to the host, and a broken build leaves the old site serving untouched.

Then an AI coding tool turned that spec into a working program: a single Go binary with a test suite, continuous validation on every push, and a systemd timer to publish. The interesting part is not that the AI wrote the code — it is that the spec was short enough to be completely written, reviewed, and understood. Four features fit in a person’s head.

The Case for Hugo

Be clear about what the established tools offer, because it is substantial:

• Longevity through community. Hugo has existed for over a decade, survives its maintainers’ attention spans, and will still build your site in ten years.
• Someone else fixed it already. Every edge case — draft handling, feeds, image processing — has been hit by thousands of users before you.
• Documentation and answers. Your problem is a search away.

For a site with taxonomies, multilingual content, hundreds of pages, or several authors, that maturity is decisive. Nothing bespoke competes with it, AI-assisted or not.

The Case Against, for a Site Like This One

The cost of a general-purpose tool is that it is general. Using Hugo for four features means adopting its theme layer, its configuration surface, its directory conventions, and its release cadence — thousands of options standing guard around the four you use. The practical consequences show up slowly:

• Upgrades become events. A template function deprecates, a theme breaks, and a site you meant to ignore for a year demands an afternoon.
• The mental model erodes. Nearly two years between posts is enough to forget how the tool’s abstractions map onto your site.
• Every feature you don’t use is still yours to carry. Not in bytes — in documentation you must skim past and behavior you must rule out when something goes wrong.

The bespoke tool inverts every one of those. It has no site features beyond the four required, so there is nothing to deprecate. It is a couple of thousand lines of plain code that can be reread in an evening. It compiles to one static binary that will run unchanged after every OS upgrade until the architecture itself dies.

What AI Actually Changed

The trade-off between “use a framework” and “roll your own” is ancient, and rolling your own traditionally lost for one reason: the build cost was enormous and fell entirely on you. That is the variable that has changed. When a working, tested implementation of a well-specified tool costs an afternoon instead of a month, the calculus tips — not for everything, but for problems that are small, stable, and fully understood.

The discipline that makes it work is the same one that makes whiteboards work: ruthless simplification first. The AI did not decide what to build; the spec did. An AI pointed at a vague wish produces a vague application, and a bespoke tool you don’t understand is strictly worse than a popular tool you don’t understand — at least the popular one has a community. The sequence matters: shrink the problem until you can hold it, write down exactly what remains, and only then generate the code. Owning the tool means owning its maintenance; the goal is to have almost nothing to maintain.

Feasibility, Long Term

So are open source generators like Hugo still the sensible default? For most people, most of the time — yes. The community is the feature, and it is a feature no bespoke tool has. But the niche where rolling your own wins has widened considerably, and this site now lives in it: a stable, minimal problem, a complete spec, code plain enough to read over SSH, and a publish pipeline with no moving parts you didn’t choose.

The whiteboard lesson applies to tooling, too: start with the least sophisticated thing that works, and let the pain argue for the upgrade. Most of the time, it never arrives.