What we mean when we say "build together".

DNL notes · 05.03.2025 · 7 min read

There is a version of agency work where the client hands over a brief and receives a solution. The agency disappears for six weeks and emerges with something polished and complete. It looks good in a presentation. It rarely works in the world.

The work we care about happens differently. It requires the people closest to the problem — the product owner, the domain expert, the user researcher who has sat with real users — to be genuinely present in the design and engineering process. Not as approvers. As participants.

That sounds obvious. In practice it is unusual. Most organisations structure their vendor relationships to minimise disruption to internal teams. The agency is managed, not partnered. Decisions are reviewed, not made together. The result is a product that reflects the agency's interpretation of the brief rather than the team's actual understanding of the problem.

"The best collaborations we have had felt less like client relationships and more like temporary team expansions."

Building together means something specific to us. It means shared working sessions where decisions get made, not just shared documents where decisions get annotated. It means the product owner can change direction on a Tuesday and the team can respond by Thursday. It means the designer and the engineer are in the same conversation about what is possible, not in separate conversations about what has been specified.

The best collaborations we have had felt less like client relationships and more like temporary team expansions. We bring capability; the client brings context. Neither is sufficient alone. The product that results belongs to everyone who built it — and it shows.