My Agent-Ready Website Stack

I built my first website when I was 7 or 8 years old. It was a Pokémon fan page on GeoCities, and my dad helped me make it. We had a computer in our house back when that was pretty rare, and I remember watching the images I had uploaded load bit by bit, line by line—Pikachu slowly revealing himself one pixel row at a time.

I got into coding through Flash and ActionScript 2.0, making little games and animations.

By the time I was 13 or 14, I was learning the fundamentals of web development—HTML, CSS, and vanilla JavaScript.

In high school I was already building websites. This was back when jQuery was ubiquitous and Dreamweaver was still a credible tool. I even used Dreamweaver for a web dev class. It was painful.

Eventually I turned it into a career.

I've made hundreds of websites since then. WordPress, Drupal, Shopify. I've worked on modern React frontends for startups.

I've seen the evolution from table-based layouts to Flexbox to CSS Grid, from jQuery to React Server Components.

I remember debating CSS semantics with colleagues at marketing agencies—BEM versus atomic CSS. I discovered Tailwind early on and immediately fell in love with the concept.

I watched design systems mature. Atomic Design by Brad Frost had a huge ripple effect in the industry. People started iterating on that approach with things like design tokens—configuring design system variables in YAML that could be transformed for multiple platforms.

I pushed for these approaches at mid-to-large organizations because they help keep brand consistent. Multiple teams and stakeholders can stay aligned. These approaches required more foundational work and added some complexity. But for large enough organizations, it was worth it.

Everything has trade-offs.

The WordPress Era

I was a big fan of WordPress early on. The ecosystem was incredible—you could add almost any feature you wanted through plugins, free or paid. Need a contact form? There's a plugin for that. SEO optimization? Plugin. E-commerce? Plugin.

But I learned the hard way that this convenience comes with a cost.

One of my websites got hacked. Malware injected through an outdated plugin. The site was compromised, data was at risk, and I spent weeks cleaning it up. I had to beg my web host for a backup. They had one, thankfully, but it was old. I lost a month of content.

After that nightmare, I pushed my clients toward WordPress hosts that offered daily backups, staging environments, and production deploy workflows—services like WP Engine were doing this well. It was overkill for small brochure sites, but for real business websites it provided peace of mind.

But backups don't solve the root problem. They just help you recover faster.

That's when I really understood: platforms like WordPress require constant vigilance. When something is as ubiquitous as WordPress, it becomes a target. The maintenance burden is real—you're managing a complex software stack with plugins, themes, and core updates that can conflict in unexpected ways.

WordPress sites can get convoluted fast. You end up with CSS coming from multiple sources. Plugins interfere with each other. It's like a tangled web of string—you pull somewhere and something gets tighter somewhere else. Not elegant.

The Jamstack Revelation

Around a decade ago, the Jamstack approach started gaining traction, and it immediately clicked with me on a first-principles level.

The idea was simple: pre-render your pages at build time, serve them as static files from a CDN. No database queries on every request. No server-side rendering delays. No database to hack.

The security implications were profound. By eliminating the dynamic server and database, you eliminate entire categories of attacks. No SQL injection. No PHP vulnerabilities. Your "attack surface" is basically just your static HTML files and whatever CDN you're using.

The infrastructure was maturing too. Netlify and Vercel made deployment trivial. GitHub Pages and Jekyll proved static sites could work for real projects. I built a site for my graduate program using Eleventy—a student organization site for the Graduate Arts Council at Virginia Tech. Headless CMSs let you keep the content management experience while ditching the server-side baggage.

I became a convert. I helped companies adopt this approach—I remember building a corporate site for Ridgeline using a headless WordPress CMS (the team liked the interface) feeding into a static frontend. The security improvement alone was worth it for them.

The Notion Interlude

My personal site, though, took a different path.

For the past few years, my website was built on Notion. I'd been using Notion for my portfolio, my blog drafts, my idea capture—it was where my content already lived. And services like Bullet made it trivial to publish Notion pages as actual websites.

I chose the "lazy" option. I could have built something custom. I have the skills. But I'm utilitarian-ish—sometimes the simple solution is the right one. It was cheaper to pay Bullet $10 a month for the convenience of using Notion, which I was already working with, than putting in the effort to build a custom site from scratch.

