Fixed price vs time and materials: how to buy software without surprises

Fixed price means you agree a defined scope and a set price before the work starts. If the work takes longer than the supplier expected, that is the supplier's problem. If you want something outside the scope, it is re-quoted as a change.

Time and materials (often shortened to T&M) means you pay for the time actually spent, usually at a day or hourly rate, plus any costs. You can change direction at any point, but the final bill depends on how long everything takes.

The real difference is who carries the risk of the unknown. Under fixed price, the supplier does, so the supplier needs a clear scope and prices in a margin for uncertainty. Under T&M, you do, so you need visibility and control over how the time is spent.

Fixed price is the better choice when:

• The outcome can be described in concrete terms: pages, templates, features, integrations and acceptance criteria.
• The technology is well understood, such as a marketing site, a store on an established platform or a defined MVP.
• You have a fixed budget and need certainty for cash flow, a board or investors.
• You do not have the time or technical knowledge to supervise day-to-day spend.

The trade-off is flexibility. A good fixed-price project still allows change, but through a written change process rather than a quiet conversation. That is a feature, not a bug: it forces every addition to be weighed against its cost.

T&M is the better choice when:

• The problem is not yet understood well enough to write down, such as research, prototyping or integrating with a poorly documented legacy system.
• Priorities will genuinely change week to week based on what users do.
• The work is ongoing rather than a project with an end, such as continuous product development after launch.
• You have someone on your side who can read progress, set priorities and challenge estimates.

The risk with T&M is not dishonesty. It is drift. Without firm priorities, the work expands into the time available, and the budget follows.

In practice the best contracts combine both models in stages:

1. Define before you commit. A short audit or discovery phase turns a vague idea into a written scope. For larger builds this is often a small fixed-price piece of work in its own right.
2. Fix what is clear. Once the scope is written, price the build as fixed phases or milestones, each with its own deliverables.
3. Keep flexible capacity for the rest. For genuine unknowns, agree a capped T&M allowance or a monthly retained capacity, with a regular review of how it is used.

Staging also limits your exposure. If the first phase goes badly, you have spent a fraction of the budget and can change course.

Fixed price only works if the scope is specific. Before you sign, check that it includes:

• A list of every page template, feature and integration, not a general description
• What is explicitly out of scope
• Acceptance criteria: how you will both agree that each item is done
• Who supplies content, designs, data and access, and by when
• The number of design revision rounds
• Browsers and devices supported
• What happens after launch: warranty period, hosting and support
• Payment schedule tied to milestones rather than dates
• Ownership of code, designs and accounts

If a supplier cannot produce this, the price is not really fixed. It is an estimate waiting for an argument.

Most budget surprises come from change, not from bad estimates. A healthy change process looks like this:

1. Either side can raise a change at any time.
2. The supplier replies in writing with the impact on price and timeline.
3. Nothing is built until you approve it.
4. Approved changes are logged, so the final invoice can be traced line by line.

Two warning signs: a supplier who says yes to every request without mentioning cost, and a supplier who treats every clarification as a paid change. The first will surprise you at the end; the second will wear you down throughout.

Before signing with any supplier, ask:

• Is this price fixed, and what exactly would make it change?
• How often will I see working software, not just status updates?
• What happens if you underestimated the work?
• How do you handle a change I request halfway through?
• What deposit do you take, and how is the balance split?
• Who owns the code if we stop working together?

Clear, specific answers matter more than the model itself.

• "Fixed price means no flexibility." It means flexibility has a visible price. You can still change your mind; you simply see the cost before you commit to it.
• "Time and materials is always cheaper." Only if the work goes to plan. Without firm priorities and someone watching the spend, it is often the more expensive route, and you only find out at the end.
• "Agile projects cannot be fixed price." Short sprints and fixed prices work well together. Fix the budget and the outcome for each phase, and let the team decide the order of work within it. Weekly demos give you the same visibility you would expect from any agile team.

The model is a tool for sharing risk sensibly. Pick the one that puts each risk with the party best placed to manage it.

We quote fixed prices. Every engagement starts with a free audit that maps what needs doing, followed by a written scope, timeline and price. Projects start with a 40% deposit and the balance is split across agreed milestones. You see progress weekly, and if the scope grows we re-quote rather than bill silently. For ongoing work, an embedded engineering pod is quoted per quarter at a predictable monthly cost.

You can see entry prices on our pricing page, read about our web development work, or send us your brief for a fixed quote.