@aaronshipsit

Colophon

How this site gets built

A colophon is the note at the back of a book naming the type, the paper, and the press. This one is mostly about the press, because the press is the interesting part: the pages you're reading were built by AI agents pulling items off a roadmap board — a board running on the product this site exists to talk about.

It's a product dogfooding itself into existence, which is a nice sentence and therefore exactly the kind of sentence that needs checking. So: what's true today is stated flatly, what isn't true yet has its own section, and what you can verify from outside has its own list.

The stack, without the adjectives

Nothing exotic, and that's the point — the interesting part isn't what it's made of, it's how it gets assembled.

  • Front endNext.js 15 and React 19, server-rendered. CSS Modules and hand-written CSS — no component library, no utility framework.
  • APIFastAPI on Python, async SQLAlchemy, Alembic migrations. This site barely needs an API; it has one because everything in the fleet is shaped the same way.
  • DataPostgreSQL 17 and Redis 7.
  • HostingDocker Compose on a single host behind nginx. One command deploys, one command rolls back, and both are run by a human.
  • AnalyticsSelf-hosted Umami, consent-gated — no third-party analytics network, ever. It runs on the product site today. It is not switched on here yet, so this site currently measures nothing at all.
  • Error reportingServer errors go to our own self-hosted GlitchTip, never a hosted service — and it is a server-side path only, so nothing error-reporting-related runs in your browser. Same rule as the analytics: the reader's browser stays clean.
  • PlatformA shared internal library every product sits on: transactional email, billing, entitlements, audit and usage events. Vendored into the repository and pinned by checksum rather than by version range.
  • Contact formThe message on the contact page is emailed to me through that shared transactional-email path and stored nowhere else — no database, no ticket queue, no account. There's no CAPTCHA either: a hidden honeypot field and a couple of server-side rate limits do the spam work, so nothing runs in your browser to prove you're human. Same rule as the analytics and the error reporting.

The factory underneath

Every product here starts as one document: a vision with a named customer, a price, a first-dollar path, and written kill criteria. A tool I built — the app factory — turns that document into a working repository: web app, API, migrations, deploy and rollback scripts, health checks, backups, and the shared platform already wired in and tested.

That's why a personal site with nothing for sale arrives with billing and entitlements installed and switched off. It isn't ambition. It's that leaving the rails in costs nothing and bolting them on later costs a rebuild. The first commit in this repository is called, literally, "initial scaffold from app factory".

The files the factory owns are checksum-locked. If one of them drifts — mine or an agent's — the deploy script refuses to run rather than shipping something nobody reviewed. Guardrails that can be quietly edited by the thing they're guarding aren't guardrails.

The loop that built this page

Seven steps, in order. The first and the last are done by a person, and that is not a temporary arrangement.

  1. A human writes the spec. What the page is for, what it must never claim, and what would make it wrong. This is the slow part and it stays slow.
  2. It becomes an item on a board. The roadmap for this site is a FeatureJet board: ranked, with a status on every item. The product manages its own maker's website.
  3. An agent claims it. Work is pulled from the queue rather than handed out, and claiming is a status change on the item, so two agents can't quietly build the same thing.
  4. It gets built in isolation. Separate branch, separate working copy. Several agents work at once without stepping on each other's files — this page and its neighbours were written in parallel.
  5. The gates run. Types, unit tests, lint, a real production build, and browser screenshots at desktop and phone widths. A failed gate means the work isn't finished, not that the gate was unlucky.
  6. Evidence gets attached. The commit, what the tests covered, the screenshots. "Done" is a claim, and a claim with nothing under it goes back in the queue.
  7. A human reviews and merges. Every line, including the boring ones, including the ones that agree with me. Then a human runs the deploy. This step is not automated and isn't scheduled to be.

Who actually does what

The honest division of labour, because this is the exact place where people overclaim.

  • The human: writes the specs, sets the constraints and the refusals, decides what gets built and in what order, reviews every diff, runs every deploy, and carries the blame for anything that ships.
  • The agents: read the repository, write the code and the tests, run the gates, take the screenshots, gather the evidence — and push back when they think the spec is wrong, which is most of their actual value.
  • Nobody: decides what to build. There is no queue that fills itself. Every item on that board was put there by a person who had a reason.

The dogfooding, stated precisely

FeatureJet exists because agents need somewhere to take work from: a board of ranked items, an API to claim and update them, and a public record of what changed and when. Most feedback tools are built for humans to vote in. This one is also built for machines to work out of.

This site's roadmap is one of those boards, and these pages were built by agents holding one of its items. That's a real loop, not a staged demo.

It's also a small one: one site, one board, one reviewer. Take it as evidence that the mechanism holds at this size — not as proof that it would hold at yours. When it has been run at a bigger size, that will be written down too, along with wherever it broke.

What you can check yourself

Claims are cheap. These are the ones you can go and test without taking my word for anything.

Verifiable today
  • The agent API is public and documented: featurejet.com/docs/api and featurejet.com/docs/mcp. The claim-an-item-and-report-back loop described above is that API — the same one anyone else would use.
  • FeatureJet runs its own board in public, roadmap and changelog included, at feedback.featurejet.com. That is the product doing this job for itself where you can watch.
  • This site’s own board is public too, at aaronshipsit.featurejet.com. The backlog the loop above pulls from, what’s planned, and what has shipped are a page you can open with no account — so the roadmap here is now your evidence rather than my word.
  • The self-hosted analytics claim is checkable from the outside: view source on featurejet.com and the analytics script is served from a domain we run, not from a third-party network.
  • This site loads no analytics and no third-party scripts today. Also view source — the check is that there is nothing to find.
  • And the honest gap: this repository is private, so the stack section is not independently verifiable. It is written as versions and service names rather than adjectives precisely because that is the kind of claim that can be caught out later.

What isn't true yet

Three things this page would like to claim and can't, kept here so the rest of it stays worth reading.

  • Nothing here is autonomous. Agents don't decide what to build, don't approve their own work, and don't deploy. Overnight progress is real, and it happens because somebody was extremely specific the evening before and reads all of it the next morning.
  • Analytics are off. Umami is self-hosted and running for the product site, but the consent gate for this one isn't built, so no tracking of any kind runs here. That also means there's no traffic number to show you, which is the honest trade.
  • No live numbers. A page fed by real platform metrics is on the roadmap and isn't built. Until it exists, this site quotes no traffic, revenue, or customer figures anywhere — an empty results section is more useful than a decorated one.

Why publish this at all

Most sites hide how they're made, which is fine when the method is ordinary. Here the method is the most interesting thing on offer — more interesting than the writing, and it's the one part a competitor can't copy by reading it, because what takes the time is the specs, the constraints, and the reviewing.

If any of this stops being true, this page gets corrected before the marketing does.