Fixed price or time and materials: which suits you?

A fixed-price contract suits you when you can describe what you want clearly enough to write it down and test it. Time and materials suits you when the work cannot be described yet, or when you expect to change direction as you learn. For most business owners buying software, the safest route is a hybrid: a short fixed-price discovery phase, then the build in fixed-price phases.

Last checked: 6 November 2026

The choice is not really about which model is cheaper. It is about who carries the cost when the work turns out bigger than expected, and how much control you keep over what gets built.

How each model splits the risk

Under a fixed price, you and the developer agree a scope, a price and usually a timeline. If the work takes longer than estimated, the developer absorbs the cost. If you want something that was not in the scope, you pay for it separately.

Under time and materials (T&M), you pay for the hours or days actually worked at an agreed rate, plus direct costs such as paid services or licences. If the work takes longer, you pay more. If you change your mind, the team simply moves to the new priority.

Neither column is free of risk. A developer quoting a fixed price includes a margin for the unknowns, so a well-run T&M project can cost less. A T&M project with no limit and no reporting can cost far more.

What a fixed price actually fixes

A fixed price fixes the price of a written scope, not the price of whatever you had in mind. That gap is the most common source of disputes. If the scope says "an admin dashboard", you and the developer may picture very different things.

Before you accept a fixed quote, check that the scope document names:

• Every screen or page, and who uses it.
• What each user can do, written as actions: create an invoice, approve a refund, export a report.
• The integrations, such as a payment gateway, an SMS provider or an accounting system.
• What is explicitly not included.
• How the work will be accepted: who tests it, on which devices, and for how long.

If the developer cannot or will not write this down, the price is not really fixed. A clear project brief from your side makes this step much faster, and our contract checklist covers the clauses to read before you sign.

How change requests work

Every real project changes. You see the first screens and realise the sales team needs a filter, or a new branch opens halfway through. A change request is how a fixed-price contract absorbs that without arguments.

A sound process looks like this:

1. You describe the change in writing.
2. The developer replies with its effect on price and timeline, also in writing.
3. You approve or decline it before any work starts.
4. The approved change is added to the scope and tested like everything else.

Watch for two opposite problems: a developer who agrees to "small changes" verbally and bills for them later, and a developer who treats every clarification as a paid change. The contract should say what counts as a bug fix (free, because it was in the scope) and what counts as new work (paid).

Under T&M, change requests are lighter because you are already paying for time. You still need a written list of priorities, so you know what the hours were spent on.

Milestone payments: pay for what you can test

Whichever model you choose, tie payments to things you can see working. A common fixed-price schedule is a deposit at signing, then a payment each time an agreed milestone is delivered and accepted, with the last payment after launch.

Each milestone should have three parts: a deliverable you can use (not "50% of development"), a short acceptance test, and the payment that follows it. Avoid schedules where most of the money is paid before you have seen anything run.

Under T&M, the equivalent is regular invoicing with a timesheet and a short report of what was done. Ask for a monthly cap: the team stops and asks you before going over it. That one clause removes most of the risk of an open-ended bill.

When time and materials protects you

T&M is not just the developer's preferred option. In some situations it protects the buyer:

• The idea is still taking shape. If you are testing a new product, a fixed scope locks you into decisions you would make better in a month.
• The work is ongoing. Maintenance, small improvements and support rarely fit a fixed scope.
• The unknowns are technical. Connecting to an old system with no documentation can take a day or a month. A fixed price for that will either be padded or fought over.
• You want to steer week by week. With T&M you decide what the team works on next.

The Agile Manifesto, written by a group of software developers in 2001, values "customer collaboration over contract negotiation" and "responding to change over following a plan". T&M is the contract model that fits that way of working. It only works if you have time to take part: review the work, answer questions and set priorities.

The hybrid: fixed-price discovery, then fixed-price phases

For most business systems, a two-step approach gives you the strengths of both models.

Step 1: a short, fixed-price discovery phase. The developer studies how your business works, maps the users and processes, and produces a written scope, screen sketches and an estimate. You pay a fixed amount for this, and you own the result. The UK government's service manual describes the same idea for public services: understand the problem first, and do not start building in discovery. It also says that stopping after discovery is not a failure if the research shows the project should not go ahead.

Step 2: the build, in fixed-price phases. Instead of one large fixed price, the scope is split into phases, each with its own price and milestones. Phase 1 is the smallest version that does useful work. Later phases are priced once phase 1 is in use and everyone knows much more.

You get a known budget for each step and a natural point to stop or change direction. Because the scope came out of discovery, it is detailed enough to hold to. To see what drives the numbers in each phase, read what a web app actually costs to build. When the last phase is delivered, use a handover checklist to make sure you receive the code, the accounts and the documentation.

How KF Tech Solutions works

We build custom software, websites, and web and mobile apps, and we work with businesses in Egypt and the Gulf. Every project starts with a free call to understand what you need, followed by a written quote with a fixed price for the agreed scope. Projects start from $200 (about SAR 750 / AED 735); the final price depends on scope, with a fixed written quote after a free call.

Common questions

Is fixed price always more expensive than time and materials?

Not always. A fixed quote includes a margin for risk, so well-run T&M work can cost less. But T&M has no ceiling unless you add one, and a fixed price protects you if the developer underestimated. For a clearly defined system, a fixed price is usually the easier budget to manage.

What happens if a fixed-price project runs late?

That depends on your contract. Many contracts tie the final payment to acceptance, which gives the developer a reason to finish. Some add a delay clause. Check what yours says before signing, and make sure delays caused by late feedback from your side are treated separately.

Can I switch from time and materials to fixed price later?

Yes, and it is common. Many projects start on T&M or with a paid discovery, then move to fixed-price phases once the scope is clear enough to write down.

Who owns the work from a paid discovery phase?

It should be you. Make sure the contract says the written scope, sketches and estimates belong to you, so you can take them to another developer if you choose.

How big should the deposit be?

There is no standard figure. What matters is that the deposit covers the start of the work, not most of the project, and that the remaining payments follow milestones you can test.

Not sure which model fits your project? Book a free call and describe what you need, or send us a message. We will tell you whether the scope is clear enough for a fixed quote, and what is missing if it is not.

Sources

• Manifesto for Agile Software Development
• How the discovery phase works, GOV.UK Service Manual