Beaver

Beaver is my CLI generator for standing up new Go services — it takes a protobuf schema and produces a running, production-shaped service instead of a folder of TODOs.

The workflow is schema-first: I write the domain model as protobuf messages and Beaver generates the stack around them — Go structs, a PostgreSQL repository built on squirrel, an interface and service layer, a ConnectRPC handler, a Kafka consumer stub, migrations, and a Cobra CLI. It also scaffolds the project itself: go.mod, Dockerfiles, a Makefile, linter config, and a CLAUDE.md of conventions. The boring 80% is generated correctly every time; the only hand-written code is the business logic that makes each service different. Most of the other services here were built with it.

Beaver is my CLI generator for scaffolding new Go services end-to-end — a tool that takes a protobuf schema and turns it into a running, production-shaped service instead of a folder of TODOs. I kept starting new services and rewriting the same entity structs, repository boilerplate, ConnectRPC handlers, and CLI commands by hand, so I built a generator that does it from the schema outward.

The workflow is schema-first: I write the domain model as protobuf messages, and Beaver compiles them and generates the full stack around them — Go structs, a PostgreSQL-backed repository built on squirrel, an interface and service layer, a ConnectRPC service, a Kafka consumer stub, database migrations, and a Cobra CLI (with a gRPC client) for talking to the running service. It also scaffolds the surrounding project itself: go.mod, Dockerfiles, a Makefile, .golangci.yml, and a generated CLAUDE.md so an AI assistant working in the new repo already knows the conventions.

I wanted the boring 80% of standing up a new service — the model, the plumbing, the CRUD — to be generated correctly and consistently every time, so the only code I write by hand is the business logic that makes each service actually different.