Before WordPress: how a 2002 author platform ran for sixteen years

In November 2002, six months before WordPress launched, I built a hosted publishing platform for the Authors Guild that gave member writers self-service author websites. It ran continuously for sixteen years with no ongoing maintenance from me. The reason it lasted is the whole argument.

The Authors Guild needed a hosted publishing service for non-technical members six months before WordPress existed. I built it as a static-output, multi-tenant platform, and it ran continuously for sixteen years. Those two facts are connected, and the connection is the whole point.

I want to be plain about why I’m telling this story. Sixteen years of a system running without me touching it is a story about how the thing was built, not about how long ago I built it.

I built the platform for the Authors Guild, one of the oldest literary nonprofits in the United States. The service gave members, who were working authors and journalists rather than web developers, a self-service way to publish personal websites: biographies, bibliographies, events pages, newsletters, sample chapters, book information. It also gave the Guild something harder to build than features. It gave them a hosted member service they could charge for and keep running over time.

The timing matters. The platform shipped before WordPress was a practical default. WordPress launched in May 2003. When my system went live, the stack that would later be the obvious choice didn’t exist yet. I had to design from first principles for the client in front of me.

This is the WordPress Practice case for architecture that fits its context. The system this post describes ran for sixteen years because it was built for the problem in front of it, not for the problem the tooling expected. That principle holds for any platform decision you make today, including whether to reach for WordPress.

What the client needed

Founded in 1912, the Authors Guild represents the professional interests of working American writers. In 2001, it wanted to offer paying members a turnkey web presence: a place to introduce themselves, list published works, post appearances, share sample material, and give editors, reviewers, and readers a reliable place to find them online.

The constraints were clear. The users were non-technical. The Guild needed to host the service itself. Payment had to be wired into a members-only offering. And the system had to stay workable over a horizon measured in years, not quarters.

The first version launched in ColdFusion in late 2001, and the SiteBuilder project entry covers that original build. It met the immediate need, but the Guild wanted a sturdier foundation to grow into. They commissioned me to rebuild the platform in PHP. That rebuild, which I codenamed sitebuilder2, was operational by November 2002.

The architectural choice that mattered most

The decision that defined everything was simple and it held: the public sites were generated as static HTML.

SiteBuilder didn’t render author pages on every request. When a member edited a biography, added a book cover, or updated an events page, the application wrote complete .htm files to disk under that author’s directory, usually index.htm, bio.htm, works.htm, events.htm, and newsletter.htm. The dynamic PHP layer handled the author’s session in the back end. The published site was just static files served straight from the filesystem.

Here’s the way I explain that choice to people who don’t write code. A restaurant can hand you a printed menu, or it can send a waiter to the kitchen to ask the cook what’s available every single time someone walks in. The printed menu is wrong the day the kitchen changes something, so you reprint it. The rest of the time, it’s instant, it costs almost nothing, and a thousand diners can read it at once without bothering the cook. SiteBuilder printed the menu. When a member changed something, I reprinted their pages. Every other visit was just handing over a page that already existed.

That separation solved the problem the Guild actually had. For a hosted member service, read traffic would always dwarf write traffic. Most visitors only ever needed to view a page. Only members logged in to edit. Static output skipped the database round-trip and the template rendering on every public page load. It made the member sites fast and cheap to serve, and it made them predictable to operate. More than that, it matched the institution’s economics. The Guild needed to support a lot of member websites without turning every public visit into application overhead it didn’t need to pay for.

Years later, the developer world would name “static site generation” as a pattern, through tools like Jekyll, Hugo, and Eleventy. SiteBuilder wasn’t part of that movement. It arrived at the same core idea for the same reason mature systems usually do. It was the right answer for the load.

A shared platform, many member sites

The architecture had three parts. There was a shared PHP application layer handling accounts, themes, image processing, analytics, billing, and the author editor. There was a generation step that ran at save time and wrote static files for each member. And there were the per-author public sites, served from subdirectories under members.authorsguild.net/{username}/.

