How this website is built and tested

The template system in one picture

The site has no server-side code at runtime. I write small templates for the head, the menu and the footer, and a Markdown file for each content page. One build script turns them into plain HTML files. Those files are what visitors get.

Menu and footer links live in one data file, so every page gets the same navigation. A page that is not linked from the menu or the footer fails the build. This public roadmap comes from one data file too.

Quality gates

I ask the AI agents for speed and I keep the gates for safety. Nothing ships without these checks.

• Byte parity. Six hand-written pages (home, privacy, terms, the demo hub, its privacy page and the API docs) must build byte for byte the same as a golden baseline. If one byte changes without my say-so, the check stops the release.
• Pixel diff. A page I touch is compared with the old one at 1440, 768 and 390 pixels wide, in light and dark. The difference should be zero except where I meant to change something.
• Behaviour tests. Scripts drive a real browser to test consent, the burger menu, cross-page navigation and the content layouts. The content test opens 20 pages at 1440 and 390 pixels and checks for errors, broken images, sideways scrolling and valid structured data.
• Link crawl and lint. Every internal link must resolve. Titles, descriptions, canonical tags, alt text and image sizes are linted on every build.
• Dry runs. Each group of pages is built once in a temporary folder with the group marked as published, and the same lint runs there. Nothing on disk changes.

Before and after

Each pair below is a real step. The first moved the content pages onto the style of the demo hub. The second did the same for a note, and moved the mascot into the hero.

BeforeAfter

BeforeAfter

Reversible releases

A release is a short, fixed routine.

1. The build and every check must pass. The release tool refuses to run without a fresh pass.
2. A dry run shows the exact list of files that will change.
3. The tool takes a backup of what it is about to replace.
4. It pushes the files and checks the live pages. If a check fails, it rolls back by itself.
5. If I find a problem later, one command puts the previous version back.

After a release I open the changed pages on the live site and check the status and the text. I also check that the home page and the demo hub still load.

The SEO checklist, done on this site

These are the steps I applied here. They remove problems. They do not decide where a page ranks.

A lab test on a slowed mobile profile gave a largest contentful paint of 516 to 560 ms for the home page, with no layout shift. It is my own lab figure, not what visitors will see. My technical SEO checklist explains the steps.

What went wrong, and what caught it

• Invisible button text. On the light theme, white text sat on a green button, and the page link colour overrode the button colour. A contrast script found it. I fixed it the same day and measured again: 416 button and link states, the lowest contrast ratio 5.76 to 1. Lesson: after a style change, measure contrast in light and dark. Do not trust my eyes.
• A 200 that lied. A request for a file that did not exist still returned 200, because an old catch-all redirect sent it to another page. Lesson: check the final address and the text on the page, not only the status code.
• A page nobody could reach. A new page with no link in the menu or footer is invisible. Lesson: a page is not done until something links to it. The build now fails on it.
• A test that disagrees with itself. The demo hub does not render the same pixels every time in a headless browser. The pixel gate renders it twice per side and takes the closest pair.