When a business decides to commission custom software, one of the first commercial questions is how to structure the contract. The two classic models are fixed price — an agreed scope for an agreed price — and time and materials (T&M) — paying for the actual effort spent. Many business owners instinctively prefer fixed price because it seems to cap their risk. Development companies often prefer time and materials because software estimates are uncertain. Both views contain truth, and both can lead to bad outcomes when applied to the wrong project.
This guide explains how each model really works, where the risk sits, what happens when things change, and how to choose — or combine — models for your project. It does not discuss specific prices; the aim is to help you structure the agreement so that both sides are motivated to deliver the right software.
Why software is hard to price
Building a house is often used as an analogy for building software. It is a misleading one. A house is built from detailed drawings using well-known materials and methods; the main uncertainty is execution. Custom business software is closer to designing and building a new kind of machine for a specific factory: the requirements are discovered as you go, users change their minds when they see the first version, edge cases appear only with real data, and integrations with other systems hold surprises.
Estimates for software therefore carry real uncertainty, which narrows as the project progresses. At the idea stage, an estimate may be off by a factor of two or more. After discovery, the range narrows considerably. After a few development cycles with the same team, estimates for the remaining work become fairly reliable. Any contract model is really a way of deciding who carries this uncertainty and how it is managed.
Fixed price: how it really works
Under a fixed-price contract, the vendor agrees to deliver a defined scope for a defined price, usually with milestones and payments tied to them. If the work takes longer than estimated, the vendor absorbs the cost. If it takes less, the vendor keeps the difference.
To make this work, the vendor needs a precise definition of scope. Anything not clearly in the scope document is, by default, out of scope. Vendors therefore add a contingency to the price to cover uncertainty — a risk premium — and manage changes strictly through change requests.
Where fixed price works well
- Small, well-defined projects: a specific integration, a defined report set, a migration with known data.
- Projects where the requirements are already detailed and stable, perhaps because a similar system exists.
- A defined discovery or prototype phase with clear deliverables.
- Later releases of an existing product, where the team knows the system and the scope is well understood.
Where fixed price struggles
- Uncertain requirements. If you do not yet know exactly how the software should work, the scope document will be vague, the risk premium high and change requests frequent.
- Learning during the project. Fixed price discourages change. But seeing working software is precisely when users realise what they really need.
- Misaligned incentives. The vendor's profit grows when they deliver the minimum that satisfies the written scope. Quality aspects that are hard to specify — usability, maintainability, test coverage — are at risk.
- Disputes. Arguments about whether something was "in scope" consume time and goodwill that should go into the product.
Time and materials: how it really works
Under time and materials, you pay for the effort actually spent — usually at agreed rates per role — plus any direct costs such as third-party services. You direct the work through priorities; the vendor provides the team and expertise.
Where T&M works well
- Projects where requirements will evolve, such as new products and systems replacing informal processes.
- Long-running product development and ongoing improvement after launch.
- Work where you want to learn from each release and adjust priorities.
- Relationships where you have a capable product owner who can direct the team.
Where T&M struggles
- Weak client-side ownership. Without someone to prioritise and decide, effort drifts into low-value features.
- Lack of transparency. If you cannot see what the team is doing and what it has delivered, T&M feels like an open cheque.
- Budget anxiety. Finance teams and boards often need a figure to approve. Pure T&M with no cap is hard to approve.
Where the risk really sits
| Risk | Fixed price | Time and materials |
|---|---|---|
| Estimate turns out too low | Vendor carries it (but priced in as contingency) | Client carries it |
| Requirements change | Client pays through change requests | Client reprioritises within budget |
| Requirements were misunderstood | Disputed: was it in scope? | Corrected in the next cycle |
| Quality below expectations | Depends on how precisely quality was specified | Visible early; client can redirect or stop |
| Vendor works slowly | Vendor's problem, but may cut corners | Client's problem unless monitored |
| Project should change direction | Expensive: contract renegotiation | Straightforward: change priorities |
The table shows that neither model removes risk; each moves it. Fixed price protects you against the vendor's estimation errors but makes change expensive and can hurt quality. T&M makes change easy and keeps incentives aligned with quality but requires you to manage scope and monitor progress.
Three worked scenarios
Scenario A: A defined integration
A distributor wants its online store to send confirmed orders to its inventory system and receive stock levels back every hour. Both systems have documented APIs, the data mapping is known, and the business rules are simple. This is a good fit for fixed price: the scope can be written precisely, the uncertainty is low and the vendor can estimate reliably.
Scenario B: Replacing spreadsheets with a business system
A manufacturer wants to replace a web of spreadsheets for production planning, job tracking and dispatch. Nobody has written down exactly how planning works; it lives in the planner's head and her spreadsheets. Users will certainly change their minds when they see the first screens. A fixed price here would require a large contingency and lead to constant change requests. A better structure is a fixed-price discovery, followed by T&M development with a capped budget per release. After discovery, both sides know enough to set a realistic budget for release one, and the client keeps control over priorities within it.
Scenario C: A new SaaS product
A founder wants to build a SaaS product for a niche industry. The first version will be tested with early customers, and the product will change based on their feedback. Requirements are inherently uncertain and will remain so for months. Time and materials with a monthly team budget, clear priorities and regular releases fits best. Fixed price for a product still searching for its market would lock in assumptions that customers will overturn.
Hybrid models that work
Fixed discovery, then T&M with caps. A short fixed-price discovery produces scope, designs and a plan. Development then proceeds on T&M, with a budget cap per release and the right to adjust scope within the cap. This combines early certainty with flexibility where it matters.
Fixed price per release. After the first release, when the team knows the system and the business, each subsequent release is scoped and priced as a fixed package. This works well for mature products with predictable work.
Capped T&M ("not to exceed"). T&M billing with an upper limit for a defined scope. If the limit is approached, the parties review scope together before continuing. This gives finance a number while keeping flexibility.
Dedicated team. For ongoing development, a stable team is reserved for you each month. You set priorities; the team delivers continuously. Costs are predictable per month, and the team accumulates deep knowledge of your business.
Contract terms that matter more than the pricing model
Whichever model you choose, these terms often determine whether the relationship works:
- Ownership. Code and intellectual property created for you transfer to you on payment. Pre-existing components the vendor reuses are licensed to you perpetually for your use.
- Access. You have access to the code repository and test environments throughout, not only at the end.
- Acceptance. A clear acceptance process with reasonable timelines, based on agreed criteria.
- Change process. How changes are requested, estimated, approved and recorded.
- Transparency. For T&M, regular reports of time spent by person and task, linked to delivered features.
- Termination. Either side can end the contract with reasonable notice; on termination, you receive all code, documentation and credentials for work paid for.
- Warranty period. Defects found within an agreed period after acceptance are fixed at no cost.
- Support terms. Response times, scope and charging for support after launch.
- Third-party costs. Hosting, licences, API fees and app store fees are identified and borne as agreed — usually by the client, paid directly to the providers.
- Confidentiality and data protection. Protection of your business information and any personal data the vendor handles.
Keeping T&M under control
If you choose time and materials, these practices keep budgets predictable:
- Set a budget per release or per quarter, and review burn against delivered features every cycle.
- Maintain a prioritised backlog; the most valuable items are always built first.
- Insist on working software at the end of every cycle.
- Review time reports, but judge progress by delivered value rather than hours.
- Keep the right to pause, reduce or stop work with short notice.
Keeping fixed price healthy
If you choose fixed price, protect the project this way:
- Invest in discovery so the scope is precise before you sign.
- Specify quality expectations — performance, usability testing, test coverage, documentation — not just features.
- Agree a lightweight change process and a small change budget in advance.
- Tie payments to accepted, working milestones rather than calendar dates.
- Still ask for regular demos; fixed price does not mean waiting until the end to see anything.
How to choose
Ask three questions:
- How clear and stable is the scope? Clear and stable favours fixed price; uncertain or evolving favours T&M.
- How much will we learn during the project? If seeing working software will change your mind — and it usually does — you need flexibility.
- Do we have a strong product owner? T&M needs one. Fixed price needs one too, but mainly at the start.
For most business systems, the answer is a hybrid: fix what can be known, and keep flexible what cannot.
Summary
Fixed price and time and materials do not remove risk; they place it differently. Fixed price suits small, well-defined work and later releases of known systems. Time and materials suits evolving requirements and ongoing product development, provided you have a product owner and transparency. Hybrids — fixed discovery followed by capped T&M, or fixed price per release — often give the best balance. Above all, get the contract terms right: ownership, access, acceptance, change, transparency and termination matter more than the pricing model itself.
Frequently asked questions
Is a fixed-price contract safer for the client?
Only when the scope is genuinely clear and stable. When requirements are uncertain, fixed price shifts risk into change requests, disputes and a vendor motivated to deliver the minimum. The total cost can end up higher.
How do we control cost under time and materials?
With a capped budget per phase, a prioritised backlog, regular demos of working software, transparent time reporting and the right to stop or change direction at any point.
What is a hybrid model?
A common hybrid is a fixed-price discovery phase followed by time-and-materials development with a budget cap, or fixed price per release once each release's scope is agreed.
Who owns the code under each model?
Ownership is a separate contract term, not a feature of the pricing model. Make sure the contract transfers ownership of the code and intellectual property to you on payment, whichever model you choose.
Can we switch models during a project?
Yes, by agreement. Many projects start with time and materials while uncertainty is high and move to fixed price per release once the product and the working relationship are well understood.