One codebase ran the whole service. Each member got their own published site. Centralized maintenance lowered the cost of running a service where every member’s site could be different, without flattening everyone into the same experience.

What the system had to get right

Some of what I had to solve here is the kind of thing a modern framework hands you for free. In 2002, I was building it.

Member-uploaded photos needed resizing, cropping, and optimizing. I ran those at upload time on the server, not in the visitor’s browser at request time.

Each member’s files had to stay in their own directory, and this is the one that kept me up at night. A publishing error for one author could not be allowed to touch another author’s live site. I remember the moment it stopped being theoretical. Early in the build I had a path bug where the generation step, under one specific edit sequence, resolved the output directory one level too high. On my test data, one member’s save started writing files into the shared parent instead of their own folder. Two test authors, and one of them was about to overwrite the other. Nothing real broke, because it was test data, but it was the clearest possible warning of what would happen at scale with real members and real money on the line. I rewrote the path handling so every write was pinned to the member’s own directory and could not climb out of it, and I built the check in two places instead of trusting it once. After that, the code enforced isolation directly. I no longer had to assume it held.

The editing interface needed secure authentication without third-party libraries, because PHP in 2002 didn’t have the session tooling it has now. Members could pick from a set of site designs, and the generation layer had to apply the chosen theme across all of a member’s static files without rendering anything per request. And membership payment and feature access had to be linked without standing up a separate identity layer.

These were correct solutions. Correctness was the whole point. The system worked because the architecture fit the problem.

How long it actually ran

The platform ran for sixteen years because the architecture removed the need for ongoing maintenance. There was nothing to patch on the public side.

Static file output is low-maintenance by nature. There’s no persistent application server to keep alive. Nothing renders on the fly, so there’s no query performance to watch. When a member’s page loads, the server is doing the thing servers are best at: handing back a file from disk.

For most of that sixteen years, I had no ongoing relationship with the platform at all. It kept serving members because the architecture never created the obligations that would have pulled me back in. A system designed for its actual context keeps running on its own. That is the expected outcome.

So the sixteen years is a data point, and the argument it supports is about architecture. A system designed correctly for its load and its operating context lasts because it solved the real problem. Nobody had to keep rescuing it.

This engagement in context

This project sits in the WordPress Practice pillar — the work of designing a platform that fits its actual operating context rather than inheriting the defaults of whatever framework happens to be popular. In 2002, that meant building from first principles because the off-the-shelf option didn’t exist yet. Today it means knowing when WordPress is the right answer and when the problem needs a different starting point. The Site Audit service is where this thinking begins: determining what the system actually needs before anyone writes a line of code.

What this transfers to

I’ll say the obvious thing first: nobody should build SiteBuilder today. WordPress, with decent hosting and a membership plugin, does everything this system did, and it does it with no custom code from you. If a client handed me this brief now, that’s where I’d point them.

The part worth carrying forward is how I’d approach the same brief today.

Figure out your real load profile before you pick an architecture. A read-heavy service and a write-heavy service want completely different things, and guessing wrong here is expensive to undo later. Split the work at the right seam, too. The public site and the member editor had different performance needs, so I designed them as separate concerns instead of forcing one to behave like the other.

And put the simplicity where it counts. The static output layer was deliberately the dumbest part of the whole system, and that’s exactly why it kept paying off, quietly, for sixteen years. The flip side is the part people get wrong: in 2001, SiteBuilder was the right call for the Guild. Today WordPress is the right call for a similar brief, because the off-the-shelf option finally grew up enough to meet the need. The right answer changes when the ecosystem changes. Matching the architecture to what’s actually available, and to what the client actually is, beats matching it to whatever you happen to know how to build.

The lesson I keep relearning is the unglamorous one. The job was always to build something that solved the problem in front of me and then got out of the way.

If you’re deciding between building something custom and adopting an off-the-shelf platform, or if you’ve inherited a system and can’t tell whether to rescue it or replace it — a Site Audit is usually the right starting point. The answer almost always comes from the architecture question, not the technology question.