One person.
Whole systems.
Municipal websites, registries, and the data tools that keep records moving. Built and maintained by one person.
The work
Most of the shelf is one municipal stack: a public website, four registries, document tracking, and assistance cases. The registries share one shape: intake, requirements, approval, and a card or ID. Underneath, the same four pieces: FastAPI, React, PostgreSQL, and Docker.
The data tools come before the records: one pulls structured data from websites, the other imports spreadsheets, CSV, JSON, and database sources. Neither asks anyone to retype a row.
Registries carry records and printouts. Tracking carries a queue. Assistance carries cases, budgets, and releases. The website carries the public side.
This site is smaller, but built the same way: Flask, PostgreSQL, server-rendered Jinja, and a Bootstrap admin, deployed on Railway. The shelf and the blog live in the database; the shelf on the home page is rendered from it.
How a build runs
I start with the manual job: the spreadsheet, the logbook, the stack of forms. Then I build the smallest complete system that replaces it, with migrations, tests, and a way to fix mistakes after it goes live. When it ships, I stay on it. The office keeps using it, so it keeps changing.
No account manager, no handoff between scoping and building. The person who decides what gets built is the person who fixes it when it breaks.
Who it is for
If your week includes retyping the same data into a second system, tracking requests in a notebook, or producing the same report by hand every month, that is the work I build for. The first conversation is about the manual job, not a feature list.