This week I asked for something small. In one of our build-log posts I had written that each recording is filed "with a checksum." Most readers would have no idea what that means. I wanted every term like that explained in plain words, the way you would explain it at a kitchen table. A checksum is a kind of digital fingerprint, worked out from every byte in a file. Change a single byte and the fingerprint no longer matches.
Then I asked for the same fix everywhere it applied, not just in that one post.
We checked every published post on three of the sites that run on our platform, this one included. That was 91 posts. Forty-two of them used a term a general reader would trip over: codebase (the software itself), marginal cost (what one more costs once the first is paid for), CMS (the system a newsroom publishes with), and a few dozen others. Each term got a short, plain explanation the first time it appears in a post. Where a term added nothing, it was replaced with the plain word. That came to 133 changes. None of them altered a fact, a number or a quote, and each one is logged with the old wording beside the new.
The words are not the point of this post. The pass is.
How this would have gone before
A year ago our publications ran on separate WordPress sites. Each had its own install, its own login and its own admin screen, and each kept its articles in its own database. A job like this one would have been three jobs. Log into the first site, find the posts, fix them, check them. Log into the second and do it again. Then the third. Anything learned on the first site, a better way to explain a term or a mistake to avoid, would have to be carried by hand to the next.
The cost of a website per publication that I felt most was never the hosting bill. It was that every improvement had to be made once per site, by someone who remembered to make it.
How it went now
Every publication we run sits in one database. So the job was one job. One read of every post across all three sites. One set of rules for how to explain a term. One run that applied the changes. One log that records each one. Adding a fourth site, or a tenth, to a job like this adds no extra steps. It is just a few more rows in the same table.
This is what I mean when I say we built infrastructure, not websites. A website gets better one site at a time. We built ours so that an improvement made for one publication's readers reaches every publication's readers.
The rule is standing now, too. Every new post gets checked for unexplained terms before it goes out, on every site, from one place.
This is No. 17 in We Built Our Own, a Mercury Local series on building our own publishing stack. Previous: Why we did not rent it.