How I Built This Website

Printed books traditionally close with a colophon, a short note on how the thing was made: the typefaces, the paper, the press. I think websites deserve the same courtesy. This one brings my writing and speaking together in one place, and this page is its colophon: the stack, the design decisions, and the principles behind the build, written for the curious and for anyone weighing a similar build of their own.

The first version was a static Hugo site too, born of hard lessons from my previous WordPress sites that spent their lives being knocked over by DDoS attacks. I started writing my own generator in Perl (I’m a classically trained Software Engineer afterall), realised after a couple of weeks that better options existed, and settled on Hugo. That build served me well for almost three years. What you’re reading now is its successor, rebuilt from the ground up in June and July 2026.

The goals haven’t changed much, though the bar has risen:

1. Respect the reader’s privacy: collect the minimum, keep it first-party, and give no data to third parties
2. Score above 90% on usability, accessibility, best practice, and SEO
3. Be easy to maintain and update from any device: MacBook, iPad, or iPhone
4. Stay static, so there is nothing to bring down and nothing to patch on a Sunday
5. Carry a custom design that one person can maintain
6. Ship clean, semantic HTML with not a single class attribute in the markup
7. Self-host everything: fonts, styles, and scripts, with no third-party CDNs
8. Work without JavaScript, but get better with it
9. Support Schema.org, OpenGraph, and everything else that helps search engines and AI systems read the site properly

The design

The design started life as a static prototype: every page type built as plain HTML and CSS, reviewed one change at a time, and refined until it was signed off as the design contract. Only then was it cut into a Hugo theme, with an automated probe comparing the rendered output of every template against its prototype, element by element, so nothing drifted in translation.

The typefaces are Fraunces for headings, Hanken Grotesk for text and interface, and Space Mono for the small print, all subset and served from this domain. The stylesheet is classless: styling hangs off semantic elements, attributes, and ARIA states rather than class names, an approach I first tried on the previous build and liked enough to keep. Behaviour is a set of small Alpine.js components applied as progressive enhancement, so every page works with JavaScript switched off and improves with it on.

Hosting the website

The site lives in a Git repository, which lets me track changes between versions and undo anything I break. Hugo builds the static site and deploys it to an Amazon S3 bucket fronted by a CloudFront distribution with an SSL certificate. The domain, mariothomas.com, is hosted in Amazon Route 53.

Sometimes I write things on the move, so publishing has to work from anywhere: I commit from my iPad or iPhone using SourceTree, and when a deployable version reaches the Git repository, a small always-on machine picks it up and deploys the site automatically.

Analytics are first-party and minimal: my own collector, built and hosted by me, with nothing shared and no third-party trackers on the page.

Built for machines as well as people

An increasing share of this site’s readers aren’t people. Every page publishes a plain-markdown alternate alongside its HTML, the whole site is summarised for language models in llms.txt and llms-full.txt, and structured data describes each page in Schema.org terms. AI crawlers are explicitly welcomed in robots.txt rather than blocked. If an AI system is going to answer someone’s question with my work, I’d rather it read the source properly.

Use of generative AI on this website

The ideas, arguments, experiences, frameworks, and editorial judgement in the writing on this site are my own. When other authors contribute, they are appropriately cited.

I use generative AI extensively as part of my writing and research process, but not as a single-model writing tool. I have built a multi-model editorial system that combines ChatGPT, Claude, Grok, models accessed through Amazon Bedrock, and GPT-OSS models running locally on an NVIDIA DGX Spark.

Behind those models sits a knowledge architecture built around my own work. My published writing, research, frameworks, principles, glossary, editorial guidance, and developing ideas form a structured corpus connected through an ontology, knowledge graph, and semantic layer. A retrieval-augmented pipeline uses that context to bring the right parts of the corpus into the writing process, rather than asking a model to work from a blank prompt or its general training alone. The aim is not simply to give an AI more information. It is to give it the relationships, terminology, provenance, and intellectual context that make the information meaningful.

Different models play different roles within that system. I use them to explore ideas, challenge arguments, interrogate sources, test assumptions, surface contradictions, make connections across previous work, structure drafts, critique prose, and work through revisions. Some are better researchers, some better critics, some better at synthesis, and some are useful precisely because they disagree with the others. They may also contribute wording.

The process is intentionally iterative. I bring the underlying ideas, experiences, questions, and points of view. The models encounter those ideas in the context of a body of work that already has its own language, concepts, and history. They challenge, extend, connect, or sometimes reject what I give them. I decide what is persuasive, what is wrong, what is genuinely new, what sounds like me, and what survives into publication.

No single model writes the finished article autonomously. The work moves between human judgement and machine contribution, between frontier and open models, between cloud and local compute, and through a knowledge layer designed around my own intellectual corpus. I edit and approve every article published under my name and remain accountable for its arguments, claims, and conclusions.

Some images are generated using AI. Where this is the case, the alt text references the specific model used.

Audio editions of some articles are narrated using a synthetic voice cloned from my own voice using ElevenLabs. The voice is mine; the synthesis is automated when I cannot get to a studio to record in person. The content of each audio edition is identical to the published article.

The website itself was also built in collaboration with AI. I designed and directed the implementation using many of the same models, knowledge systems, and environments described above, with AI contributing code, templates, tooling, analysis, and review under my direction. The architecture, design decisions, and final implementation remain my responsibility.