The GUS Stack — Go, Unix, SQLite

When a software need or idea arises, it’s now easier to chat with an agent to spin up a full-blown app than it is to capture notes or make a planning doc for later. Even when it is YOLO or disposable software, it’s nice to build on a simple and well-designed shared foundation instead of always re-building from first principles. Here’s the foundation that’s working well for me…

Go, Unix, SQLite (GUS) Stack

Unix, its philosophy, and many distributions have long dominated for development and production. I’m always hacking on a MacBook with Darwin and deploying to a Linux-based platform like exe.dev, fly.io, or Hetzner.

SQLite’s embedded engine and single-file-on-disk design make it the most widely deployed database engine in the world. Its simplicity makes it the obvious starting point for small apps, especially on a host like exe.dev that has a persistent disk.

Go, its “batteries included” standard library and build/test tools, and its “idiomatic Go” syntax and style that has been stable since 2012, makes an excellent language for agents and humans. A single binary to download and run is the fastest way to bootstrap a computer, and fast rebuilds make a great development loop.

exe.dev adds Typescript to their “GUTS” stack but I prefer as much server-side rendering (SSR) as possible with a little HTMX or vanilla and build-less Javascript sprinkled around only as needed. Constraining the language, build, and test tools makes my agent and my code review life better.

Within the Go ecosystem I favor:

• cockroachdb/errors for errors with stack traces
• templ for type-safe HTML templates (with htmx for reactivity and tailwindcss for CSS)
• fuego for an OpenAPI spec generated from our web handlers
• sqlc for type-safe code generated from SQL
• modernc.org/sqlite for a pure Go sqlite library
• goose for SQL and Go migrations
• dbos for durable workflows in SQLite

Automatic Testing

Agentic coding works best with fast feedback for the agent to verify its work. The fastest feedback loop continues to be well-written unit and integration tests.

For both the dev loop and integration tests, it’s critical to give the agent “eyes” on the actual rendered application. For that I use a headless Chrome via DevTools Protocol (CDP) through rod as a library in tests, and rodney as a CLI for one-off validations.

Telling the agent to “verify the page layout with rodney” catches a ton of small bits of polish that would take a lot of back and forth chatting otherwise.

Having it write a test that verifies the DOM state after clicking through the happy path results in features that work in one shot and don’t regress in future development.

Try it Out

I’ve packaged this all up in a GitHub template, so a simple and productive app foundation is one chat away.

Use https://github.com/housecat-inc/scratch and build a dinner party RSVP website.

If you want to see a full-blown product built with these approaches, sign up for the Housecat Email and CRM Inbox at https://housecat.com.