These decisions are always situational. Just because you can do something impressive or complex doesn't mean you should.

But it had its downsides. After I moved away from using Notion day-to-day, I didn't enjoy working on the website. The site languished. I stopped updating it.

And I realized I had things I wanted to say again, so it was time for something new.

Building for the AI Era

Here's the thing: the web is changing again. And this time it's not about frameworks or build tools—it's about AI.

I've been deep in the AI tooling world lately. Claude Code, Cursor, Roo Code, all of it. AI is getting rapidly better at coding and design. Claude recently launched their own design product. Tools like Pencil and others are competing with Figma. Google has their own design tools. Everyone's rushing into this space.

Websites are basically software—just less complex than full applications, at least for content-forward sites. AI has been helping with writing for a while now. But the new consideration, one that didn't matter even a few years ago, is this: how do you build a website that agents can work on effectively?

This became my primary criterion.

I thought about what I wanted this website to be. It's straightforward and content-focused. I wanted something easy to maintain, fast, and lightweight. I wanted to minimize platform risk—no single vendor that could de-platform me, change pricing, or force me into a new system. Something I could easily migrate to a different host without catastrophe. Something I could back up completely.

Jamstack made sense. Markdown in Git made sense. And crucially, these choices are incredibly AI-friendly. LLMs are extremely comfortable working with Markdown. They understand Git. They can read the entire codebase, suggest edits, implement changes.

My criteria came down to three things:

AI-first: I want tools that agents can easily work with. Whether I'm using Claude Code, Cursor, or Kilo Code, they can all edit Markdown files and use Git. They can work on my website for me.
Platform independence: Full ownership and control. No vendor lock-in.
Low maintenance: Robust and simple. No brittle plugin ecosystems. Minimal attack surface.

I'm not automating the content pipeline—I still want this to be my website, in my voice. But these AI tools handle the day-to-day work of running a website, letting me focus on what I actually enjoy: writing.

Why This Stack

I chose Astro as the framework, Keystatic for the CMS, and Netlify for hosting.

Astro is purpose-built for content-rich websites. Their marketing says "fast by default" and they mean it:

Zero JavaScript by default: Pages ship as clean HTML. No hydration overhead, no unnecessary JavaScript weighting down the page. Just fast-loading content.
Islands architecture: You can add interactivity where you need it, but the rest of the page stays static. A search bar might need JavaScript. Your blog post doesn't.
Framework-agnostic: If I want to sprinkle in React components, Vue, Svelte, or even vanilla web components, Astro doesn't force a specific approach. I'm not locked into any single frontend paradigm.
Content collections: Built-in support for type-safe content (like my Markdown blog posts) with automatic routing, validation, and even type generation. It's exactly what you want for a site like this.
Flexible rendering: I can start with static generation, but Astro can also handle server-side rendering or hybrid approaches if my needs change. I'm starting simple, but I'm not locked in.

For the CMS, Keystatic is intentionally minimal. I didn't want the bloat of WordPress plugins or another platform to maintain. Keystatic gives me a nice editing interface, but since it's Git-based, my content lives alongside my code—version controlled, portable, and immediately accessible to any AI agent.

Netlify handles the infrastructure. I've used them for years. Push to GitHub, site builds and deploys automatically. Rollbacks are a click away. It's the same CI/CD workflow that's been standard in Jamstack for a decade, and it just works.

The Real Lesson

The web keeps evolving. We went from LAMP stacks to Jamstack. Now we're entering the agentic era.

I'm worried about dead internet theory—the idea that AI-generated slop will flood the web with low-quality content. I don't want to contribute to that. But I do want to use AI as a tool to build and maintain my corner of the web more effectively.

The lesson after 15+ years of building websites is this: choose tools based on your actual needs and constraints. Don't chase complexity for its own sake. Don't default to "industry standard" if it doesn't fit your situation.

For me, right now, that meant building something that works seamlessly with the AI tools I'm already using every day. Something I own completely. Something that will still work in ten years regardless of which hosting company I use or which AI coding assistant is popular.

The stack—Astro, Keystatic, Netlify, Markdown, Git—isn't exciting. But it's robust, it's portable, and it's agent-ready.

Sometimes the best technology decision is the boring one that lets you focus on what actually matters: the content, the ideas, the work you want to share.

That's what I'm doing here.