← All news & guides

Guides

Fixed Price or Time and Materials? How to Choose a Contract for Your Bespoke Software Project

The short answer

Fixed price works when you know exactly what you want built. Time and materials works when you don't, or when the project is likely to change shape as you go. Most bespoke software sits somewhere between the two, which is why the contract matters as much as the quote.

Neither option is a trick. They're just two different ways of sharing risk between you and whoever's building the thing. A contract is formally defined as a mutually binding agreement that obligates the seller to deliver a specified product, service or result, and obligates the buyer to pay for it. Everything else in this guide is really about where the risk sits inside that agreement, and how to make sure it sits somewhere sensible before you sign anything.

What a fixed price contract actually protects you from

A fixed price (sometimes called lump-sum) contract sets one total price for a well-defined product. The key phrase there is "well-defined." If the scope is genuinely nailed down, a fixed price is great for a finance director: one number, one invoice, no surprises. If it isn't nailed down, both sides are taking a gamble, because a fixed price contract on a poorly defined product puts both buyer and seller at risk.

Here's what that means in practice. Under a proper fixed price deal, you as the buyer get a defined cost with no overruns, though the initial price may be a bit higher than a day-rate estimate to cover the agency's risk. In exchange, the agency carries the risk of loss if costs run over or the project turns out to need more work than anyone first thought. That trade-off is spelled out plainly: the buyer gets cost certainty while the seller absorbs the risk of overruns.

So when does fixed price suit you? When you've already done the thinking: you know the features, the pages, the integrations, the rules. This is common for a well-scoped website, a defined set of features for bespoke software development, or a project where you need to put one number in front of a board and have it stay accurate. It's a poor fit for anything exploratory, where nobody yet knows exactly what "done" looks like.

What time and materials actually protects you from

A time and materials (T&M) contract works differently. You pay for the actual time spent, charged at an agreed rate, plus the cost of any supplies. It's an open-ended arrangement, which means costs that aren't clearly defined up front can escalate into overages. That's the plain trade-off: T&M covers actual time and materials at a fixed rate but is open-ended, so undefined costs can grow.

Where T&M earns its keep is on projects where nobody can honestly scope everything on day one; think product builds that will evolve as you learn what users actually need, or software touching several legacy systems where the full picture only emerges once development starts. T&M contracts are especially useful when the scope is difficult to define, and they protect the agency from absorbing cost overruns on work nobody could have accurately quoted. The flip side is just as plain: that same source notes T&M shifts the risk of loss onto the buyer, meaning you.

That doesn't make T&M a worse deal, just a different one. One genuine advantage is that it tends to produce better working relationships between client and agency, because nobody's fighting over whether a change is

The bit nobody mentions: phases change everything

Whichever pricing model you pick, the single biggest thing you can do to protect yourself is break the project into phases, with payment tied to each phase's completion. This gives both sides a regular checkpoint to confirm the project is on track and the scope is still accurate, and crucially it gives you, the buyer, the flexibility to change vendors or stop altogether based on how a phase actually went. That's not a minor nice-to-have; it's described as a core way to reduce risk on both fixed price and T&M deals: phased payment lets both parties verify progress and gives the buyer an exit point if things aren't working.

In practice, this means a sensible contract, fixed price or T&M, should read like a series of smaller, checkable commitments rather than one giant leap of faith. Before you sign anything, make sure it actually covers the basics: a statement of work, a schedule, acceptance criteria, warranty terms, limitation of liability, how change requests get handled, and how either side can end the arrangement. These are named outright as the components a proper project contract needs to address: statement of work, schedule, acceptance criteria, warranty, liability limits, change requests, termination and dispute resolution.

Termination deserves its own line of questioning. Ask whether either party can end the contract, with or without notice, whether there's a penalty for ending early, who owns the finished work (this is the

What to do now

If you already know roughly what you need built, fixed price will likely give you the clean number your board wants. If the project is still taking shape, or touches systems nobody's fully mapped yet, time and materials with clear phases will probably serve you better and avoid an inflated price tag for risk that may never materialise.

Either way, don't sign anything until the scope, schedule, acceptance criteria and termination terms are written down in plain English. If you'd like a second pair of eyes on a quote you've already got, or you want to talk through which model fits your project, request a quote and we'll walk you through it. Or if you're still at the stage of working out what you actually need, have a look at our bespoke software development page first.

Sources