What we can show you
Our own systems, until yours.
Client work appears here only with the client's written approval. Until then, here is our own.
3systems, all our own
0client entries, pending written approval
01This website
A studio website, built on a fixed day. Our own, not a client's.
02The scanner
The free scan on this site. Our own, not a client's.
03The fleet orchestrator
The system that ran the build of this site. Our own; no client data appears here.
Every entry below follows the same template: what the system is, the constraint, what we found, what we did, what we did not do, the numbers we can verify, and what we would do differently. No logos, no quotes, no metric that was not measured. When a client approves an entry in writing, it goes here in the same shape.
Systems3 entries, one template
This website, built by the fleet in parallel bays and reviewed by a person
A studio website, built on a fixed day. Our own, not a client's.
- load
- Internal build, September 2026.
- team on it
- The founder on review and merge. The fleet on research and build, one bay per page group.
- client data
- None. Our own system, no client name or repository appears.
- the system
- A Next.js site on Railway: the pages you are reading, a read-only scanner behind an API route, a lead endpoint, and a build log generated from the repository's own history. No database of its own.
- the constraint
- A fixed day, and one rule: every sentence on the site had to be traceable to something true. That rules out most of what a studio site usually carries, such as counters that render as zero without JavaScript, a logo wall, and a team page of headshots. What was left had to be written from evidence.
- what we found
- That a website is mostly a numbers problem. Before any page was written, one lane compiled a ledger of every numeral that could appear on the site with its source and its status, and it retired a comparator two other lanes had already used. The copy got rewritten to the ledger, not the other way round.
- what we did
- Ran research in parallel bays (voice, offers, proof, name, stack, identity), then one synthesis. Built the site the same way: one bay per page group in its own git worktree, screenshots at desktop and phone width on every branch, a person reading each diff before merge. The log page is generated from git at build time so it cannot drift from the truth.
- what we did not do
- No logo wall, no testimonials, no ratings, no counter that is not read from data with a timestamp. We did not make the repository public, so nothing here says the commits are public.
- numbers we can verify
- The commit dates and line counts are on the log, generated from the repository at build time. We do not print them here twice. Nothing else about this build was measured, so nothing else is claimed.
- what we would do differently
- Write the numbers ledger before the copy, not after. Two lanes had to be corrected when the ledger retired a figure they had already used, and that is a day we would not spend again.
- follow-on
- This site is on our own retainer: the fleet keeps building it and the log shows when.
The scanner: a read-only production-readiness engine behind one route
The free scan on this site. Our own, not a client's.
- load
- Build and hardening, September 2026.
- team on it
- The founder on review. The fleet on the build.
- client data
- None. Our own system, no client name or repository appears.
- the system
- A single TypeScript module with zero dependencies. It fetches a page the way a browser does, reads the scripts the page loads, and looks for secrets in the bundle, a service-role key in the browser, missing security headers, exposed environment and git files, and database tables readable with the app's own public key. It returns a typed list of findings and a grade.
- the constraint
- A scanner that has never run for a stranger has a lifetime scan count of zero, and any number we printed about it would have been invented. So the constraint was to ship a tool with no history and say so, rather than dress it in a counter.
- what we found
- That a scan can prove less and still say enough. A first draft of the database probe read a real row to show a table was open, which is more than a scan needs, so the shipped probe reads nothing and only checks whether the table answers. The guard against scanning private addresses checked strings and not what those names resolved to, the only consent was a sentence under the input, and the finding text used punctuation the house does not use. Each of those was fixed before the route went live.
- what we did
- Built the engine into this site as one file behind one route, wrote the acceptable-use terms it needed, and put them in front of it. The scan stays read-only: ordinary requests any browser makes, no writes, no storage of results unless you ask us to send them to you.
- what we did not do
- We did not publish a scan count. The honest starting number is zero, and a counter that starts at zero is either read from a table with a timestamp or not shown. We did not give the scanner a name of its own; it is the scan, on this site.
- numbers we can verify
- None yet. A scan takes seconds, not minutes, and the code puts a hard ceiling on how long it may run. Counts appear on the scan page only when they are read from a table, with the date they were read.
- what we would do differently
- Write the terms page first. A scanner without acceptable-use terms in front of it is a liability the day it goes live, so the terms and the privacy page belong in the first commit of a tool like this, not the last.
- follow-on
- The scanner is the intake for the crane, our rescue offer. The list it gives you is the list we would start from.
The fleet orchestrator: many metered Claude Code sessions in git worktrees, with a human gate
The system that ran the build of this site. Our own; no client data appears here.
- load
- Internal tooling, built and rebuilt through 2026.
- team on it
- The founder on review. The fleet on itself, which is the one job it is not allowed to merge.
- client data
- None. Our own system, no client name or repository appears.
- the system
- A job queue that spawns Claude Code sessions, one per job, each in its own git worktree of the target repository, each metered. A sentinel runs checks on every branch and fails first. A person is the gate: nothing merges, deploys, or deletes without one.
- the constraint
- Token cost scales with the number of sessions, and a worktree gives isolation, not coordination. Two agents in two bays can both be right and still collide at the merge. The orchestrator had to make that visible before it became expensive.
- what we found
- That agents fail in a small number of repeatable ways: they declare a job done because a test passed, they drift out of their bay into files they do not own, and they hit a rate limit and stop quietly. Each of those got a check, and the checks live in the same branch as the work so they cannot be skipped.
- what we did
- Built the queue, the per-job metering, the worktree per job, and the human gate. Wrote a runbook for each repository the fleet touches, with the definition of done the sentinel reads. Kept the fleet's own cost printed on every branch it opens.
- what we did not do
- No autonomy past the seam. The fleet does not merge its own work and it does not touch production. We did not make the orchestrator public, and no client repository or client name appears in anything we show about it.
- numbers we can verify
- None on this page. The live counts (jobs, bays, cost) belong on the fleet page, read from the orchestrator with a timestamp and a method line, never typed.
- what we would do differently
- Trust health probes less, sooner. A probe that returns a success code is not a fleet node that works; we now check for the exact response we expect, not the status code, and we would have started there.
- follow-on
- Every load on this site runs through it. Watch it on the fleet page.
Each system above has a page where you can watch it. The fleet page replays a real job through the bays. The scan runs the scanner on a URL you own. The log is this site's own commit history, generated at build time.
If you want to see the machine on your own task rather than ours, the first load is a Sprint Zero: fixed price, $3.5k to $7.5k depending on scope, credited to a retainer if you continue.