Fixed price vs hourly: how to pay for web and software work

Hourly: you carry the risk

On hourly billing, every surprise in the work costs you. If the scope was unclear or the build takes longer than expected, the clock keeps running and the bill grows. Hourly suits genuinely open-ended work where nobody can define the finish line in advance. It is a poor fit for anything that can be scoped.

Fixed price: the provider carries the risk

On a fixed price, the number is agreed before work starts and does not move, as long as the scope holds. The provider absorbs the overrun. This is the better model for well-defined work such as a website, a defined feature set or an audit, because it turns an open-ended cost into a known one.

The catch is scope. A fixed price is only fair if the scope is frozen in writing. Every unmanaged change reopens the risk, so new requests should go on a separate, priced list.

The structure that protects you

Whichever model is used, payments should be staged against visible progress rather than paid upfront.

• A deposit to begin, then payments at a working demo, then on delivery.
• Each payment tied to something you can actually see and use.
• A written scope, signed before the clock or the work starts.
• A separate change list for anything added later.

The question to ask any provider

Ask directly: if the project takes longer than you expect, who pays? The answer tells you which model you are really buying. A provider confident in their scoping will happily fix the price and stand behind it. One who will not is telling you the scope is not really under control.