I called more than ten electrical companies, but none could answer a basic question about the job.

The fusebox behind my stove had failed. Every company could schedule an appointment, but the person answering the phone was never the electrician doing the work. The answer was always some version of: “Book a time and someone will come assess it when they arrive.”

Eventually, I reached a small operation where the electrician answered the phone himself. He asked for photos, diagnosed the likely problem, and quoted the work before arriving. When he showed up, he confirmed what he had already understood and fixed it quickly.

The advantage was not merely that his business was small. It was that context and accountability stayed in the same place.

We have all experienced some version of this. A plumber, mechanic, contractor, or developer who understands the situation, owns the work, and stands behind the result feels fundamentally different from a process designed to distribute responsibility.

You already know which person you would rather have on the phone.

I want the people who hire UpHill Solutions to have that same experience. Unfortunately, that is not always how software consulting works.

The fifth developer

Before founding UpHill Solutions, I worked at a consulting agency where clients rarely spoke directly with the person writing their software.

Information moved through sales, founders, managers, and whichever developer happened to have room on their plate. Managers often acted as intermediaries, relaying technical decisions they did not fully understand in either direction and losing something in translation each time.

For one client, a developer learned the product and the business, then left. Another inherited the code without the context behind it. The client paid while that understanding was rebuilt, only for the cycle to repeat.

By the time I joined, I was the fifth developer.

The client had spent years paying different people to relearn the same system. Every handoff preserved the code but discarded part of the understanding required to work on it safely.

The relationship had deteriorated enough that the manager eventually stopped joining our calls. It was just me and the client.

Context is part of the system

Software is more than the code stored in a repository.

It includes the reason a workflow exists, the exception created for one customer three years ago, the vendor limitation nobody documented, the report that must run before payroll, and the workaround employees rely on without realizing it is a workaround.

That knowledge accumulates through conversations, incidents, revisions, and ordinary use.

The longer an engineer works with a business, the more accurately they can distinguish a local defect from a symptom of a larger problem. They learn which parts of the system are fragile, which apparent inconsistencies are deliberate, and which requests reveal a deeper operational issue.

A handoff does not merely transfer work. It interrupts that accumulation.

It is like asking a new contractor to finish a partially built house with the plans but none of the conversations behind them. They can see where the walls were placed, but not why one was moved, which compromise concealed a structural constraint, or what the owner intends to change later.

The incoming developer faces the same problem. They may receive the source code, tickets, and documentation, but they do not inherit every decision that shaped the system. The client pays for that missing context through repeated explanations, longer investigations, cautious changes, and mistakes that someone familiar with the history would have avoided.

The handoff tax

The fifth developer was not an isolated failure. It was the predictable result of a model built around interchangeable capacity.

From the agency’s perspective, a developer leaving creates a staffing problem. Assign someone else and the position is filled.

From the client’s perspective, the same event creates a knowledge problem.

The replacement developer must reconstruct how the business operates, why previous decisions were made, which assumptions the system depends on, and which parts are dangerous to change.

That work is rarely listed as a separate charge. It appears as slower delivery, repeated meetings, regressions, conservative estimates, and projects that seem to take longer each time they change hands.

The client does not merely pay for the replacement developer.

They pay the handoff tax.

None of this is necessarily the fault of an individual developer. It is what happens when a business treats developers as interchangeable parts: remove one, insert another, and expect the surrounding system to continue unchanged.

But developers are not interchangeable once they have accumulated years of context about a client’s business.

The role may be replaceable but the understanding is not.

Small by design

A client of mine put it well:

“A good developer is hard to find, but a developer who actually understands how you think well enough to finish your sentences? That’s even rarer.”

That kind of understanding is not created by adding more developers to a bench. It is the product of continuity, and continuity requires limits.

The more engagements a person or team accepts, the harder it becomes to retain the context that makes long-term work valuable. Eventually, clients compete for attention, communication passes through intermediaries, and the person making commitments drifts away from the person responsible for fulfilling them.

Staying small does not mean every project requires only one developer. Some work needs additional specialists or a larger delivery team. The constraint is that growth cannot come at the expense of clear ownership, direct communication, or retained context.

I would rather accept fewer engagements and understand them deeply than maximize the amount of development capacity I can sell.

I am not selling access to a bench of interchangeable developers.

I am selling continuity.

The confidence that the people responsible for the work understand why the system exists, remain accountable for their decisions, and still know its history when the next change arrives.

Most small and mid-sized businesses do not need twenty developers. They need someone who understands how the business operates, knows where the edge cases are buried, and recognizes when a small request is connected to something larger.

Software rarely stays finished. A vendor changes an API. A workflow evolves. Someone new joins the company. An employee discovers an exception nobody anticipated.

What appears to be a new project is often another chapter in the life of the same system. When the people responsible for it already understand the business, those changes begin with context instead of rediscovery.

That is why UpHill Solutions stays intentionally small.

Not because smallness is inherently virtuous, but because ownership, continuity, and accumulated understanding are the parts of consulting I refuse to scale away.

Back to Insights