Hello, sfalcon.dev

How I built sfalcon.dev using swamp

by Seth Falcon ·August 24, 2026

It’s been 1,209 days since my last post over on Substack. It’s been even longer since I set up a static site generator to host my own site.I used nanoc through 2017, then Hugo in 2019. In that time, the world has changed. The day-to-day of the work I do as an engineering leader and software engineer is radically different. The change has played out with a speed and depth that I’ve never experienced before in my 20+ years working in software. So this seems like as good a time as any to pick back up on a habit of writing things down and sharing them. The break was certainly long enough.

Meanwhile, some things haven’t changed. If you redo your blog, your first post documents what you did. Here we are.

a mini factory

Instead of starting with a static site generator, I started with an agent (Claude Code) and a new AI-centric automation tool I’ve been hearing about called swamp.Yes, this whole exercise is an excuse to explore swamp, which fits a long tradition of kicking the tires on automation tools by setting up a blog. Swamp makes it easy to develop repeatable workflows with your agent. And rather than pointing my agent at building the site straight away, I asked it to build a software factory first. This is something swamp knows how to do using the @swamp/software-factory extension.

A factory? Building a blog is a software project, even if small. There are build vs buy decisions to make, scripts that wire things together, and a workflow to define for publishing. When using agents to implement software projects, I’ve become convinced that you get better outcomes by defining a “software factory” that structures how changes flow from “inbox” to “done” and sets the roles and rules of engagement for the agents doing the work. So the first order of business was to build a lightweight software factory for the project: somewhere I could create issues, have them worked and reviewed, and approve them.

In a new repo, I ran swamp repo init, started Claude Code, and gave it a short brief (see the brief below). After a few turns I had a factory that could create issues, plan them behind a review gate, implement them with a review, and ship after my final approval. My agent and I could then use this to organize the work and adhere to its rules while building.

The factory stages

Now, the UX for this factory is rather rough. Creating, listing, and inspecting issues all take command-line calls with multiple options, and the output is JSON that needs additional parsing to get a concise summary:

swamp data get issues index --json \
    | jq -r '.content.issues[] | "\(.id)\t\(.status)\t\(.title)"'

But my agent didn’t mind. We planned out the project and implemented six issues: five through the factory, and one by hand after the site was already up. Once the core was working I got curious about cycle time, and because the factory records every stage transition, my agent could pull wall-clock start-to-done for each issue straight out of swamp’s datastore.These durations include (substantial) idle time when an issue sat waiting for my approval while I was off doing other things.

All of the data for the factory lives in swamp’s datastore. For each issue, there’s a record of the artifacts produced by each stage as well as the approvals. Keeping all of that data behind the scenes and making it queryable for later use is a big part of swamp’s power.

Having agents write code and then do a review pass is not new. But in past setups, I couldn’t quantify what was happening in these loops after the fact. Here, that data is available. Across the five factory runs, review recorded twenty findings: three high, seven medium, and ten low. If I wanted to go back and inspect any of these, I could. They’re not just lost to a session transcript.

All of this is, admittedly, overkill for building a personal site, but on a real project, access to this sort of data is a great starting point for optimizing agent-driven software delivery.

what about the site?

I went with Astro on Cloudflare Pages. Markdown in, static HTML out. The only custom piece is a small plugin that turns :sn[...] and :mn[...] into the sidenotes in the margin. Swamp methods cover the rest: new_post, lint, and deploy, which stops if lint fails. None of it is novel. The interesting part was the factory and driving the implementation with swamp.

wrap up

I have a working site that my agent built using a well-defined workflow that I can reuse to add features later on. Did I get a better result by using a factory and swamp? Answering that would take an eval comparing this against other approaches. From a how-it-felt perspective, this was a success. I didn’t have to redirect the agent, issues were found and fixed, and a rich set of data to explore came along at zero extra effort.

Writing, for me, is still the slow part. I’ve spent longer writing up this post than building all of the tooling to power the site. Maybe I’ll get faster if I write more often than every 1,209 days. Here’s hoping.

the brief

# sfalcon.dev

Personal blog for Seth Falcon (sfalcon). Created using a swamp software
factory. Built as a static site generator.

## The factory

We are starting completely green field. Define a software factory so that we
can create issues, work them, and ship them. We will iterate on the factory
as we go. The minimal starting elemnts

## What our factory is going to build:

A static site generator. Source is markdown. Decide on an existing engine or
build our own.
Where we host needs to be decided. AWS? Cloudflare? Other?
Desired domain: sfalcon.dev or userprimary.net (I already own this one).
deployment automation to publish
usage telemetry (how many views, etc)

post creation (template creation)  and site publish will be swamp workflow or
model runs.

style: I want an Edward Tufte informed style. Readability is key. 
Margin notes would be awesome. Expect that I'll have code blocks. 
Simple. neutral tone palate for colors.