Paying for hours vs. paying for results in engineering work

Paying for hours vs. paying for results in engineering work

Paying for hours means buying an engineer's time and keeping the risk of what that time produces. Paying for results means tying part of the fee to a number both sides agreed on, so whoever does the work carries part of that risk with you. Fixed price sits in between: the scope is bought up front, and the risk moves to whoever estimated it. Every engineering budget uses one of these three, usually without naming which one, and the choice decides who pays when the work takes longer or delivers less than expected.

Most budget conversations start and end with the hourly rate, because it is the number on the proposal. It is also the least informative number in the deal. The real cost of engineering work lives in what the rate doesn't show: the weeks before someone is productive, the code that gets rewritten, the review time, the role that sits open. This article walks through those costs, compares where each pricing model puts the risk, and covers what has to be true before part of a fee can be tied to results. The argument is simple: the cheapest rate is rarely the cheapest way to buy engineering, and paying for results only helps when the result can be measured honestly.

What an hourly rate leaves out

An hourly rate prices an engineer's time, not the output of that time. Two engineers at the same rate can cost a company very different amounts, depending on how long they take to become productive, how much of their work survives review, and how much of someone else's time they consume along the way.

The scale of the gap is easy to underestimate. The Consortium for Information & Software Quality estimated that the cost of poor software quality in the US had grown to at least $2.41 trillion in 2022. Little of that shows up on a rate card. It shows up later, as rework, incidents and features that ship late because the codebase resists change.

For a buyer, the practical consequence is that comparing rates compares the wrong thing. The useful comparison is the total cost of getting a piece of work done and keeping it working.

The hidden costs of paying for hours

Paying for hours puts every one of these costs on the buyer's side of the table. None of them is a reason to avoid hourly work. All of them belong in the budget.

• Ramp-up. A new engineer spends the first weeks learning the systems, the domain and the unwritten rules. That time is billed at the full rate and delivers little that ships.
• Rework. Code that passes a demo and fails in production gets written twice. With AI coding assistants in the toolchain, teams can produce more code faster, which also means more code that someone has to review and, sometimes, rewrite.
• Review and coordination. Every hour of new work consumes some hours of a senior engineer's attention: reviews, questions, decisions. That time rarely appears in the cost of the engineer who generated it.
• Idle time and context switching. Waiting on access, on a decision, on another team. Under hourly pricing, the clock keeps running.
• The open seat. Before any of this, there is the time the role sat empty. The cost of slow engineering hiring is a line most budgets never track.

Hourly pricing is still the right model for a lot of work, especially when the scope is uncertain and the buyer wants to direct it day by day. The point is to compare it on total cost, not on rate.

Hourly, fixed price or results: where the risk sits

Each pricing model answers the same question differently: who pays when the work takes more effort than expected?

• Hourly (time and materials). The buyer pays for the effort, whatever it turns out to be. Flexible, easy to start, and the buyer carries the risk of overruns.
• Fixed price. The buyer pays for a defined scope. The provider carries the risk of a bad estimate, so it gets priced in, and every change to the scope becomes a negotiation.
• Results-based. Part of the fee depends on an agreed outcome. The risk is shared, and the hard work moves from estimating effort to defining and measuring the result.

The comparison between the first two, applied to engineering, is covered in depth in time and materials vs. fixed price. This article focuses on the third, because it is the one most teams have never tried and the one most often sold without the fine print.

What changes when part of the fee is tied to results

Tying part of the fee to results changes who worries about the cost of the hidden work. When a share of the payment depends on an outcome, ramp-up, rework and idle time stop being only the buyer's problem.

DevelopersLATAM describes this route on its home page as outcome-based engagement, the third of its three ways in: "You pay less up front. The rest is tied to the numbers we agreed, measured at the end of the period — so we carry part of the risk with you." The same page draws a line that matters for buyers: "The engineers and the employment model are the same in all three. What changes is how you buy, and how the risk is shared…"

That line is the difference between results-based pricing for people and results-based pricing for a product or a platform. The engineers still join your team, and your team still directs the work. What changes is the commercial arrangement around them.

Results-based pricing is not a fit for everything. Exploratory work, research and one-off problems are hard to tie to a number agreed in advance. It works best where the work repeats and the outcome can be counted, which is also where AI-augmented teams tend to get smaller over time.

What results-based pricing does not mean

Results-based pricing is easy to oversell, so it helps to be clear about its limits.

• It is not a guarantee. Part of the fee depends on the result. The work, the risk of a bad month and the decisions about the product still exist, and someone still has to make them.
• It does not hand over control. When the engineers are part of your team, your engineering leaders still decide what gets built and how. The payment model changes; the direction of the work doesn't.
• It is not cheaper by definition. Depending on how the agreement is written, paying less up front and tying the rest to a number can end up costing about the same as paying for hours, or more, when the result is reached. The difference is what the money pays for: the outcome, not the hours.
• It does not replace a baseline. Without knowing where a number starts, there is no way to know whether it moved.

How to measure results without gaming them

Measuring results is the part that decides whether results-based pricing helps or hurts. Any number that pays someone gets optimized, and a badly chosen number gets optimized at the expense of everything it doesn't capture. Lines of code, tickets closed and story points are all easy to inflate.

Better measures share three traits: they are close to what the business actually needs, they are hard to move without doing the real work, and they are read together rather than one at a time. For delivery itself, the DORA software delivery metrics are a widely used reference: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Speed is balanced against stability, so pushing one at the expense of the other shows up.

Before any number goes into an agreement, settle four things:

• What exactly is measured, and what the starting point is today.
• Who measures it, and from which system, so nobody argues about the data at the end.
• Over what period, long enough for the result to be real and short enough to matter.
• What happens if the number isn't reached, and what happens if it changes for reasons nobody controls.

Teams that already run remote agile development well have an advantage here: their definition of done and their delivery data are already written down.

Frequently asked questions

What are the disadvantages of fixed-price contracts?

The main disadvantage of a fixed-price contract is rigidity. The provider prices the risk of a bad estimate into the fee, so the buyer often pays for that cushion whether or not it is needed. Every change to the scope becomes a negotiation, which gets expensive in engineering work, where requirements tend to shift once the build starts.

What is the difference between a fixed-price and a cost-plus contract?

A fixed-price contract pays an agreed amount for a defined scope, while a cost-plus contract reimburses the actual costs plus an agreed fee. Under fixed price, the provider absorbs any overrun. Under cost-plus, the buyer does, in exchange for flexibility. Hourly engineering work behaves much like cost-plus: the buyer pays for the effort, whatever it turns out to be.

Which contract type is the riskiest for the contractor?

Fixed price is usually the riskiest contract type for the contractor, because the fee stays the same when the work takes more effort than estimated. Hourly work sits at the other end, with the buyer carrying the overruns. Results-based pricing falls in between: the risk is shared through the part of the fee tied to the agreed outcome.

‍

Before you choose how to pay: three questions

1. Can you describe the result in a number your team already tracks? If not, start with hourly or fixed price and build the baseline first.
2. Does the work repeat? Results-based pricing rewards work that compounds. One-off work is usually better bought by the hour or by the scope.
3. Who on your side owns the measurement? Someone has to, and it should be decided before the engagement starts, not at the end of the period.

How you pay is one decision; how you fill the role is another, and the ways to fill an engineering position are worth comparing first. If the answers point toward tying part of the fee to results, talk to the team about how that would work for the role you need to fill.

‍