The most expensive part of your build is the decision nobody makes

A founder asks us whether paying twice as much means the product arrives twice as fast.

It does not, and we say so plainly. Anyone who promises that is selling something.

But the question points at the wrong number. The rate is the smallest variable in what a product ends up costing. The largest one appears on no invoice at all: the time a decision spends unmade.

The bill nobody itemises

Engineering is rarely the bottleneck. A team reaches a question only the business can answer, asks it, and waits.

Three days pass. The developers move to something else, because sitting idle is worse. When the answer arrives, the context has gone cold, half the surrounding work has been built on an assumption that turns out to be wrong, and some of it is redone.

None of this is logged anywhere. No one files a ticket for the four days a question sat in a group chat. It surfaces later as the product being late, and the conversation that follows is about velocity, or about the team, when it was never about either.

We see this most often where several people share responsibility and everyone is acting in good faith. Each of them is doing what seems right with the knowledge they have. The work still moves slowly, because nobody in the group is positioned to end the discussion.

What we are building is your half

The split we hold to is simple. The business input belongs to the founder's side: what we are building, what the business actually needs, in what order. The technical judgment belongs to us: how it gets built, what it runs on, what to refactor and when.

When those two blur, the failure is specific and predictable. The business questions go unanswered while the group debates implementation details it is not equipped to settle, and the team stalls waiting on the answers only that group can give.

The business half is the harder one. It requires knowing your market well enough to say what matters and in what sequence, and being willing to commit to that in writing while the work is still cheap to change. The technical half is ours to carry, and we would rather carry it than have it distributed across a committee. That division is most of what the role actually replaces.

Someone has to be able to end the discussion

The practical fix is to name one person on the business side who can settle open questions.

It genuinely does not matter who. What matters is that the team knows the name, and that the person understands the job is to close questions rather than to have the best opinion in the room.

Without that, a group of capable people can circle the same question for weeks, each waiting for a consensus that has no mechanism to form. The friction is not inside any one person's work. It lives in the gap between them, which is where the expensive problems usually hide.

Values are what you hold people to when the work is ambiguous

Most real work is ambiguous. A specification never covers every case, and the interesting decisions are the ones nobody wrote down in advance.

So the first thing we agree with a founder building something serious is not a process or a tool. It is the mission, and a short set of values the team is held to. That sounds soft, and it is the most practical thing we know. Values are what people navigate by when the instructions run out.

Without them, the only instrument left is supervision. And close supervision produces exactly what nobody wants: people who stop taking ownership and start waiting to be told, because ownership without authority is just exposure. No one sets out to build a team like that. It is what fills the gap when there is nothing else to hold on to.

The best teams we have worked in were not closely managed. People knew what they were building, what they would not compromise on, and who decided what. Then they were trusted to do the work. The same principle holds inside our own company, where written rules do the work managers usually do.

Judge the work, not the noise around it

Results are the only honest measure, and that cuts toward us first. If what we are doing is not producing value, we want to hear it early and directly, from the person who thinks so rather than relayed through someone else.

The useful form of that criticism names the specific gap. "This requirement is not reflected in the build" is something we can act on the same day. "I am not sure they understand the business" leaves everyone guessing at what to fix, and usually produces another meeting rather than a change.

Naming the gap is the whole job. It closes in one exchange.

The strongest engagements are the ones either side could leave

We hand over the organisation, the code, and its full history. The documentation is written so that a team who has never met us could pick the product up.

That is deliberate, and it costs us something. It means nobody stays with us because leaving would be painful. They stay because the work is good, which is the only durable reason anyone should.

It also changes what a founder is deciding. When the exit is safe, committing further is a judgment about the work rather than a calculation about how much would be lost. Those are much better conversations to have, and they are the reason we would rather set a review point early, while neither side needs one, than discover we disagree about how to work together a year in.

The rate comparison that started all this has an answer, and it is not about rates. What a feature costs you is the engineering, plus the rework, plus every hour you and your team spend supervising it, divided by whether it ends up being the right feature at all. Run that calculation and the hourly number stops being the interesting part.