Yesterday I met a potential client for my software consultancy. Did my pitch, explained what I build, how I work. Halfway through, he said he’d looked me up. Found this site. He thought I still did sound design and video editing.
This site had been sitting here for years, frozen from my LA days. Portfolio pieces from Walking Dead, Better Call Saul, American Horror Story. I hadn’t touched it.
That’s what made me rebuild it. The how is more interesting than the why.
The Read/Write Problem
Think about a local bakery’s website. They update it once a month. New seasonal menu, changed hours, a holiday notice. Visitors hit that site hundreds of times a day. The read-to-write ratio is something like 10,000 to 1.
Look at how that site was probably built. A CMS running on a server, a database storing the content, an admin panel for that one monthly edit, plugins that need updating, PHP that needs patching, a hosting plan that needs monitoring. All of that infrastructure exists to serve the write side of a 10,000-to-1 equation.
WordPress powers roughly 43% of all websites on the internet. Nearly half the web runs on dynamic server infrastructure that re-renders the same unchanged content on every request.
I built WordPress sites for clients for years. Loved it. It solved real problems: e-commerce, newsletters, CRM, all out of the box. But about 80% of my small business clients didn’t need any of that. They needed five pages, a contact form, and for the thing to load fast. I kept building dynamic systems for static problems because that’s what the industry told me to use.
What Every Era Got Right (and Wrong)
I started building websites in the late 90s. Geocities. Angelfire. Pure HTML files, FTP’d to a server, usually rendered wrong in Netscape. Those sites were ugly and wonderful. You uploaded them and they worked. No updates needed, no server to maintain. Go to archive.org. Some of those Geocities pages still render. Try that with a WordPress site from 2014.
What those early static sites couldn’t do was share code. Change the navigation? Edit every page by hand. Redesign the footer? Every single page. WordPress and server-side frameworks fixed that. One template, rendered dynamically, consistent across the whole site. A real breakthrough. But the price was maintaining a live application. Updates that break things, security patches you’re too scared to install, a server running around the clock to serve pages that change once a quarter.
JavaScript frameworks showed up with something genuinely good: reusable UI components. A button defined once, used everywhere. A hero section as a self-contained unit of design. React, Vue, Svelte nailed this concept. What they also brought was a 200MB node_modules folder, build pipelines that need their own documentation, and dependency chains that turn a five-page website into a full-time maintenance gig. For interactive web apps, sure. For a plumber’s website in Arroyo Grande, no.
Static site generators asked the right question: why re-render pages that don’t change? Jekyll, Hugo, 11ty all took a shot at answering it. But the answer was too narrow. Markdown files piped through templates. Built for developer blogs. No component system, no way to think about a page as a composition of reusable design pieces. My excitement for SSGs died fast the first time around.
Separating Design from Content
The breakthrough was realizing that the component concept didn’t belong to JavaScript frameworks. It belonged to the build step.
A hero section is a design decision. The text inside it is a content decision. Different concerns, different change frequencies, different people responsible for them. Separate them and maintenance gets trivial. Redesign the hero? Change the component, every page using it updates on the next build. Change what the hero says on the About page? Edit the content, design stays put.
Atomic design without a JavaScript runtime. Atoms, molecules, organisms. A button, a card, a full page section, all defined as reusable components, combined with structured content at build time. The output is plain HTML files. No database behind them, no server rendering them on every request.
I built a static site generator in Python around this idea. I’ll take Python over JavaScript for this kind of work without a second thought. Components that nest, reuse, and compose. Content in structured files, separate from the templates that render it. One build command produces a complete site. Upload the output folder anywhere.
The Interface That Disappears
Admin panels exist because non-developers need to edit websites. Fair point. But there’s a different answer now.
I have workflows where an AI agent gets context about the project: the component library, the content structure, who the client is, what the site does. Like onboarding a junior developer. Here’s the codebase, here are the standard procedures, here’s the client brief. Make this change.
No login screen. No WYSIWYG editor. No CMS backend to secure and update. Describe the change and a structured workflow executes it. The framework has to be simple enough for this to work. An LLM needs to understand the full project within a short context window. A static site with clear components and structured content files fits that constraint. A WordPress installation with 47 plugins does not.
This blog post exists because of that workflow. I’m talking into a mic, not typing into a CMS. I’ve wanted to maintain a blog for years, started many, stuck with none. The friction was the interface. Remove the interface and the writing happens.
Back to Static
I was a teenager uploading HTML files to Geocities from a bedroom in Istanbul. Those files loaded fast, never broke, and still render on archive.org twenty-five years later.
This site is that same idea with better tools. Components for reusable design. Structured content separated from layout. Structured AI workflows for the write side of the read/write ratio. The output is what it always should have been: HTML files on a server. No admin panel. No database. Hostable for a few dollars a year.
My old Geocities pages from 1999 still work. Most of the WordPress sites I built in 2010 are gone.