Iroko: the site I built as a teenager that is still up

Built in the summer before I turned sixteen. Moved between hosting providers by hand a few years later, free migration thrown in with the switch, done by someone who had never seen the code. Nearly twenty years on, it is behind HTTP/3 and a WAF that did not exist when it was written, and it has no idea. It never asked for anything, so nothing had to be maintained for it.

It belongs to a company owned by a friend of my father's. Twenty years on, the site still stands in for that company in its industry and its local community, and beyond. I noticed it was still up, and this summer I promised him a new one, for free. We are in touch, rarely, and I will rebuild it at some point. The catch: the old one is so operational that the replacement never becomes urgent.

What broke? Nothing. Nearly twenty years, zero maintenance from me, still serving. That is the uncomfortable part, and the reason this is a scar rather than a trophy: the modern systems I am proud of have needed more attention to survive less time.

The honest part: at the time I was proud of it. Back then, this was an amazing site, and I built it the only way I knew how. I did not think it was primitive or something to grow out of. The wrong belief came later: the slow assumption that the sophisticated tooling I picked up afterwards was the "real" engineering, and that this early work was behind me.

What was actually wrong was the belief that sophistication buys durability. The site survived because it makes no demands of its environment: no framework to deprecate, no dependencies to patch, no runtime to keep alive, no build to reproduce, no certificate I had to hand renew (the host added HTTPS, HTTP/2, HTTP/3, and a WAF underneath the same untouched files).

The migration is the strongest evidence, stronger than the age. Some years after it was built, the site was moved between hosting providers by hand: a free migration bundled with a hosting switch, standard practice at the time, performed by a hosting technician who had never seen the code. No build step, no dependency install, no runtime version to match, no configuration to port. Someone FTP'd a folder across and repointed DNS, and it kept serving. Twenty years of uptime could be luck. Surviving an unceremonious hand-migration by a stranger is a property of how it was built, not of who was watching it.

The trade-off is visible in the bytes: plain static HTML is inflexible and looks its age, but it has almost no surface that can fail. Expressiveness and dynamism were traded away for a maintenance surface of essentially zero.

Static was not a decision back then. It was simply how I built sites at the time, the only method I had, so the durability was an accident. What makes this a scar and not luck is that I can now defend on purpose the thing I once did by default.

Today I would probably build it with Next.js and Sanity. But the more honest answer is about pace: tech moves so fast that the stack from two years ago is already half irrelevant. As an example, the JavaScript frameworks were built to make life easier for developers (I know, someone is probably laughing), and now you need most of them less than before, because coding is not the primary concern right now. After all, the focus has moved up to architecture, orchestration, context management - where all 3 create the purpose of the software you build and how it interacts with users.

So Iroko in twenty years is not this frozen folder. It is still simple, but alive: a CMS behind it, better SEO, something more viable. The irony I would keep is that "still simple" is exactly why the first version lasted at all.

This is not "build static HTML". An audience running Next.js on Vercel would dismiss that, and they would be right. The rule is about coupling. The site outlived twenty years of infrastructure churn because it made no demands of its environment: it is served today over HTTPS, HTTP/2, and HTTP/3, behind a BitNinja WAF on Caddy, none of which existed when it was written, and it needed no changes to receive any of it.

Transferable form: build-time over runtime, config over code, fewer things that must be true for it to work. The fewer demands a system makes of its environment, the longer it survives that environment changing.

The dead P3P privacy header the site still sends: a standard that died years ago, still politely announcing itself on every response.