From Geocities to Claude: How I Manage a Website Without Writing Code

I was maybe eleven years old the first time I made something appear on the internet.

It was a Geocities page. If you’re old enough to remember, you know exactly what I’m talking about—the neighborhood system (mine was in “Area51,” naturally), the under-construction GIFs, the visitor counters that never climbed as fast as you wanted them to. I had a guestbook that maybe four people signed, three of whom were me from different computers.

The thing I remember most clearly isn’t any specific page I built. It’s the feeling. You’d type something, hit a button, and suddenly it existed on the internet. Anyone in the world could theoretically see it. For a kid in St. Louis, that felt like magic.

I didn’t know HTML. I didn’t need to. Geocities had a page builder—basically a WYSIWYG editor where you’d drag things around and it would generate the code. But eventually, curiosity got the best of me. I started hitting “View Source” on pages I liked, copying snippets I didn’t understand, pasting them into my own pages to see what would happen.

That’s how I learned that the internet was made of code. And that’s how I caught the bug.

The Long Way Around

Once you see the source code, you can’t unsee it. I went from copying <marquee> tags to actually understanding what HTML was doing. Then CSS. Then the realization that static pages could only get you so far.

PHP was my first “real” programming language. If you’ve written PHP—especially early-2000s PHP—you know it was simultaneously empowering and horrifying. You could build anything. None of it was secure. I built forums, simple CMS tools, things that probably had SQL injection vulnerabilities you could drive a truck through. But it worked, and it taught me how the web actually functioned underneath.

Then JavaScript got serious. Not the JavaScript of alert boxes and mouseover effects—the JavaScript that started eating the world around 2010. Frameworks appearing faster than you could learn them. Suddenly the frontend wasn’t just decoration; it was the application.

Ruby came next, then Python. Each language felt like learning a new way to think about problems. Each era of web development felt like it was the final form. “Surely,” I thought every few years, “this is how we’ll build things from now on.”

It never was.

Full Circle

Here’s the thing I didn’t expect: the trajectory of my career would eventually loop back to where it started.

Think about what Geocities actually was. You had an idea for a page. You described what you wanted—maybe by dragging and dropping, maybe by picking a template, maybe by typing into a form. The tool turned that intent into a working website. You didn’t need to understand the implementation.

That’s exactly what I do now. Except instead of a clunky page builder, I’m having a conversation with Claude. And instead of a page with spinning skull GIFs and a midi soundtrack, the output is a professional business website running on modern infrastructure.

The abstraction level is completely different. The fundamental interaction is the same: describe what you want, get a working result.

I went from conversational (Geocities page builder) to code (two decades of learning languages and frameworks) back to conversational (AI-assisted development). But this time, the conversation is operating at a level that early-2000s me couldn’t have imagined.

How I Actually Manage This Site

Let me make this concrete, because “I manage my website with AI” can sound like marketing fluff. Here’s how moserresearch.ai actually gets built and maintained.

The site runs on Astro with Tailwind CSS, deployed to Cloudflare Pages. It’s a proper modern stack—static site generation, optimized assets, automatic deployments from GitHub. The kind of setup that would’ve taken significant configuration work a few years ago.

I barely touch the code directly.

When I wanted to add an RSS feed to the site, I didn’t open a code editor and start writing XML generation logic. I told Claude what I needed. Within a few minutes, the feed was built, integrated with the existing blog infrastructure, and the RSS icon was added to the footer. Every commit gets a “Co-Authored-By: Claude” tag—because that’s what it is, a collaboration.

When I write a blog post—including this one—I’m not manually creating files, writing frontmatter, optimizing images, or checking that the markdown renders correctly. I describe the post I want to write. We have a conversation about the angle, the structure, the tone. Claude drafts it, I refine it, and the technical plumbing happens in the background.

It goes beyond code changes. When I needed a privacy policy and terms of service for the site, I didn’t copy a generic template off the internet or pay a lawyer to draft boilerplate. I walked Claude through exactly how Moser Research operates—what data we collect, how Cloudflare handles our email routing, what our actual business practices are. The result was a privacy policy and terms of service tailored specifically to our operation. Not a one-size-fits-all template with irrelevant clauses about data we don’t collect—an accurate description of what we actually do. (We documented the whole process in our AI-powered legal review case study if you want to see how it worked.)

I did the same thing with security. I had Claude perform a full security audit of the site—reviewing headers, content security policies, dependency vulnerabilities, form handling, the whole surface area. It identified issues, explained why they mattered, and then fixed them. The kind of audit that would cost real money from a security consultancy, done through conversation in an afternoon.

