// field notes
Field notes.
Every project here reuses something from an earlier one. We keep a graph of those handoffs — what came from where, and why it worked the second time. This is the public slice of it.
Entries are drawn from that graph and published after review, so nothing here is a summary of a summary. Client work appears only in the shape of the technique, never the client's business.
2026-09-01
The locked-voice prompt, pointed at our own front door
The pattern that keeps a consumer product's voice consistent — brand rules written into a system prompt with hard forbidden-phrase lists — became the architect, the blueprint desk on this site.
A voice locked at the prompt layer survives a one-shot public endpoint the same way it survived a SaaS: the rules travel with the words.
2026-08-31
The page engine's third port
The build-at-deploy page engine written for a used-equipment marketplace, then reused for a service business's town matrix, pointed at this site: pages generated from a content matrix, sitemap and structured data emitted with them.
The third port proved the pattern is domain-free — pages are a build artifact of a matrix, and this time the matrix was search demand instead of towns.
2026-06-25
A polish pass on one product became the standard for all of them
A UX and accessibility pass on a single consumer product got written up as a canonical pattern set rather than left in that codebase — press states, motion timing, focus handling, contrast.
The labour was spent once. Every surface built since inherits it without anyone re-deciding, which is the only reason a one-person shop can hold a quality bar across unrelated products.
2026-06-24
A cheap filter first, a model only on what survives
Keyword blocklists always miss the next weird thing — a Buick, a Peloton, listed under restaurant equipment. So a model now validates what the regex kept, before anything renders. Regex runs free on everything; the model sees only new survivors, batched about forty per call, each item checked once in its lifetime, failing open if the call fails.
It caught 10 bad items out of 240 in the first pass and costs pennies a day. Putting the expensive check second, and only on what the cheap check could not settle, is what makes a model affordable in a pipeline that runs forever.
2026-06-22
A client feature turned out to be the product
One client build got taken further than the brief asked — a named assistant that writes the site's daily content, an owner panel instead of a CMS, review syncing on a timer. When the dust settled, those features were not a favour. They were a pipeline.
The asset is the pipeline, not the build: clone it, re-scan to the next client's data, re-skin the persona. The first one was expensive and every one after is mostly configuration.
2026-06-21
One button, sweated once
A single UI detail on this site was worked over until it was right — press timing, the border resolve, the focus state — and then promoted from a one-off to the standard every later surface starts from.
Quality compounds only when a perfected detail becomes a default. Otherwise you pay for it again on every project and it comes out slightly different each time.
2026-06-21
A dormant account was an asset, not a dead end
An Instagram account with 10,100 followers had gone quiet. Rather than start a new one, it was wired to a generation pipeline and put back to work publishing daily.
The audience was already built. Reviving a dormant asset beat starting from zero, and that calculation is almost always worth running before anything gets abandoned.
2026-06-21
Harvested the schema, left the system
An existing research tool was evaluated for adoption and not adopted. What got taken was its schema discipline — how it structured and constrained its data — dropped into infrastructure that already existed here.
Extract the principle and integrate it natively into what you are already holding. Grafting a whole system in because one part of it is good is how codebases acquire dependencies nobody understands.
2026-06-20
A marketplace engine, pointed at a service business
The city-by-category page engine built for a used-equipment marketplace was reused whole for a local service business: towns crossed with services, roughly eighty pages plus a guide library, generated from data files instead of written.
It was a re-skin, not a rebuild, because the engine had already been proven somewhere unrelated. Coverage stopped being a writing project and became a build decision.
2026-06-10
A pure library moved without a fight
The calculation library written for a paid product became the content engine for a social publishing bot — same formula, entirely different surface, no adapter layer in between.
A pure function with no dependencies on its original context transfers at zero cost. That is worth remembering while writing the first one, because it is the only reason the second use is free.
2025-11-11
The second product reused the first one's skeleton
The whole shape of a generation SaaS — provider abstraction, the wizard into paywall into rendered PDF — was reused for a second, unrelated product, and deliberately simplified on the way: one provider instead of several.
The second build traded resilience for speed on purpose, and shipped in twenty-eight commits. Knowing which parts of a proven shape you are allowed to drop is most of the speed.
Why keep it in public
A studio's real output is not the list of things it built, it is the set of techniques that survived contact with a second problem. Keeping the log where anyone can read it means the claim and the evidence arrive together, and it forces the same discipline internally: a technique that cannot be described in one honest sentence probably did not transfer.
New entries land as work ships, not on a content calendar. If nothing carried over this month, nothing is posted.
studio@anchor163.com
// copied