When you commission software, you will be asked, sooner or later, how you want to pay for it. The two classic answers are a fixed price for the whole project, or payment for time and materials as the work happens. Each is sold as the safe option. Each can go badly wrong when used for the wrong kind of project. I have worked under both for many years, from both sides of the table, and the right choice is almost always obvious once you ask the right questions.

What each model actually is

Fixed price means the supplier agrees to deliver a defined scope for an agreed sum. The risk of the work taking longer than expected sits with the supplier. In exchange, the supplier needs the scope to be defined, and will resist changes to it.

Time and materials means you pay for the effort actually spent, usually by the hour, day or month, plus any direct costs such as third-party licences. The risk of the work taking longer sits with you. In exchange you get flexibility: you can change direction, add features and drop the ones that turn out not to matter.

A third arrangement, the dedicated developer or monthly engagement, is a close cousin of time and materials: you reserve a set amount of a developer’s time each month and direct how it is used. We cover it on our dedicated developer page.

The fixed-price promise, and where it breaks

A fixed price feels comforting because it gives you a number to put in a budget. That comfort is real when the following are true:

  • The requirements are clear, written down and unlikely to change.
  • The technology is familiar and the risks are low.
  • You can describe, in advance, how you will decide that the work is finished.

Under those conditions a fixed price is efficient. Everyone knows what is being built and what it costs.

The trouble starts when those conditions are not met, which is common. Imagine a project whose requirements are fuzzy. A supplier asked for a fixed price has two honest options. They can add a generous margin to cover the unknowns, in which case you pay for risk that may never materialise. Or they can quote tightly and then protect themselves by interpreting every ambiguity in the narrowest possible way. Both lead to friction. You end up arguing about whether something is “in scope” when you should be talking about whether it is useful.

There is a quieter problem too. When a supplier is bearing the risk, there is a natural incentive to cut corners that you cannot easily see: less testing, thinner documentation, quicker and less maintainable solutions. Good suppliers do not do this, but the structure of the contract makes it tempting, and it is worth knowing.

The time-and-materials promise, and where it breaks

Time and materials is honest about the nature of software: the best understanding of the problem arrives while building. It lets you start sooner, learn from real use and adjust. It tends to produce better products when the idea is still forming.

Its risk is the opposite one. Without discipline, the budget has no ceiling and the project has no natural end. You need to trust the supplier to work efficiently and tell you the truth about progress. You also need to do your part by prioritising, because every feature you add costs more.

You can reduce that risk considerably with simple habits:

  • Agree an estimated range at the start and treat it as a planning figure, not a promise.
  • Work in short milestones with something you can see and test at the end of each.
  • Ask for regular reports of time spent against each piece of work.
  • Set a review point at which you decide to continue, change direction or stop.
  • Keep a prioritised backlog, so the most valuable work is always done first.

A simple way to choose

Ask yourself these questions about your project.

How well can I describe the finished product today? If you could hand a written specification to three suppliers and expect similar results, a fixed price is reasonable. If you could not, it is not.

How likely is it that I will change my mind? Be honest. Most people learn something once they see working software. If you expect to adjust the plan, time and materials will fit better.

How new is the technology or the problem? Unfamiliar territory, such as a new integration or an AI feature, carries unknowns that are better shared than hidden in a price.

How big is the piece of work? Small, well-bounded tasks, such as a particular report, a simple integration or a defined fix, suit fixed price. Large, long programmes are better divided into stages, each with its own agreement.

How much do I value budget certainty over flexibility? Some organisations have procurement rules that require a fixed figure. That is a legitimate constraint, and there are ways to meet it, described below.

The hybrids that usually work best

In practice, the best arrangement is often a mixture.

Paid discovery, then fixed price. Spend a short, paid phase (a week or two) producing a written scope, a prototype or a technical spike that tests the riskiest part. Then fix the price for the build against that scope. You buy certainty with a small, time-boxed investment.

Fixed price per milestone. Divide the project into stages, each with a clear deliverable and a fixed price, and agree each stage after finishing the previous one. You get predictability in small steps and the freedom to adjust between them.

Time and materials with a cap. Work on time and materials, but agree a maximum that cannot be exceeded without your approval. The supplier is protected from open-ended scope; you are protected from open-ended cost.

Monthly engagement. For ongoing products with a steady stream of changes, a fixed monthly amount for an agreed amount of developer time is simple to budget and simple to run.

Changes and how contracts handle them

No matter which model you choose, the project will change. The contract should say how. Under a fixed price, there should be a written change request process: describe the change, estimate its effect, approve it, then proceed. Under time and materials, changes happen through reprioritising, and the only question is whether the total still fits your budget. If a contract is silent on change, expect disagreements.

Other things worth writing down

Whatever the pricing model, make sure the agreement covers a few essentials:

  • Ownership. You should own the code and the intellectual property once the work is paid for, and the code should live in a repository you control.
  • Acceptance. How will you decide a deliverable is done? Tests, a demo, a checklist?
  • Confidentiality. An NDA, if your information is sensitive.
  • Warranty and support. What happens when a bug appears the week after launch?
  • Ending the relationship. How either side can stop, and what you receive if they do.

What I recommend

If you can describe your project clearly, ask for a fixed price and expect a good supplier to give it, with a clear scope and a change process. If you cannot, do not force the issue. Begin with a short, paid discovery phase or a time-and-materials stage with a cap, and move to fixed prices for the pieces that become well defined.

At IT-Labs we offer all of these, and we recommend the model after a free initial consultation, because the right choice depends on your project and not on what suits our invoicing. Each engagement starts with a written estimate. If you are working out what to ask for, our article on what drives the cost of custom software is a helpful companion, and you can read more about how we run projects on our how we work page. When you are ready, tell us about your project.