Static site, dynamic client

A client rang in June because a price on their site was wrong. Not a disaster, somebody had typed 45 instead of 145, but it had been up for two days and they wanted it gone in the next ten minutes.

I was on a train.

On a WordPress site, that call ends with me saying “log in and fix it, it’s the second block on the services page.” On this one it ended with me explaining, over bad reception, that the change goes in a text file, in a repository, and then a build runs, and the build takes about 90 seconds, and no, they couldn’t just do it, and yes I’d do it when I got back to my desk.

Everything about that site was better than the WordPress one it replaced. It was four times faster. It cost $10 a year to host instead of $30 a month. It had no admin login to be brute-forced, no plugins to patch, no database to be injected, and every change to it for two years was in a git history with a reason attached.

None of that was any use whatsoever on that phone call.

The one axis

I’ve built quite a few of these now and the pattern is consistent. Static wins comfortably on speed, cost, security, maintenance burden, reliability and auditability, and loses on exactly one thing: a non-technical person making a small change quickly, on their own, without being frightened.

And that one thing is not a minor entry on the list. It’s most of what owning a website feels like to the person who owns it. They don’t experience the milliseconds or the absence of a security patch. They experience the Tuesday.

They don't experience the milliseconds or the security patch they didn't need. They experience the Tuesday afternoon when a price is wrong.

Which means when I’m comparing the two, I’m weighing six things I can measure against one thing I can’t, and I have a systematic tendency to let the six win. That’s not analysis, that’s just what’s easy to count.

What the build asks of a person

It’s worth being concrete about the ask, because I don’t think developers see it any more.

To change a sentence, the editor needs: an account on a code hosting service, an understanding of what a repository is, the ability to find the right file among several hundred, comfort with a text format where a stray character in the front matter breaks everything, and the patience to wait a couple of minutes and then hard-refresh.

Then there’s the failure mode, which is the real problem. If they get the syntax slightly wrong, the build fails. The site doesn’t break, which is genuinely the best part of the whole arrangement, but there is no feedback loop a normal person can use. There’s a log. The log says something about a Liquid exception on line 14 of a layout they’ve never opened. At that point they ring me, and they ring me slightly embarrassed, and now editing their own website is a thing they associate with having done something wrong.

I’ve watched this happen to a bright, capable, completely non-technical marketing manager, twice, and after the second time they stopped touching the site and started emailing me changes. Which is a worse outcome than the CMS for everyone including me.

The editors got better

To be fair to where things are: this has improved a lot in the last 18 months, and the git-backed editing layers are a good idea. The editor gets a proper admin interface with labeled fields, and behind the scenes it’s writing to the repo and triggering a build. No YAML in their face.

I’ve shipped two projects on that and it works. Three caveats from actually doing it.

The latency reads as failure. They press save, the page doesn’t change, and there’s no obvious “it’s building” state anywhere they’d look. Every single client has asked me, in the first week, whether it saved. You can explain the pipeline once and they will not retain it, and they shouldn’t have to.

The preview is not the site. It’s a preview of the fields, in a panel, roughly. The moment the layout is doing anything interesting, what they see while editing and what appears afterward diverge enough to be unsettling.

And images are worse. Uploading, cropping, reusing an image from three months ago, finding it again. The media library is one of the excellent things about a mature CMS and everybody underrates it because developers rarely use it.

When static wins

None of that is an argument against static sites. It’s an argument about matching, and there are cases where it’s obviously right.

Sites that change a few times a year. A practice, a consultancy, a firm with five pages and a phone number. The editing cost is small because there’s barely any editing, and the maintenance saving is enormous because nobody was ever going to apply those updates.

Anything where the client is technical, or has one technical person who actually enjoys it. This is more common than you’d think and it’s a delight when it happens.

Content that’s generated rather than written. A directory of a few hundred members, a product list, a schedule, where the real source of truth is a spreadsheet or an export from some internal system and the site is a rendering of it. Static builds are outstanding at this and a CMS is actively in the way.

Campaign and event sites, which go up, run, and are archived. Nobody needs an admin for six weeks.

And anything where the site has been hacked before. That conversation is short.

The bias worth naming

The last thing, and the reason I wrote this rather than a post about how great static sites are.

I love working this way. The whole site in a repo, everything in version control, a local server that rebuilds in a second, no database, no admin, deploy by pushing. It is easily the most pleasant way I have ever built websites and I’d choose it for everything I own.

That’s a preference about my working day. It has nothing to do with the client, and I’ve noticed I can produce a very tidy technical justification for it in about 90 seconds, complete with numbers. The numbers are all true. They’re also downstream of wanting to do it.

So the question I’ve started asking myself first, before any of the technical comparison, is: who is going to change this, how often, and what happens when they get it wrong at 4:50 on a Friday. If I can’t answer that with a straight face, the answer is a CMS, and the answer is a CMS more often than my preferences would like.

What we actually did

They kept the static site, incidentally. What we did was move the handful of things that actually change, the prices and the opening hours, into a small data file with an editing interface pointed at it, and left everything else alone.

Which is not a principled architecture. It’s the four fields that were causing the phone calls, plus a form to edit them, and it has worked perfectly for two months. Most of what I get right turns out to look like that.