Skip to content

Fixed price or hourly: choosing a software contract by stage

7 min read
Custom Software
Fixed price or hourly: choosing a software contract by stage

Key Takeaways

  • 1The right contract depends on how well the scope is known, not on how much you trust the supplier
  • 2Use a small fixed-price discovery first, because it turns an unknown scope into a written one
  • 3Fixed price fits work with a clear scope and acceptance test; time and materials fits work that will change as you learn
  • 4Split the project into stages and choose the contract per stage, with a decision point between them
  • 5Whatever the contract, agree on a budget ceiling, a regular report of progress and a clear way to stop

Sooner or later, every software project reaches the same question from procurement or finance: will this be a fixed price, or do we pay by the hour? Both sides have strong opinions. Buyers want certainty about cost. Suppliers want protection from scope that grows without limit.

The useful answer is that the choice is not about the supplier. It is about how much you know about the work at the moment you sign. This article gives a simple way to match the contract to the stage of the project, so that you are not forced to pick one model for the whole thing.

What each model really transfers

A fixed price moves the risk of the effort to the supplier. If the work takes longer than planned, the supplier carries the cost. In return, the scope must be written down well enough to price, and every change goes through a change request.

Time and materials (T&M) moves the risk of the effort to the buyer. You pay for the hours used, usually with a rate card and a regular report. In return, you keep the freedom to change direction without renegotiating.

Neither is cheaper by nature. A fixed price includes a margin for the supplier's risk, so it is often higher for vague work. T&M has no such margin, but it needs more attention from you. If you want the wider picture of what a custom build costs, see the real cost of custom software.

The deciding question: how well is the scope known?

Ask three questions about the piece of work you are about to contract:

  1. Can you describe the result so that two people would agree whether it is finished?
  2. Are the main unknowns (data, integrations, user behaviour) already explored?
  3. Is it unlikely that you will want to change the direction during the work?

If all three answers are yes, a fixed price works well. If one or more is no, a fixed price will either be padded with a large margin or will cause arguments later. In that case, T&M with a ceiling is the honest model, or you first buy the answers to the open questions.

Stage 1: discovery - small fixed price

Discovery is the work that converts "we need something like this" into a written scope, a rough architecture and an estimate. It is a good candidate for a small fixed price, because the output is a document, and the effort can be limited to a few weeks.

The fixed price here protects you from a long, open-ended analysis. It also means you can take the result to another supplier if you are not satisfied. For what a good discovery should deliver, see discovery that prevents expensive custom software mistakes and how to de-risk custom builds in discovery.

Stage 2: first build - fixed price if the scope is tight, otherwise T&M with a ceiling

After discovery you have a scope. Now check it against the three questions.

  • Clear, bounded first version: fix the price for a defined set of features, with an acceptance test for each. Keep the scope small, so the supplier does not need a big safety margin.
  • Parts still uncertain: split them out. Fix the price for the clear part, and run the uncertain part as T&M with a monthly ceiling and a review after each month.

Do not stretch a fixed price over a scope that you already know will move. Both sides will then spend their energy on change requests instead of on the software.

Stage 3: extension and improvement - T&M or a capacity agreement

After launch, the work is made of many small items: fixes, new features, adjustments after real use. This is hard to price in advance, and the priorities change every month.

Here T&M works best, either as hours on demand or as a monthly capacity with a fixed team. What you should insist on is a visible backlog and a monthly summary of what was done. For the costs to expect in this period, what to budget in years two to five gives a framework.

A worked example (illustrative numbers)

This example is calculated for illustration. It is not a client case.

Suppose a company plans an internal ordering tool and receives two offers.

  • Offer A, one fixed price for everything: 120,000 euros.
  • Offer B, by stage: discovery fixed at 8,000 euros; first build fixed at 70,000 euros for the clear features; a T&M ceiling of 30,000 euros for the uncertain integration; extension at an hourly rate after launch.

At first glance, Offer A is simpler, and it is 12,000 euros above the 108,000 euros ceiling of Offer B (8,000 + 70,000 + 30,000). The difference is not the main point, though. Suppose that during discovery the team finds out that the integration with the warehouse system is much simpler than expected, and only 12,000 euros of the T&M ceiling is used. Offer B then costs 90,000 euros. Under Offer A, the integration would have been priced with the original uncertainty built in.

The opposite may also happen: the integration needs 30,000 euros, the ceiling is reached, and you decide at the review point whether to continue. Under Offer A, the supplier would have asked for a change request at the same moment, but with less transparency about the reasons. The numbers are invented; the lesson is that staging gives you a decision point exactly where the uncertainty is.

Terms that matter in both models

Regardless of the model, check these points before you sign:

  • Acceptance: how will you decide that a delivery is done? Write the test, not only the feature name.
  • Ceiling and alerts: in T&M, a maximum budget per month and a promise to warn you at 75 percent.
  • Reporting: a short weekly or monthly summary of hours, progress and open risks.
  • Change handling: who may approve a change, how fast it is priced, and what happens to the schedule.
  • Exit: the right to stop after each stage, with the code, documents and access handed over. For a similar view of exit terms, see AI agent vendor contracts: SLA, liability and exit.

If you are also choosing who will do the work, what to expect when hiring a software consultancy covers that side. This article assumes you already have candidates and want to set the form of the agreement.

What to do next

Take the project you are planning and cut it into three or four stages. For each stage, answer the three questions about the scope, and write down the contract type that follows. Then ask your suppliers to quote that way. The way they react to staging, with clear acceptance and a ceiling, tells you a lot about how they will work after you sign.

Share this article

Interested in Custom Software & Systems?

Learn more about how we can help your organization with this service.

Explore Service

Need expert guidance?

Let's discuss how our experience can help solve your biggest challenges.