Red Oak logo
Web Zero

Web Zero

This page, the blog, the services pages — all of it is static files. HTML, CSS, and JavaScript. No WordPress, no PHP, no database, no server running code.

It started as an epiphany while working with AI. The site was originally a Next.js build, and I turned it into static files. Mobile PageSpeed went from 62 to 92. That was the first data point. Then I started asking the obvious questions: if the site doesn't need a server to run, why am I maintaining one? And if it doesn't need a CMS to change, why is there one at all?

What Web Zero is

Web Zero is the answer. It's building a website at zero: zero server-side runtime, zero CMS, zero theme updates. The site is files in Git, and that's the whole system.

  • AI is the interface for change. Nobody edits the HTML by hand. You describe the change to an AI agent, and the agent makes the edit in the repo. The CMS admin screen was always just an interface. This one is cheaper and talks to you.

  • Git is the guardrail. Every change is a commit, and every commit is reviewable and reversible. That's the discipline the CMS used to enforce. Now it's enforced by version control, which is what it was built for.

  • Everything else falls out of that. Search, previews, deploys — all simple tools around the files. One command builds the site. Pushing to the main branch ships it.

What's running on this site

Most of this isn't theory. The site you're reading is the test case.

  • Static pages, served from the edge. Nothing to patch, no plugin stack.

  • Blog posts written in Markdown and built into pages at deploy time.

  • A machine-readable layer (llms.txt and an AI index) generated on every build, so AI tools can read the site the way search engines always could.

  • Mobile PageSpeed at 92 on today's mobile lab test. It was 62 before.

Why a customer would want this

So far this has been about how I build. Here's what it does for the person paying for the site.

  • Speed. No server round-trip and no plugin bloat. The live site scores 92 on today's mobile lab test, and it loads in under two seconds on a throttled phone connection. Google uses page speed as a ranking signal, and visitors decide in the first few seconds.

  • Cost. No theme license and no plugin subscriptions. What's left is low-cost hosting. A small number.

  • Security. There is no admin panel to target and no login to steal. No plugin supply chain to watch. The October PHP emergency release is the case study: that class of vulnerability does not reach a site with no backend engine.

  • Ownership. The site is files you hold, in a repo you control. No platform can hold it for a price increase, and no vendor departure means a migration rescue. If I disappear, the site doesn't.

  • The basics are in. Responsive on every screen size, accessible, and it carries the legal set a real business needs: privacy policy, terms, cookie policy, accessibility statement, and a consent banner that respects them.

Lighthouse mobile report for www.redoak.consulting, October 22, 2026: 92 performance, 97 accessibility, 100 best practices, 100 SEO

That's Lighthouse, the engine behind PageSpeed Insights, run against the live site on October 22, 2026. Mobile form factor. Before the conversion, the same measurement was a 62.

What I'm still working on

This is a work in progress, and I'd rather say that plainly than dress it up. Dynamic features are the hard part of a site with no server. Right now I'm testing:

  • An events calendar that reads an ICS file. No backend. A feed and a renderer.

  • A shopping cart and checkout built on Stripe's hosted pages. The card data never touches this site.

  • Site search, done client-side from a small index the build generates.

  • Bookings. I want it to be a form and a calendar, and I don't want it to be more.

I'll write up what works and what doesn't as I go. That's the point of a public project page: it's a work log, not a brochure.

The timing

This work is landing at an interesting moment. On October 21, PHP shipped emergency releases fixing two critical vulnerabilities that allow unauthenticated remote code execution, rated 9.2 each. Every site built on that engine inherits the exposure until the engine is patched. A static site doesn't have the layer. That isn't the only reason to build this way. It is a reason.

If you're running a WordPress site and you'd like a second opinion on what this would look like for you, talk to me. jason@redoak.consulting