02The story
Why it exists in this stack
I sell WordPress work, so the obvious move was to build this in WordPress. I built it in Nuxt instead, for one reason: the modern-stack half of what I do needed something public that could be inspected rather than described.
It is a small site with a lot of engineering underneath it, which is roughly the argument.
The decisions
Prerendered, not server-rendered. Every page is HTML on a CDN before anyone asks for it. One server route survives, for the contact form, because that is the only thing on the site that genuinely needs a server.
A budget that fails the build. The JavaScript budget is 130KB gzipped and it is checked as part of the production build, not admired in a readme. The homepage currently ships about 104KB.
Content as typed data, not as pages. Every project, post, capability and timeline entry is validated against a schema at build time — required alt text, required image dimensions, no capability listed under two headings. A file that does not validate stops the build rather than rendering an empty section.
An accessibility guard in the same place. Heading order, one h1 and one
main per page, alt text, image dimensions, labels. It is cheaper to enforce
than to audit.
Constraints I set myself
No animation library, no component library, no analytics with a consent banner attached. Two typefaces. One accent colour. Every interaction on the site is one of six named CSS moves, each with a keyboard-focus equivalent, and none of them animate a layout property.
The sound effects are synthesised in about forty lines of Web Audio rather than downloaded, so the site ships no audio files at all.
What it is not
It is not a demonstration that Nuxt is better than WordPress. Half the sites I build would be worse in this stack, because their owners need to edit them on a Tuesday afternoon without calling anybody.
It is a demonstration that I can hold a build to a standard when there is no client asking me to.
