When a law firm hires outside counsel for complex litigation, they want a lead attorney who knows the matter, owns the strategy, and is accountable for the outcome. Not a rotating cast of associates who need to be caught up every time there is a call.

Custom software works the same way. Almost nobody does it that way.

The standard vendor model: an account manager fields the initial call, a project manager translates the requirements, a development team builds the thing, and someone else tests it. With every handoff, things get lost and assumptions fill the gaps. By the time code is being written, the developer is two steps removed from whoever actually understood what the client needed.

For institutional clients - law firms, investment offices, regulated enterprises - this creates specific problems.

Confidentiality

Every person who touches a project is a potential exposure point. A law firm sharing details of its billing workflow, a family office describing its portfolio structure, a casino walking through its operational reporting gaps: none of these are conversations for a team of twelve at a vendor who also serves their competitors. The fewer people who know, the better.

A single senior engineer who scopes and builds the engagement is also a single point of confidentiality. There is no junior analyst who overheard the kickoff call. No project coordinator whose notes are sitting on a shared drive.

Translation

Requirements degrade as they pass through people. By the time the developer gets the brief, it has been filtered and interpreted at least twice. What gets built often bears only a family resemblance to what was originally meant.

When the person asking the questions is the same person writing the code, there is no translation. There is direct understanding.

Accountability

In a distributed team model, accountability is diffuse. When something goes wrong - and it always does - the conversation involves multiple parties with different perspectives and different incentives. Resolution takes time. The client absorbs the cost of that time.

One point of contact means one point of accountability - one person to call when something goes wrong, who cannot point to anyone else.

What this requires

This model only works if that single person is genuinely senior. A junior developer working alone is not this model; it is just an under-resourced project. The value comes from the seniority and judgment applied to every decision: the architecture choices, the scope conversations, the moments when a requirement turns out to be more complex than it looked and someone has to decide what to do about it.

A note on internal collaboration

This is a constraint on how the client relationship is structured, not on how the work gets done. Bringing in a second engineer for a code review, consulting a specialist on a specific architectural question, getting another set of eyes before something ships: none of that breaks the model. What the client gets is still one accountable person who owns the engagement. What happens on the other side of that relationship is craft, and good craft often involves other people.

What would break the model is if those collaborators started interfacing directly with the client: taking requirements, making commitments, fielding questions. At that point you have rebuilt the same telephone-game structure the model is designed to avoid, just with fewer people in the chain.

Institutional clients deserve institutional-grade judgment applied directly to their problem by the person they are paying.

That is the only model we operate.