The platform we run ourselves
The studio's own operations platform — adaptive interviews, research, drafting and a durable job pipeline — built as one Go modular monolith and running in production.
A studio this size loses its scarcest hours to the work around the work — preparation, research, follow-up, and the admin that surrounds every conversation. None of it is billable and none of it compounds.
One Go modular monolith with schema-per-module Postgres, AI agents behind domain ports, and durable Postgres-backed jobs. The slow, reversible work runs unattended; anything that reaches a person stops and waits for one.
Running in production. The architecture has since survived a complete swap of the AI framework by changing one adapter file — which is the result we actually cared about.
Most studio sites show client work. This one is ours, and it is the honest answer to "can you build the thing you are describing" — because you can read what it does and then judge whether the reasoning holds.
Where the line sits
The most useful thing in it is a refusal.
Agents do the slow, reversible work: reading, summarising, assembling what is already public about a company, preparing a draft. Every one of those is recoverable — a mistake is a row in a database, corrected before it matters.
Nothing is sent by a machine. A message that reaches a person has been read and sent by one, and the system's capacity to send is metered, monitored, and cut off automatically if quality drops.
Autonomy is worth having exactly up to the point where a mistake stops being reversible. That line is a design decision, not a technical limit — and it is the same judgement any system we build for a client gets: which steps can be undone quietly, and which ones reach the outside world and therefore need a person's name on them.
One monolith, not six services
Three products live in it — a discovery tool that runs adaptive interviews, the system that runs the studio's own pipeline, and this site. They share one Postgres instance with a schema per module and a migration ledger each. Modules talk through domain interfaces, never through each other's tables.
That buys most of what people reach for microservices to get — isolation, independent migrations, clear ownership — without paying the operations tax of a distributed system for what is, at the end, one person on call.
The AI is behind a port, and that mattered
Every AI capability is a domain interface (Capability, Interviewer,
Drafter) with the framework hidden behind an adapter. It looked like ceremony
when we wrote it.
Then the official Anthropic Go SDK and Genkit turned out to be mutually incompatible in one module — a hard version conflict on a shared JSON-schema dependency, no resolution available. The entire AI layer had to move.
It touched one adapter file. Nothing in the calling code changed.
That is the thing worth hiring for: not the framework choice, which was wrong and got replaced, but the seam that made being wrong cheap.
Why we show it
Every claim on this site about how we build is one you can check against a system that is actually running, rather than against a description of one. If the reasoning above sounds right to you, that is the useful signal. If it sounds wrong, that is a more useful signal still, and cheaper than finding out later.