Design changes, SEO improvements, new pages, bug fixes—they all work the same way. I describe the outcome I want. The code gets written, tested, and committed.

But here’s the part that actually makes this work: there’s a file in the project called CLAUDE.md. It’s essentially an operating manual for the site—the tech stack, the color palette, the content guidelines, the legal review checklist, even our specific pricing that needs to stay consistent across pages. When Claude works on the site, it reads that file first, which means it has the context to make changes that are consistent with everything that already exists.

That file is the difference between “AI that generates code” and “AI that maintains a project.” Without it, every change would require re-explaining the entire codebase. With it, Claude operates more like a developer who’s been on the project for months. It’s cognitive offload in practice—instead of holding all these decisions in my head and re-explaining them every time, they’re documented once and available whenever I need to make a change. It’s also a real-world example of what we call Business Entity as Code—treating your business operations like software: version-controlled, documented, and reproducible.

What I Still Do

I want to be honest about what this isn’t. This isn’t “I pushed a button and an AI built my business website.” I’m still making every decision about what the site should say, how it should work, and what it should look like.

I decide the messaging strategy. I write the core ideas for blog posts—the arguments, the frameworks, the experiences that come from actually running this business. I review every piece of content against our epistemic integrity checklist (yes, we have one of those, because publishing AI-assisted content without one is how you end up saying things that sound smart but aren’t true).

I’m also the one who knows when something is wrong. If Claude generates a component that doesn’t quite match the site’s visual language, I can see it because I understand the design system. If a blog post drifts into a tone that doesn’t sound like us, I catch it because I know what “us” sounds like.

The skill set didn’t disappear. It shifted. Twenty years of writing code means I can evaluate what the AI produces, debug it when it breaks, and describe what I want precisely enough that the output is usually right on the first pass. The expertise is in knowing what to ask for and recognizing quality when I see it.

What This Means If You’re a Business Owner

Here’s where this gets relevant beyond my personal nostalgia trip.

If you’re a small business owner, you’ve probably had some version of this experience: you know you need a better web presence, or better internal tools, or better documentation, but the technical barrier feels too high. You either need to learn to code, hire a developer, or settle for whatever a template gives you.

That barrier is dissolving.

The limiting factor isn’t technical skill anymore. It’s clarity about what you actually need. The business owner who can clearly articulate “I need a scheduling system that handles these three types of appointments and sends these specific follow-ups” is going to get a better result from AI tools than a vague “I need a website.”

This is the same pattern we see across every AI implementation: the technology is ready, but the human side—documented processes, clear requirements, organized information—is what determines whether it works well or just generates noise. We wrote a full guide on what it actually takes to be AI-ready if you want the details.

That’s the whole thesis behind what we do at Moser Research. We help small business owners get the operational clarity that makes AI actually useful. Whether that’s documenting your processes so they can be automated, building custom tools that fit how you actually work, or maintaining your systems as AI capabilities continue to evolve—it all starts with getting clear about what your business actually does and needs.

The Real Full Circle

Geocities made the web accessible to an eleven-year-old who didn’t know what HTML was. It lowered the barrier to “have an idea, see it on the internet” and an entire generation of developers got their start because of it.

AI is doing the same thing, but at a professional level. The websites being built through conversation today aren’t Geocities pages with hit counters. They’re production applications with real architecture. The gap between “I want this” and “this exists” has never been smaller—but most people still have a mental model of AI from two years ago. That gap between what’s possible and what people think is possible is what we call the capability overhang, and it’s the biggest competitive opportunity in a generation.

The code is still there, underneath all of it. Astro still compiles components. Tailwind still generates CSS. Git still tracks changes. The fundamentals haven’t gone anywhere—they’ve just become something you can direct through conversation rather than type out character by character.

I spent twenty years learning to write code. I don’t regret a minute of it—that knowledge is what makes me effective at working with AI now. But I’m glad the next generation of business owners won’t have to take the same long way around just to get a professional website or automate a workflow.

The tools finally match the intent. You describe what you need, and it happens.

That’s what Geocities promised. It just took a couple of decades to deliver.

If your business is ready to stop treating technology as a barrier and start using it as the accelerant it’s become, let’s have a conversation about it.

The scenarios described in this post represent common opportunities we see across small businesses. Specific results depend on your existing infrastructure, processes, and implementation approach.