Being the build partner behind a design studio
When a design studio hires Fathom, the studio is the client — not the end business paying the studio. We have run that model with twenty-plus design partners. Most of what makes it work is decided in scoping: who directs, who invoices, and what the handoff actually includes before any code is written.
Why a studio brings in a build partner
Design studios that are good at design are frequently not staffed to build. Hiring an engineer is a permanent cost set against project work that arrives in bursts. Subcontracting an individual developer means the studio absorbs project management, code review, and the risk of that person being unavailable in month four. Neither option is appealing.
The alternative is a partner who takes the build as a unit — scoping, engineering, QA, deployment, and the support tail — so the studio stays in the part of the work it is good at and wants to do. That is the arrangement. When it works, the studio's output goes up without their headcount changing.
It only works if the partner is genuinely uninterested in owning the client relationship. A build partner who quietly angles to become the client's agency is a threat, and studios can tell.
The studio is the client
The single most important operating decision is that our client is the studio, not the business paying the studio. We invoice the studio. We take direction from the studio. When the end client wants something changed, that request reaches us through the studio, and our answer travels back the same way.
This feels inefficient and occasionally is. A question that could be answered in ten seconds takes a day of relay. We accept that cost because the alternative — two parties both giving direction, one of whom never agreed to the scope — is how projects go sideways.
The exception we make is technical. On some engagements we sit in a shared channel and answer implementation questions directly, with the studio in the room. What we do not do is negotiate scope, timeline or price with anyone but the studio.
Meeting each studio where they are costs us reuse. Holding the engineering constant is what makes that affordable.
The handoff that works
The best design handoffs we receive are not the most detailed ones. They are the ones that are explicit about which decisions are fixed and which are ours. A file with pixel-perfect desktop comps and nothing else has silently delegated every responsive decision to us without saying so. We will make those calls, but the studio may not like where they land.
What we ask for is the states, not just the resting appearance. Hover, focus, loading, empty, error, too long. A page designed only in its ideal state will meet reality on our machine, and reality includes a client who writes a nine-word headline where the comp had three.
And the content model, at least loosely. Which parts of this page does the client edit? That question changes the build more than any visual decision, and it is far cheaper to answer during design than after we have built a page that assumed fixed copy.
The parts that are genuinely awkward
Credit. We do not appear on the site, we are frequently not in the case study, and work that goes into our own portfolio needs the studio's blessing first. That is the deal, we knew it going in, and it is still occasionally strange to watch something you built get written up without you. The compensation is that studios who trust you come back, and repeat work from a small number of partners is a better business than winning strangers.
Support after launch. The end client emails the studio about a bug. The studio forwards it. We fix it. Who pays depends on an agreement somebody should have written down, and if nobody did, it is usually the studio absorbing it. We try to settle the support arrangement during scoping, because an unbudgeted maintenance obligation is how a good partnership quietly goes cold.
Disagreeing with the design. Sometimes a design has a problem only visible from the build side: an interaction that will be slow against real data, a layout that will break with real content, a pattern that will fail on touch. Raising it well matters. Our version is to bring the specific case, propose the smallest change that fixes it, and defer if they still want it their way. It is their design.
Working with more than one studio
Running this model with twenty-plus design partners creates a tension worth naming. Each studio has its own conventions: how they name things, which tools they live in, how much process they want, whether they expect daily updates or a weekly summary. The efficient move is to impose one way of working on all of them.
We mostly do not, and it costs us. Meeting each studio where they are means more context-switching and less reuse of process than we would like. What we hold constant is the engineering underneath — the stack, the review standards, the way we scope — because that is where consistency actually buys quality. What we let vary is the collaboration surface, because that is where a studio's preferences are cheap to accommodate and expensive to fight.
What genuinely transfers between engagements is narrower than you would hope. Not components, usually, because designs differ too much. What transfers is the shape of the problems: how a content model wants to be structured, which handoff gaps show up every single time, what breaks once real content arrives. That accumulates, and it is most of what a studio is buying on the second project.
What makes a partnership last
Predictability, mostly. Studios do not need us to be brilliant. They need to be able to tell their client a date and be right. That means estimates we hold to, and telling them early when we will not — early enough that the studio can manage it rather than absorb it.
Consistency of build quality matters more here than in direct work, because the studio is putting their name on it and taking the call when something breaks. Every corner we cut becomes their problem with their client, in a conversation we are not part of.
And discretion, which is the whole premise. The end client never learning our name is not a limitation of the model. It is the product.
Questions
- What does a build partner actually own versus the design studio?
- The partner takes the build as a unit: scoping, engineering, QA, deployment, and the support tail. The studio stays on design and the client relationship. Direction, scope changes, and pricing run through the studio — not around it.
- What makes a design handoff buildable?
- Explicit decisions about what is fixed versus open, plus states beyond the ideal resting view — hover, focus, loading, empty, error, and too-long copy. A rough content model (what the client will edit) changes the build more than most visual polish.
- Why keep the end client from knowing the build studio?
- Discretion is the product of the model. The studio puts its name on the work and takes the support call. A build partner angling for the client relationship is a threat studios can detect, and it kills repeat partnership.
Sources
- Fathom — how we work
- Sanity — designing for editors — Useful when the handoff must define what clients edit.
- W3C — designing for different states — Empty, error, and focus states belong in the design handoff.