How we work
Every yes has
a date on it.
Our homepage draws the method as four marks: propose, gate, approve, file. This page spells out each step and shows it happening, in dated moments from the record of this site's rebrand.
The chain,
step by step
All four moments fall on October 3,
2026, and the times are Pacific.
Propose
A draft you can
send back.Each job opens with a written scope, and each page with a design draft. A person reads both, and either can be sent back.
Work page drawing · Oct 3
We drew a first version of our Work page. At about 4:10 PM Frederick sent it back, and nothing was built from it.
Gate
Checks that
can say no.Drafts are checked: the copy against the code it describes. A draft that fails waits for a fix.
Checked before a site ships
Contrast, measured
in placeEvery text color is checked against WCAG AA on its real background.
A clean build
before a deployA deploy waits until the full production build passes and every warning is read.
A security scan
before launchWe scan the staged site and fix anything rated High or Medium first.
The database decides
who sees whatA signed-in client sees their own project, and a wrong link shows nothing at all.
Your domain and
content, in your nameRegistered to you from the first day, on every site we build, Foundry included.
Homepage copy · Oct 3
At 2:36 PM a read of our new homepage against its code found two lines, and one word in a third, that promised more than the code did. None of it went live. That night Frederick ruled they be rewritten to what is true, and four passages changed.
Approve
A yes to one
named thing.Each yes covers one scope, drawing or commit and nothing more. On your build, the scope and the design draft need your yes as well as ours.
Homepage drawing · Oct 3
At about 1:55 PM Frederick read the first drawing of our homepage and answered “build it”. The code came after that, on a development preview.
File
Files that outlast
the chat.A build leaves files behind: a scope in plain text, drawings in Illustrator, code in a repository. Every approval is filed with them.
What we keep on record
Approvals, pinned to a version
Code is approved by its commit, the id of one saved version. A scope or a finished film is approved by its hash. A later edit needs a fresh yes.
A ledger line per confirm
Every confirm Frederick gives adds one line to the build's ledger, whether the action then ran or was turned away.
Misses, written up
When we miss something, we write up what happened, how we found it and what we changed. Those write-ups sit on our Work page.
- Read the misses
The brief · Oct 3
At 12:54 PM Frederick approved this rebrand's brief on our build board. The board filed the time and the brief's hash, a fingerprint of its exact text, so any edit would leave the approval stale.
What waits
for a person
Our coding agents edit files and run tests
freely. These four wait for Frederick.
A deploy
The live site changes only when Frederick gives his go for that one change. Passing every check does not count as a go.
A database change
Inside a build, a change to a live database runs only after Frederick confirms it, and we check the database itself afterward.
A push in a build
While we work on a build, its commits stay on our machine until Frederick confirms the push.
A long paid run
A run of more than about 20 paid calls, to an AI model or a voice service, waits for Frederick's yes.
An agent can draft an email or a post.
Frederick sends it, or it stays a draft.
What stays private
Client records
What a client shares with us, from files to mail, appears on this site only with that client's okay.
Keys and passwords
They stay out of everything we publish, and a scan checks every commit for them.
Inside the tools
Our case studies explain how parts of Studio OS and Media OS work. The rest stays in the studio.