Fixed price or hourly: how to choose a software contract
A fixed price works when what you asked for is already decided and little will change. Hourly works when part of the request still has to be discovered. The contract decides who carries the uncertainty: under a fixed price it is the vendor, who builds it into the number. Under hourly billing it is you, who pays whatever the discovery costs.
Fixed price or hourly: which contract should you choose?
Choose by how settled the request is. If you can say what goes in, what comes out, who uses it and which systems and spreadsheets the new system touches, and almost none of that will change, a fixed price is coherent. If part of the request depends on finding out how the operation really works, for example a pricing rule that lives in one person's head, an hourly format, preferably with a cap, fits what you actually know.
There is a simple test. Ask: if I change my mind in week six, who pays? Under a fixed price, the change becomes an addendum and a negotiation. Under hourly billing, it becomes hours on next month's invoice. Neither format removes change. Each decides who absorbs it.
What does the research say about software development contracts?
That the format is a decision about risk and trust, and that no study names a winner. The three papers below predate 2025, but they are what the academic literature has in the way of direct measurement on this subject.
Patrick Bajari and Steven Tadelis published a model in 2001 in the RAND Journal of Economics in which the buyer trades incentives against renegotiation costs. They show that a cost-plus contract is preferable to a fixed price when the project is more complex. The logic is that in a complex project the design changes after signing, and renegotiating a fixed price has a cost of its own.
The most useful empirical data comes from Lior Fink, Yossi Lichtenstein and Simon Wyss, published in 2013 in Applied Economics. They analyzed 270 software development contracts signed between January 2000 and April 2003 by an international bank, with about 100 vendors. There were 139 standard fixed-price contracts (51%), 42 firm fixed-price (16%), 43 pure time and materials (16%), 14 time and materials with a not-to-exceed cap (5%) and 32 mixed (12%). The mixed contracts averaged $632,000, against $284,000 for standard fixed price. According to the authors, a higher price, which they use as a proxy for uncertainty, appears alongside less complete contracts.
This study measures contract type, not project outcome. It comes from a single bank. It serves to show that, even for a large buyer where two thirds of contracts were fixed price, 17% used mixed formats or time and materials with a cap, and the mixed ones cost on average more than twice the standard fixed price.
The third paper is by Yossi Lichtenstein and Alan McDonnell, presented in 2003 at the European Conference on Information Systems (ECIS). The hypothesis was that risky projects would be contracted hourly and the rest at a fixed price. Across 14 external projects at two large corporations, the data did not support it. In interviews with senior managers, one of the firms contracted risky projects at a fixed price and paid a risk premium to avoid rebudgeting. The other accepted a fixed price only with trusted vendors.
What follows from this: the criterion is not the format. It is who agrees to carry what, and with how much trust.
Why does a fixed price get expensive when the request is vague?
Because cost overruns in software are rare but enormous, and someone has to pay for them.
Bent Flyvbjerg and colleagues compared 23 project types in a study in volume 57 (2026) of the Project Management Journal, covering 11,011 projects. Of the 5,360 IT projects in the sample, 40.86% went over budget. In 18.26% the overrun exceeded 50%, and in those cases the average final cost was 5.53 times the estimate. The authors conclude that IT is the only type whose overrun tail is heavy enough to make the risk unpredictable, and they propose as explanations the bespoke nature of software and decisions made too fast. As remedies they suggest modularity and slower deciding.
The link to the contract is our reading, not a result of the study. A vendor who knows this tail tends to put a reserve into a fixed price when the request is vague, and you pay that reserve even if the project goes well. When the request is well described, the reserve shrinks, because what the vendor does not know shrinks. The cost of a fixed price, then, depends less on the negotiation and more on how much you managed to decide before asking.
That is why the problem is rarely the contract. You do not have a fixed-price-or-hourly problem. You have an architecture problem: the request does not yet know what it is.
How do you split the uncertainty instead of choosing a side?
By separating the request into two piles and giving each the contract that fits it.
The first pile holds the decided parts: screens, flows and rules that someone can describe and validate. These fit a fixed price, preferably broken into small modules with intermediate deliveries. In the study by Fink and colleagues, more intermediate deliverables appear alongside more complete contracts, which makes sense: each delivery is a date when both sides check what was agreed.
The second pile holds the parts still to be discovered: the rule only one employee knows, the integration with a system nobody documented. These fit a short discovery phase at a fixed price, whose deliverable is a document of rules and a map of integrations. What the discovery documents moves to the first pile. What remains uncertain after it goes hourly under a cap, and the cap is what keeps hourly billing from becoming a blank check.
One earlier step shrinks the second pile on its own. Running the process by hand for three weeks before signing turns part of the uncertainty into a record, and the record becomes a specification. The more the request resembles a specification, the fairer a fixed price is to both sides.
One thing is still missing: a written rule for scope changes. Who can ask, who approves, how the impact on schedule and cost is reported before execution. Without it, both formats produce the same argument, only at different moments.
What does this look like in a real operation?
Consider a hypothetical scenario: a mid-sized distributor wants an order portal to replace the sales team's spreadsheet and chat threads. Two things are decided: the customer registry and the order flow, from submission to approval. Two are not: the pricing rule per customer, which today lives in the head of the sales manager, and the integration with inventory control, kept in a spreadsheet.
A single fixed-price proposal forces the vendor to guess both uncertainties and price them. A clearer split would have three blocks. First, two to three weeks of discovery at a fixed price, delivering documented pricing rules and an integration map for inventory. Second, the registry and order module at a fixed price, already using what the discovery revealed. Third, the pricing rule and the integration: at a fixed price if the discovery managed to document them, or hourly with a cap and a review at each delivery if the inventory spreadsheet still holds rules nobody can describe.
The timelines above are illustration, not measurement. The point is the structure: the uncertainty shows up early, in a short and inexpensive block, instead of showing up in week eight inside a price that has already been paid.
Yowpi's cases show a close sequence, although they do not record the contract format used. Colo Saúde started with a bounded rescue, a security audit and a performance adjustment, which took security from 7/10 to 10/10 in Yowpi's own audit and cut Bubble processing-unit consumption (WUs) by 60%. The following projects came afterwards, once trust was established. UniTrust started with a system live in two weeks, in August 2022, and the platform evolved in sequence until it covered the agent's entire lifecycle. In both, the initial delivery was small and verifiable, and the expansion came after it.
Frequently asked questions
Do I need someone technical in the company to evaluate a software contract?
Not necessarily. The technical review of the code or architecture can be hired. What only you have is the answer to "what is decided and what is not." Ask the vendor, in writing, for the list of what they considered outside the price and what they assumed about the systems you already use. That list is more useful than any clause.
Doesn't a fixed price protect my cash better?
It protects cash, not necessarily the result. The amount is set, but what fits inside it depends on how well the request was described, and what was left out comes back as an addendum. Some buyers accept paying a risk premium for predictability, as the Lichtenstein and McDonnell interviews show. It is a legitimate choice, as long as it is made knowing what the premium covers.
What if the integration with what I already use turns out more complicated than expected?
It is the most common case of hidden uncertainty, so it deserves its own treatment. Do the discovery first, so the vendor sees the existing system before pricing, and leave hourly with a cap only for what it could not clarify. If the cap is exceeded, you find out early, in a small block, and decide with data.
The next step
If you have a proposal on the table and are not sure the format fits what is already decided, the Operational Architecture Diagnostic, a 30-minute conversation, helps separate what can be fixed now from what still has to be discovered, and you leave with that list: talk to an architect.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No proposal in the first conversation.
Book a diagnostic