Fixed price or hourly rate for an IT project: who pays when it runs over

Hourly billing has a reputation for fairness. You pay for the work that was done, nothing more, while a fixed price supposedly hides a safety margin you end up funding. That sounds reasonable until something takes longer than planned. Then the hourly model hands the risk of a bad estimate to the one person least able to judge it: the client.

Fixed price IT project or hourly rate: where the risk sits

Every IT project starts with an estimate. On a fixed price IT project the vendor stands behind it. If the work takes twice as long, that is their problem. With hourly billing you stand behind it, because every hour past the estimate shows up on your invoice.

So the question is who can judge the estimate better. It is the vendor. They have built similar integrations before, they know where things tend to break, and they decide how the work gets done. You only see the interim invoice.

There is also an incentive nobody likes to mention. Under hourly billing the vendor earns more whenever things slow down. That does not make anyone dishonest, but nobody gets rewarded for being quick either. A fixed price flips this. Every hour the vendor saves is theirs to keep, so they have every reason to build fast and skip the detours.

One example, billed two ways

Say a wholesaler wants order entry from customer emails automated. Orders arrive as email text or PDF attachments. An agent reads them, matches customer and items against the ERP, and creates a draft order for the sales office to approve.

Testing with real emails turns up three things nobody mentioned beforehand. One customer sends a combined order for four branches in a single email. Another uses its own item numbers instead of the wholesaler's. And the ERP test account returns different field names than the production system.

Billed by the hour, the wholesaler pays for all three. The combined order needs new logic, the foreign item numbers need a mapping table, and the mismatched field names cost debugging time even though the client did nothing wrong. Add the back and forth on top. The final figure becomes known when the invoice arrives.

At a fixed price the same situation plays out differently. The field names are a technical issue, so they belong to the vendor and the wholesaler never hears about them. If the foreign item numbers were on the list of exceptions agreed during scoping, they are already paid for. If they were not, they count as an extension, just like the combined order, and the wholesaler decides whether to add it before anyone builds it, with a price attached.

That is where the two models part ways. With hourly billing you learn about extra effort after the fact. With a fixed price you decide in advance whether you want it.

What a fixed price needs to hold

A fixed price is only as good as the description behind it. If the quote just says "automation of order entry", the vendor has two options: pad the price heavily or argue about every detail later. You pay for either one.

A fixed price holds when it comes with a list of the cases it covers, down to the exceptions. Acceptance should be measured on real transactions from your business rather than a demo with hand-picked examples. And the quote should state what keeps costing money after handover. You can check all of this without reading a line of code.

A side effect worth having: to offer a fixed price at all, a vendor has to understand your process first. The questions about edge cases they need to ask are useful to you even if you never sign.

Short builds shrink the risk

The longer a project runs, the further the estimate drifts. That holds for both models. An agent that is set up in one to two days and tested on real cases the same week leaves little room for surprises. Larger undertakings can be split into sections, each running within days and each with its own price. The risk per section stays small, and the fixed price does not need a fat margin.

Even when it is still unclear what should be built, for instance whether a legacy system will release its data at all, you do not need a block of hourly work. Questions like that belong in the selection step, before anyone names a price. After that the cases are on the table and the fixed price rests on solid ground.

Our recommendation

Ask for a fixed price for building an automation, and make sure it comes with a list of covered cases. A vendor who cannot provide that has not understood your process yet. One who will not provide it does not want to carry the estimation risk, which means you carry it instead.

Sophera Consulting works exclusively at a fixed price, with no hourly billing and no subscription, in three steps: selection, quote, pilot. During selection we work out which process makes a good starting point and which system access we need; the quote that follows includes a cost-benefit analysis. A maintenance agent that monitors operations and watches every interface for changes is included in the price. The only running costs are the usage fees for the AI models, billed directly to you. The starting point is our free automation check.