Fixed Price vs Time and Materials: Which Contract Model Suits Your Development Project?
Fixed price, time and materials or capped T&M for a web or app build? How each model allocates risk, plus a clause checklist and a model-choice table.
Fixed price or time and materials: the short answer
Choose the model by how certain your scope is and how much you expect to learn during the build, then spend most of your effort on the clauses around it. A fixed price works when the scope is small, written down and unlikely to move. Time and materials works when you expect to change course, provided you own the backlog and watch spend closely. For most new web apps and mobile apps a hybrid is safer: a short paid discovery, then fixed-price phases or capped time and materials for the build. Whichever model you pick, the real protection comes from change control, payment tied to accepted work, a written Definition of Done and the right to stop at a break point without termination costs.
This guide is about who carries which risk and how the contract governs change, not about what the work should cost. For estimating, see how to estimate the cost of a custom web application. The advice applies to websites, web applications and mobile apps; points specific to apps have their own section.
Key takeaways
- A fixed price moves delivery risk to the supplier only for the scope you wrote down. Everything else becomes a change request.
- Time and materials keeps flexibility but leaves quality and budget risk with you unless you manage it actively.
- "Capped" means different things in different contracts. Write down what happens when the cap is reached.
- Pay against accepted deliverables, not against sprints completed or hours logged.
- Agree change control, acceptance and a Definition of Done before signing, whatever the model.
- Contract in phases so either side can stop at a break point without termination costs.
What each model allocates
The pricing model decides who absorbs the cost when the work takes longer or changes. It does not decide quality, ownership or how disputes are settled; those come from other clauses.
| Model | How it works | Delivery risk sits with | How change is handled | Supplier's incentive | Best fit |
|---|---|---|---|---|---|
| Fixed price, whole project | One price for a defined scope and timescale | Mostly the supplier, but only for the written scope | Every change is a priced change request | Finish the agreed scope efficiently; resist or price changes | Small, fully specified builds, such as a marketing site from approved designs |
| Fixed price per phase or sprint | A fixed price for each phase, release or sprint, agreed in turn | Shared; each side's exposure is roughly one phase | The backlog is re-prioritised between phases before the next one is priced | Deliver each phase well enough to win the next | New products where the first release is clear but later ones are not |
| Time and materials (T&M) | You pay for time at agreed rates | Mostly you, including the risk of poor quality | Flexible: you re-prioritise at any time | Sell time; productivity depends on your oversight | Discovery, technical spikes and work where scope genuinely moves |
| Capped T&M | T&M up to a ceiling | Depends on what the contract says happens at the cap | As T&M, within the cap | Finish within the cap, if overruns are at the supplier's cost | Builds with moderate uncertainty where you need a ceiling but not a frozen scope |
| Dedicated team or retainer | Fixed monthly capacity from named people | You, for what the capacity produces | You set priorities each cycle | Keep the team busy and the client satisfied | Ongoing product development after launch |
What government contracting guidance says
The most useful public source on this question is the UK government's Contracting for Agile guidance note, a companion to its Digital, Data and Technology (DDaT) Playbook, last updated on 20 June 2023. It is written for public-sector buyers, so treat it as a set of tested principles rather than rules for your own contract. The points that matter most for a private web or app build:
- Scope is the variable. Agile delivery constrains time and cost, and "the scope becomes the variable" (para 2.5). A contract that fixes scope, time and cost all at once works against the method.
- Fixed price is simple but rigid for uncertain work. Its main benefit is "its simplicity" (4.5). Projects with very limited information are less likely to achieve their outcomes under a rigid fixed price, and the note suggests managing that risk with fixed-price sprints contracted in phases (4.7).
- Time and materials can drive the wrong behaviours. It offers "a high-level of flexibility", but the buyer "bears the risk of poor quality" and T&M "does not incentivise the supplier to deliver as much as other pricing models" (4.19).
- Use T&M for discovery, then move on. The note sees T&M fitting best as initial discovery work, after which the parties move to a more structured model (4.20).
- Exit should be cheap. The commercial structure should support exit "without the authority incurring termination costs or the provider being saddled with stranded costs", so the worst case is roughly the cost of one sprint cycle (4.22).
- Pay for deliverables, not process. Buyers should "always avoid basing payment milestones on the delivery of the agile process itself", such as a number of completed sprints, and link payments to deliverables or code releases (4.24).
- Define quality. The contract should state a Definition of Ready, a Definition of Done and the level of defects acceptable after release (5.3).
- The buyer owns the backlog. The buyer "must retain ownership of the backlog", and the structure should not allow scope creep or let the supplier push all the difficult items to the end (6.4 and 6.5).
Worth noting
The DDaT Playbook (chapter 8) puts the principle in one sentence: "Where the scope of a project is certain, then fixed pricing may be appropriate and where there is increased uncertainty in scope, a variable approach may be more suitable to achieve best value for money."
Capped time and materials: write down what the cap means
"Capped" is one of the most misunderstood words in development contracts, because it is used for two arrangements that allocate risk in opposite directions.
- Which meaning applies, in plain words.
- What the cap covers: the whole project, a phase or a single release.
- A notification point before the cap, for example a written forecast once a set share of the budget is used. This is common practice, not a legal requirement; choose a level that leaves you time to decide.
- What "finished" means at the cap: the scope list, acceptance criteria and Definition of Done.
- Whether approved change requests raise the cap, and by how much.
| Meaning | What happens at the cap | Who carries the overrun |
|---|---|---|
| Hard cap | The supplier finishes the agreed work at its own cost | The supplier |
| Budget ceiling | Work stops, or continues only after you approve more budget | You |
Where the hard cap idea comes from
The hard-cap meaning is the one the UK government's former buying guidance for the Digital Outcomes and Specialists framework used: if the cap is reached before the work is finished, "the supplier has to complete the work at their own cost", and if the work finishes early you pay only for the time taken. The same guidance said a fixed price "works best when your requirements are well defined" and that under T&M "you own more of the risk". It was withdrawn on 31 December 2025, so read it as past government practice, not current rules.
In commercial contracts, "cap" is often used in the looser budget-ceiling sense. Neither is wrong. A hard cap only works when "the work" is defined well enough to know when it is finished, which brings back many of the scope arguments a fixed price has, and a supplier will usually price that risk into its rates or narrow the scope. A budget ceiling is easier to agree, but protects you only if you get early warning.
The clauses that matter more than the pricing model
Change control. Write down who may request a change, who may approve it, how its effect on time, cost and other features is assessed, and that no work starts until the change is approved in writing. Under a fixed price, this is how the price moves; under T&M, it is how you stop spend drifting. The day-to-day process, with a template and change log, is in how to control scope creep during delivery.
Milestones tied to accepted work. Link each payment to something you can test and accept: a release in a staging environment, a feature set that passes its acceptance criteria, or an app build ready for store submission. Avoid milestones such as "sprint 4 complete", "design phase started" or a share of hours used; they pay for activity, not results.
Acceptance and Definition of Done. Agree how long you have to test each delivery, what happens if you do not respond, and how defects are separated from changes. The user acceptance testing guide covers acceptance windows and sign-off. Then write a Definition of Done that means more than "it works on the developer's machine": code reviewed, tests passing, deployed to staging, documented, and meeting the non-functional requirements you set for speed, security and accessibility.
A scope baseline. Every model needs a dated, versioned description of what is being built. A requirements document with numbered requirements lets quotes, acceptance tests and change requests refer to the same items.
Exit and ownership. Contract in phases with break points, give either side the right to stop at a break point without termination costs, and make sure you own the code, designs and accounts as you pay, with repository access throughout. The software handover checklist lists what you should be able to walk away with.
Model-choice decision table
Three questions decide most cases: how certain is the scope, how much will you learn during the build, and how much time can you spend managing the supplier? T&M needs the most client involvement; a fixed price needs the most definition up front.
| Your situation | Better fit | Guard rails to add |
|---|---|---|
| Small, fully specified build (for example a marketing site from approved designs) | Fixed price | Signed-off designs and content list as the baseline; priced change requests; warranty period |
| New product or MVP where you will learn from users | Paid discovery, then fixed price per phase or capped T&M | You own the backlog; break points between phases; payment on accepted releases |
| Requirements unclear or integrations unknown | Discovery on T&M or a fixed fee | Defined discovery outputs that you own; no commitment to the build |
| Hard budget limit with some uncertainty | Capped T&M or fixed price per phase | Written meaning of the cap; early-warning point; rule for swapping scope |
| Little time to manage the project yourself | Fixed price per phase | Clear acceptance criteria; T&M needs oversight you cannot give |
| Ongoing improvement of a live product | Dedicated team or retainer | Named people; monthly priorities; reporting on what shipped |
| Taking over a stalled project from another supplier | Short T&M assessment, then re-plan | Code and access audit before any fixed commitment |
Contract-clause checklist for any model
Use this when reviewing a proposal or draft contract. Every item applies whether the price is fixed, capped or open.
- Scope baseline: the requirements document or backlog version and date that the price or estimate is based on.
- Assumptions and client dependencies: content, decisions, access and third-party accounts you must provide, and by when.
- Change control: who can request and who can approve, impact assessment, written approval before work starts, and how changes are priced.
- Cap or budget ceiling: which meaning applies, what it covers and the early-warning point.
- Payment milestones: tied to accepted deliverables or releases, not to sprints, phases started or hours used.
- Acceptance: a testing window for each delivery, what happens if you do not respond, and defects kept separate from change requests.
- Definition of Ready and Definition of Done: written down, including non-functional requirements.
- Backlog ownership: you set priorities; the supplier advises on sizing and sequence.
- Reporting: a regular report of work done, time or budget used against plan, and risks.
- Governance trigger: a meeting and an agreed remedy when delivery speed or quality falls below an agreed level.
- Team: named key people and how replacements are agreed.
- Break points and exit: the right to stop at the end of a phase without termination costs.
- IP and access: IP assigned on payment; repositories, hosting and app store accounts in your name from the start.
- Warranty: a defect-fixing period after acceptance, and what support costs afterwards.
- Third-party costs: who pays for hosting, licences, APIs and developer accounts.
- Disputes: escalation steps before formal dispute resolution.
Pro tip
Ask each shortlisted supplier to mark up this list against their standard terms. How they respond tells you as much as their price does.
App builds: risks to assign in writing
Mobile apps add events that neither side fully controls, which is where many fixed-price disputes start. Decide in the contract who carries each one.
- Store review. Apple and Google review every submission, and a rejection can mean rework. Say whether fixing a rejection caused by the agreed design is within the price, and who handles content or policy questions.
- Operating system and store requirement changes. New iOS and Android versions, and store rules such as Google Play's target API level requirements, can force updates during or after a build. Define them as changes or as maintenance.
- Third-party SDKs. Payment, analytics, maps and login SDKs change versions and terms. List the ones in scope.
- Devices and OS versions. The list of devices and OS versions to be tested is part of the scope baseline.
- Developer accounts. The Apple and Google developer accounts should be in your company's name, with the supplier added as team members.
What a fixed price does not protect you from
A fixed price is often chosen because it feels safe. It protects you from the supplier taking longer than estimated on the scope you described. It does not protect you from:
- Scope you did not write down, which becomes paid change.
- Quality you did not define. If performance, accessibility or test coverage are not in the contract, they can be cut to protect the supplier's margin.
- Slow decisions, late content or unavailable stakeholders on your side, which usually justify time extensions or extra charges.
- Building the wrong thing. A fixed scope delivered exactly is still wasted if users needed something else.
- Risk premiums. Suppliers price uncertainty into a fixed quote, so you may pay for risks that never happen.
Hypothetical example: a booking platform with web and mobile apps
Hypothetical example: a founder wants a booking web app plus iOS and Android apps. Two proposals arrive: a fixed price for "the full platform" based on a two-page brief, and open time and materials with no cap. Neither is safe. The founder instead pays for a four-week discovery with defined outputs: user flows, a numbered requirements list, an integration list and a release plan.
The build is then contracted in three fixed-price phases, each paid on acceptance of a release in staging, with a change budget held by the founder. The contract says store rejections caused by the agreed design are fixed within the phase price, while OS and store requirement changes after launch fall under a separate maintenance agreement. After phase one, user feedback moves two features out and one in. The swap goes through change control, and phase two is priced on the revised backlog.
When this advice does not fit
Public procurement and regulated sectors may impose their own pricing model and terms. The UK guidance quoted above is written for that context and refers to UK procurement rules.
Very small jobs of a few days rarely justify phased contracts and governance meetings. A clear quote, a short scope, a warranty and an out-of-scope list may be enough.
If nobody on your side can make product decisions every week, T&M and agile phasing will struggle. A well-specified fixed price may suit you better even if it includes a risk premium.
This is not legal advice. Termination rights, IP assignment and how variations are enforced depend on local law in India, the UAE, the UK, Australia, Singapore and elsewhere. Have a lawyer review the final contract.
Common mistakes
- Comparing a fixed-price quote with a T&M estimate as if they carried the same risk.
- Signing a fixed price on a brief with no out-of-scope list.
- Using the word "capped" without defining it.
- Paying on dates, sprints or hours rather than accepted work.
- Letting the supplier own the backlog and set priorities.
- Leaving repositories and app store accounts in the supplier's name until final payment.
- Having no break points, so the only way out is termination.
Sources
GOV.UK: Contracting for Agile guidance note (updated 20 June 2023); paragraph numbers as cited above.
GOV.UK: The Digital, Data and Technology Playbook, chapter 8, payment mechanism and pricing approach (updated 20 June 2023).
GOV.UK: How to pay for Digital Outcomes and Specialists services (withdrawn 31 December 2025; cited as historical practice).
Accessed 15 October 2026. Government guidance is written for public-sector buyers and may be revised. Take legal advice on your own contract.
Conclusion and next steps
The pricing model matters less than the governance around it. Pick fixed price, T&M or a hybrid based on how certain your scope is and how much you will learn, then make sure the contract has a versioned baseline, written change control, payment on accepted work, a Definition of Done, and break points with a clean exit. If you are still comparing suppliers, how to choose a web development company covers the checks to make before you reach the contract. For the build itself, see our web application development services.
Want a second opinion on a proposal or contract structure?
ZSpace Labs is a remote-first technology studio that works with clients globally on web applications and mobile apps. If useful, we can talk through your project and suggest a contract structure after a short discovery.
Common questions.
Only against one risk: the supplier taking longer than planned on the scope you wrote down. Unwritten scope becomes paid change, quality you did not define can be cut, and suppliers add a premium for uncertainty. A fixed price is safest when the scope is small, stable and fully specified.