Selling hours rewards activity. We prefer to price around the business result the software needs to produce.
That forces better scoping conversations. It also keeps accountability where it belongs: on the working outcome, not the timesheet.
This is not a philosophical position. It is a practical response to what agentic engineering does to the hourly model — which is break it.
The Hourly Model Has An Incentive Problem
Under an hourly contract, the vendor’s revenue is a function of elapsed effort.
Nobody sets out to exploit that. Most agencies are honest. But the incentive sits underneath every decision anyway, and it shows up in small ways: the refactor that could wait, the framework evaluation that runs two weeks, the meeting that includes six people because six people are billable.
The deeper problem is what hourly pricing does to the client’s behaviour. When you are paying by the hour, every conversation costs money. So clients batch their questions, avoid raising doubts, and stop asking “should we build this at all?” — because the answer might cost a discovery phase.
That is exactly backwards. The cheapest moment to change direction is before anything is built.
Agentic Delivery Makes It Worse
Here is the part that is specific to how we work.
If a senior engineer with an agent fleet delivers in three weeks what a conventional team delivers in three months, an hourly contract means we earn roughly a tenth as much for the same result. We would be financially punished for the efficiency we exist to provide.
The rational response to that incentive is to work slower. We would rather not be in a business where the rational response is to work slower.
Outcome pricing removes the conflict. The client buys a working system. How fast we get there is our problem, and our advantage.
flowchart LR
subgraph Hourly
A1[Faster delivery] --> A2[Less revenue]
A2 --> A3[Incentive to slow down]
end
subgraph Outcome
B1[Faster delivery] --> B2[Same revenue,<br/>earlier]
B2 --> B3[Incentive to invest<br/>in leverage]
endWhat We Actually Price
We price a defined outcome with a defined boundary. Concretely, a contract specifies:
- The system that will exist. Described in terms of what it does, for whom, and what it replaces.
- The acceptance criteria. What must be true for this to be finished — not “the code is written,” but observable behaviour a non-engineer can check.
- The operational baseline. What monitoring, alerting, and documentation ship with it. This is included by default, not a phase two.
- What is explicitly out of scope. Usually longer than the in-scope list, and more useful.
- The change mechanism. How scope moves, and what happens to price when it does.
That last one is where most fixed-price arrangements fail. Scope always moves. A contract that pretends otherwise turns into a dispute the first time reality intervenes.
Scoping Is The Hard Part, And That Is The Point
Outcome pricing forces a conversation that hourly billing lets both sides avoid.
To quote a number, we have to understand what success looks like. That means asking uncomfortable questions early:
- What decision does this system change?
- Who is the actual user, and what do they do today instead?
- What breaks in the business if this is late? If it is wrong?
- What must integrate with it, and who owns those systems?
- What does “done” mean to the person signing off?
Clients sometimes find this heavier than expected at the start. It is. The alternative is discovering the same questions in month three, having built the wrong thing at an hourly rate.
We do this scoping work before there is a contract, and we do not bill for it. If we cannot describe the outcome clearly enough to price it, we are not ready to build it — and telling you that is worth more than an invoice.
How We Handle Change
Scope changes. The mechanism matters more than the estimate.
We split changes into three categories:
- Clarification. We misunderstood something, or the spec was ambiguous. Absorbed by us at no cost. This is the largest bucket and it should be.
- Substitution. You want something different of comparable size. Swap it in, price unchanged.
- Addition. Genuinely new scope. Priced separately, agreed before work starts.
The distinction gets made in conversation, not by lawyers. It works because both parties can see the original acceptance criteria and reason about whether the request was inside them.
The Risks, Honestly
Outcome pricing moves delivery risk from the client to us. That is the deal, and it has real failure modes we manage deliberately.
Underscoping. If we misjudge, we absorb it. This has happened. The discipline is to price with a genuine buffer and to walk away from work we cannot scope confidently, rather than quoting optimistically and renegotiating later.
Gold-plating in reverse. A fixed price creates an incentive to do the minimum that passes acceptance. We counter this by putting the operational baseline — tests, observability, documentation — inside the fixed scope rather than treating it as optional. If it were an add-on, it would be the first thing cut.
Ambiguity about “done.” Handled entirely by writing acceptance criteria that a non-engineer can evaluate. If the criteria need an engineer to interpret, they are not criteria.
When Hourly Is The Right Answer
We are not dogmatic about this.
Some work genuinely cannot be scoped in advance, and pretending otherwise serves nobody:
- Open-ended research where the question itself is unclear.
- Incident response and forensic debugging.
- Early exploratory work where the goal is to learn, not to ship.
- Advisory retainers where the client wants access to judgment rather than a deliverable.
For these we use time-based arrangements without embarrassment. The test is simple: if we can describe what “finished” looks like, we can price it as an outcome. If we cannot, honesty requires a different structure.
What We Tell Clients Who Insist On Hourly
Some organisations cannot buy any other way. Procurement rules, existing vendor frameworks, budget categories that only accept rate cards.
We accommodate this. We will quote a rate. But we say plainly what changes:
You will now be paying for elapsed time on a delivery model designed to compress it. The efficiency still happens — it just accrues to your invoice rather than your timeline, and you lose the guarantee that the number at the end matches the number at the start.
Most clients, once that is stated directly, find a way to buy the outcome. The ones that cannot usually have a procurement problem worth solving for reasons far beyond us.
The Bottom Line
Hourly billing prices the input. Outcome pricing prices the result.
When delivery speed increases by an order of magnitude, pricing the input means charging less for delivering more — so the model has to change or the incentives go wrong.
Outcome pricing is harder to sell and harder to scope. It also puts the risk where the expertise is, forces the right conversation before code is written, and means the fastest path to a working system is the one that pays best.
That is the alignment we want. You should expect it from anyone claiming this kind of leverage.