The Site Meta-Project

Starting a software project involves so many things that have to get done before getting down to the actual work of developing the code itself: defining the scope and audience, picking a development language, coming up with good names… and putting up a website.

My main gripe with contemporary web tech is that the state of the art is so complicated. Following the trends means piling up layers and layers of libraries and modules. Mounds of javascript for everything. Complex deployment flows. Nothing is elegant.

When I sat down to make the site you’re reading right now, I did what I typically do these days: I asked an LLM for help. Collaborating with AI to do tech work is a major part of the motivation for this project. My aim is to find out what AI is actually good for, figure what gaps there are to fill, and then decide if there’s something I can do about filling them. More on that in future posts.

For this site, I asked GPT-5.2 to help me come up with a plan for a simple website. A landing page, top nav, link to github, a blog. It wound up producing a plan for Astro+Keystatic+Coolify+Hetzner+GitHub Apps+Docker+CI+Webhooks… and more! It seemed like a lot of tech for a little job, but I decided to follow the steps I got. I hoped I might learn something along the way.

What I actually learned was: bad idea. I didn’t think enough myself. I put myself in the hands of the LLM and its advice without knowing completely what I was going to get when everything was done. So, I got bunch of services that didn’t really talk to each other in a way I liked. I threw it away. A day of work wasted.

That was yesterday. I went to sleep. I woke up at 2:30 AM with an idea for doing better. I sat on the couch for an hour or so and sketched it out. I then worked on it couple more hours after morning coffee. Between me and Claude/Opus and GPT 5.2, I came up with a plan, with this as the introduction.

Static Site + Blog Infrastructure Plan

Astro + MDX · rsync deploy · Linode · Cloudflare DNS

This document defines a boring, sane, long-lived infrastructure for a content-driven website and blog.

The guiding principle is simple:

Build locally. Inspect everything. Deploy files. Serve static content. No CI rebuilds. No Docker. No GitHub in the deploy path. No surprises.

I then banged out the work itself in about two hours. You’re looking at the result now. The site generates static pages with a single deploy command that takes my local files (which must not have any uncommitted git changes), compiles them down, and then pushes that to a site on linode. I can view posts in the browser as I am writing them by hitting save and have the server hot-reload the page. When I deploy, I get exactly on the deployed site what I saw locally. As it says, No surprises.

It feels like this is the way that blogs should work. Live editing and previews. WYSIWYG in its way, with local and deployed versions of the site the same.

It’s about as elegant a solution as I could think of, with the state of web tech today, and without shifting my focus (for too long) away from the real goal of this project, which is to figure out some software to help AIs with code refactoring.