How this site is built, and what is actually unusual about it

Nobody typed this section. The run writes a receipt, the build reads it, and in Receipts mode you get every check by name with how long it took. Anything that reads the finished build runs once this page already exists, so it can't be listed here, and a failure there still stops the deploy.

It's a portfolio that gates its own claims. Every number here is produced by something that runs, and when one of those fails the build fails with it. Sounds like a small distinction, and it's the whole distinction.

It's shaped that way because I spent eight months telling people a design system met a WCAG standard, then wrote the test that could actually check, and it hadn't. That's published here, in full, with the numbers. A portfolio that's already shown you the thing it got wrong is an easier one to believe about everything else.

Each one's checked against a survey of real sites rather than against a feeling I had. Two turned out rarer than I'd have guessed. One turned out to matter a good deal less than I'd assumed, and it's in here at the same size as the other two, because that's the point.

They're not linters: a linter tells you about the code. These check whether the things the site says about itself are still true, and every one of them was written after something got past me.

In August 2026 all nine that existed then got audited the only way a gate honestly can be: plant a violation of the exact thing it claims to catch, run it, and refuse to take a pass for an answer. Seven caught it straight away, two didn't, and why they didn't is the most useful paragraph on this page.

Fifteen findings, nine fixed on the spot, and one of them withdrawn once I'd measured the thing properly instead of inferring it from the wrong place. The two worst were level A accessibility failures that had been live for months, and honestly the reason they were live is more interesting than the failures themselves.

Two rules inside the claims gate were dead, not wrong but dead. They'd got literal backspace characters sitting where regex word boundaries were meant to be, so each pattern was quietly demanding a control character that no real sentence has ever contained. A backspace doesn't show up in your editor, or your diff, or your terminal, or even in the regex printing its own source back at you. Reading that file for a week wouldn't have found it. Planting a violation and refusing to believe the pass did it in about a minute. That's the whole method.

Then the navigation, which is worse. Every link in the bottom bar had no accessible name at all below 768 pixels, because the icon was marked decorative, the full label was display:none, and somebody had marked the short label decorative as well. Nothing left. Six links with nothing for a screen reader to read out, and then the same six again in a second component that didn't share a line of code with the first.

The suite had never seen any of it, because the suite only ever ran at one width. On a site that renders three separate component trees, that means two thirds of the markup had never once been looked at by the thing whose entire job was looking at it. Four lines of config fixed that, and it failed on the very first run and handed me a second broken component in a file I'd already read twice and cleared.

Three component trees means three lots of CSS on every route. It was one stylesheet of 247 kilobytes when this was first written; split by route, the home page now delivers 69 kilobytes of it, measured on 24 September 2026. It also means the hydrated page ends up holding markup for shells you'll never see, though the server only ever sends one. I got that distinction wrong during the audit, wrote it down as a payload problem, then went and measured the raw HTML the server actually sends and found it wasn't one at all. Wrong, and left in.

Then the JavaScript. Every page makes you download between 196.3 and 200.8 kilobytes of it, compressed, before it does anything, and the privacy page, which has nothing interactive of its own, takes 196.3 of those. So the weight is React, Next.js and what every page shares, not any one page being greedy. Articles take 258.6, because they seat their own text on the baseline grid in your browser, with Quoin. Both are budgets now, 205 and 260, and a page that goes over fails the build. The script that measures it had a budget of 180 for the home page for weeks while the page weighed 197, because nothing ever ran it.

The gates take time to write and now and again they block something that's perfectly fine. That's why the claims gate carries an exemption list: a rule that can't tell a correction from a relapse is a rule that stops you writing about the correction at all, and the correction is the interesting part.

And there isn't a single unit test in this repository. Not one component in it is tested on its own. The end to end suite covers behaviour at the page level and covers it properly, but that's a narrower promise than the rest of this site makes, and it's fairer to say so plainly here than to let a test count in the hundreds sit on the page implying a kind of coverage that simply isn't underneath it.

The security headers are stricter than most production sites carry, and they still let inline scripts and inline styles run, which is the first thing anybody who reads a Content-Security-Policy will spot. The pages are built once, ahead of time, and Next.js ships each page's data as inline scripts. The proper fix is a nonce, a nonce has to change on every response, and that means rendering every page on request and giving up the static build the speed comes from. The inline styles are the same trade in miniature, a handful of values set on elements directly. On a site that took payments or held logins I'd pay for the nonce without thinking about it. This one holds neither, so I took the speed, and I'd rather you read that here than find it in the headers.

None of those headers reach you on this copy. It's the backup of the site on GitHub Pages, which serves the files as they are and can't add headers of its own, so the Content-Security-Policy and the rest are back as soon as the site returns to Vercel.