Narwhal

Narwhal is my product-management tool for the things I want to build or have built — articles, books, sites, apps. It’s the system of record: name a product, attach design docs, and move them through a real status instead of losing them in a pile of markdown.

Under the hood a Product is the authoritative cross-service identifier the rest of my platform hangs off — other tools reference a Narwhal product UUID rather than inventing their own notion of “which project is this.” It owns design docs too: typed as feature, discovery, spike, or system doc, nestable under a parent, and syncable to and from plain markdown on disk so my editor and git stay a second source of truth. Today it’s a ConnectRPC API and a CLI with a Kafka worker; the public-facing catalogue is still plumbing waiting on a front end.

Narwhal is my product-management tool for keeping track of the things I want to build or have built — articles, books, websites, apps, whatever. I had ideas and half-finished projects scattered across notebooks, READMEs, and my own memory, and I wanted one system of record: a place to name a “product,” attach design docs to it, and track those docs through a real status (draft, review, approved, deprecated) instead of losing them in a pile of markdown files.

Under the hood, a Product is more than a to-do list entry — it’s the authoritative cross-service identifier that the rest of my personal platform hangs off of. Other tools I run (Rabbit for tickets/sprints, Meerkat for project tracking, Magpie for search) reference a Narwhal product UUID rather than each inventing their own notion of “what project is this.” Narwhal also owns design docs: a doc belongs to a product, can be typed as a feature, discovery, spike, or system doc, and can nest under a parent discovery doc so exploratory work and the features it spawns stay linked.

Right now Narwhal is a Go service and CLI, not a web app — there’s no UI yet, just a ConnectRPC API backed by Postgres and a narwhal command-line tool for creating products, writing docs (opened in $EDITOR), and moving them through status. Docs can also be synced to and from plain markdown files on disk, so I can write in my editor and keep git as a second source of truth. A background worker consumes the doc/product change events off Kafka to write those files, publish to the search index, and record back-references when a doc gets promoted into a Rabbit design.

The bigger vision — the personal site with book reviews, liked-sites lists, and a public product catalog — is still just an idea. What exists today is the plumbing: a place to define a product once and manage its design documents consistently, so that when I do get to building the public-facing pieces, there’s already a clean data model underneath them.