Three eras of building websites, and why I went back to plain HTML

I've looked after the website for Cobb Pregnancy Resource Center for a long time. Long enough that the site has been rebuilt in two completely different ways, and I'm now building sites a third way. Looking back at the old versions, I noticed something funny: the newest way has more in common with the first than with the one in between.

Era one: writing the pages by hand

The early Cobb Pregnancy site was a handful of pages I wrote myself. The layout was an HTML table: logo across the top, a column of links down the left, the content on the right. The home page had a photo, one sentence about what they do, and the hours. That was it.

I built the first site for A Precision Clock Repair, my wife's uncle's shop, the same way. Hand-written pages, a photo gallery, and a panel that slid from one section to the next.

Those sites had real strengths. A page was a file. It loaded instantly, cost almost nothing to host, and there was nothing to break or hack. Some of those pages sat untouched for years and kept working.

The weakness was me. Changing the hours meant asking Ryan, and Ryan opening a code editor. So small changes waited, and the site slowly fell behind the business. That is exactly the kind of site I spend my days looking at now.

Era two: WordPress

WordPress fixed that problem. It gives you a login and an editor, so the person who knows the hours can change the hours. Both of those sites moved to it, and when my mom wanted a site for Fishing for Felines, her cat rescue work, I started her on WordPress from day one. She can write her own pages. I'd make the same call again for someone who wants to publish often.

But a WordPress site isn't a set of pages any more. It's a program that builds each page when someone asks for it, backed by a database, a theme and a stack of plugins. All of that needs updating, and it keeps needing it whether or not the content changes. The pages got heavier and slower. And in practice, many owners log in a few times, then stop. They end up with all the upkeep of a system built for editing and none of the editing.

Era three: describe the change, get the page

The sites I build now are plain pages again. No database, no plugins, no login screen for a stranger to try passwords on. What changed is who does the editing. I describe what should change, an AI model makes the edit across every page it touches, I check it, and it's live.

That takes away the one real weakness of era one. A hand-built site used to be hard to change because a person had to do it by hand. Now the change takes a sentence. So the whole reason for the big editing system in the middle gets a lot weaker for a small business whose site changes a few times a year.

It's a little funny to end up back where I started. But the pages are much better looking than anything I wrote by hand, they work on a phone, and they still load like a file, because that's what they are.

What this means for your website

Ask yourself one honest question: when did you last log in and change something? If the answer is "last week", an editing system like WordPress is earning its keep. If the answer is "I'm not sure I remember the password", you're paying for it, in speed and upkeep and risk, without using it.

What you actually need is a way to get a change made quickly. That doesn't have to mean doing it yourself in an editor.

How we handle it

Every site we build is plain, fast pages made from the content already on your current site. When you want something changed, you tell us in ordinary words, right on the page, and we make the change. You never have to learn an editor, and there's nothing on the site that needs security updates.