Fixed price vs time and materials: which software contract protects you?

Fixed price means you agree the scope and the cost upfront, and the supplier carries the risk of it taking longer. Time and materials (T&M) means you pay for the hours worked, so you carry that risk instead. Fixed price suits a defined product with a clear finish line; T&M suits work whose shape genuinely can’t be known yet.

We sell fixed price, so read this knowing that. We’ll still tell you when T&M is the better deal. The real choice is simpler: are you buying a result, or buying time?

“People should be shopping for outcomes, not shopping for day rates.”

What’s the difference between fixed price and time and materials?

Under a fixed price contract, you agree what will be delivered and what it costs before work starts. If it takes longer, the supplier absorbs the extra time. If you want more, you agree a change.

Under time and materials, you pay a day rate or hourly rate for the people working on your project. You also pay for materials, like software licences or hosting. The scope can move freely. So can the bill.

There are hybrids too:

• Capped T&M: you pay for hours, up to an agreed ceiling.
• Fixed price per phase: each stage is priced once the one before it is done.
• Retainer: a fixed monthly fee buys a set amount of team time.

How does each model move risk?

Every software project carries the same uncertainty. The contract doesn’t remove it. It decides who holds it.

Neither is safe by default. A fixed price with a vague scope is just T&M with a dispute at the end. T&M with a disciplined team and a strong product owner can be very good value.

What T&M feels like from your side

Open-ended T&M is like having the builders in. “Oh, there’s 20 grand there now, oh, there’s 30 grand here now.” Each invoice makes sense on its own. Added up, they’re a ticking time bomb.

Each sprint, a short block of work usually lasting two weeks, feels reasonable. Six months later, nobody can say when it’ll be finished.

We once reviewed a product whose existing team wanted a large monthly fee to keep improving it. The product hadn’t launched, and the plan had no launch date in it. The founder was weighing that open-ended bill against a fixed-price rebuild. The money already spent was the price of learning the lesson. Paying it every month was the real risk.

The hidden risk in fixed price

With fixed price, the danger is a supplier who quoted low to win the work. They’ll protect their margin by cutting corners you can’t see, like tests and security. That’s why Discovery, and a scope you can read, matter so much.

Is a cheaper day rate actually cheaper?

Not if the job takes far longer. A low rate on a slow team can cost more than a higher rate on a fast one. What you’re buying is a working product, not a number of days.

T&M quotes often look cheaper because they show a day rate and an estimate, not a total. Multiply the rate by the top of the range, then add a margin for the changes you know you’ll make. Compare that figure with a fixed price, not the optimistic estimate.

Why more developers won’t rescue a late project

When a T&M project runs late, the usual fix is more people. You pay for every one of them. Fred Brooks observed in 1975 that adding people to a late software project often makes it later.

New developers need the existing team to explain the code to them. That slows down the very people who were doing the work. Every extra person also adds conversations. On a fixed price, that’s the supplier’s problem. On T&M, it’s on your invoice.

What should you ask before you sign either?

Whichever model you choose, the answers to these questions tell you more than the contract type does.

For a fixed price quote:

1. What exactly is in scope, and what is explicitly out?
2. What happens if you find the job is bigger than you thought?
3. How do I ask for a change, and how is it priced?
4. Who decides when a feature is finished?
5. What do I own if we stop halfway?

For a time and materials quote:

1. What’s your best estimate, as a range, and what drives the top end?
2. How often will I see hours against progress?
3. Can we set a cap, and what happens when we reach it?
4. Who on your side is accountable for the overall timeline?
5. What will I see working at the end of each sprint?

A good supplier answers all of these without fuss. Vague answers to the second list are the clearest warning sign you’ll get. If nobody can say what the top end of the range depends on, nobody is managing it.

What does fixed price app development need to be honest?

A fixed price is only as good as the scope it’s fixed against. Before you sign one, check for these:

• A written scope you understand. Features, screens and integrations in plain English, not just a page count.
• Discovery before the build. Nobody can honestly fix a scope they haven’t explored with you.
• A clear definition of done. What counts as finished, and who signs it off.
• Change control. A written process for what happens when you want something new.
• Payment by phase. You pay for one phase at a time, not everything upfront.
• A way out. What you get, and what you’re owed, if either side stops.
• Ownership of the code. The contract should assign the IP to you, in writing.

That last point catches people out. Under UK law, an assignment of copyright isn’t effective unless it’s in writing and signed (Copyright, Designs and Patents Act 1988, s90(3)). Our piece on who owns your code explains why that matters. This is general information, not legal advice.

If a supplier fixes a bespoke scope after a single call, be wary. They’re either padding it heavily or planning to argue about scope later.

How change control works with us

Change control separates two kinds of extra work. New ideas from you are changes, and they’re yours to decide on. Fixing what the supplier got wrong isn’t a change at all.

“You shouldn’t have to pay for their mistakes.”

On LaunchPad we use a one-in, one-out rule during the build. If you want to add a feature, we’ll suggest one to take out, so the price and timeline hold. Bigger ideas go on the post-launch roadmap. Or we quote one as extra work, and you approve the number first. Our answer to what if I want to add more features mid-way? explains it in full.

That’s the trade you make with fixed price. You give up some freedom mid-build. In return, the number you agreed only moves if you approve a change.

What does fixed price look like in practice?

Our LaunchPad packages are fixed price, excluding VAT:

Each one runs Discover, Design, Build, Launch. You pay in stages, with each phase invoiced in advance, starting with Discovery. If the plan isn’t right after Discovery, you get your money back.

The price covers everything up to launch, including developer accounts, hosting, licences and the services the build needs. The developer accounts, hosting and code can sit in your name from the start, or with us during the build and move to you at launch. It’s your choice. Support after launch is agreed separately before the build starts. You own the code and IP. Our pricing page lists what each tier includes.

Our tiers set the price. Discovery maps the users, the features and the launch plan with you, and sets what fits inside it. That’s what keeps the fixed price honest.

When is time and materials better?

T&M is the right call more often than fixed-price suppliers admit. We’d recommend it in these situations.

• You’re exploring, not building. Research, technical experiments and proofs of concept don’t have a fixed shape yet.
• The product is live and changing. Once you have users, priorities shift every week. Paying for team time fits that better.
• The work depends on things nobody controls. Think messy old data, or a poorly documented API, a connection to another company’s system.
• You have a strong product owner. That’s someone on your side who can set priorities daily and check the output.
• You’re adding to a team, not commissioning a product. If you need two developers alongside your own, a day rate is simpler.

Infrastructure work often falls into that category, because it grows with the business. For Ymobile, the UK’s first eSIM-only mobile network, we built the infrastructure for a data pipeline in Terraform. Terraform describes cloud infrastructure as code, so it can be rebuilt or extended reliably.

That pipeline feeds Databricks, giving Ymobile real-time analytics on how customers use the service. Work like that tends to keep moving in scope as the business grows. Read the Ymobile story.

When fixed price isn’t worth it

Don’t buy a fixed price project, from us or anyone, if one of these is true.

• You can’t yet say what version one does. A fixed price needs a goal. Even our Discovery needs to know what problem you’re solving.
• You expect to change direction every week. You’ll spend more time on change requests than on the product.
• The job is small. A bug fix or a single integration is cheaper on a freelancer’s day rate.
• You already have an in-house team. If you just need extra hands, buy hands, not a package.

And if you’re unsure whether your first version is defined enough, that’s what a Discovery phase is for. It turns an idea into a scope someone can price. With us, you get your money back if the plan isn’t right after it.

Which should you choose?

Run through both lists. Whichever one has more ticks is probably your answer.

Fixed price is likely right if:

• you can describe version one on a single page
• you have a set budget, such as a funding round or savings, that can’t stretch
• you aren’t technical, and can’t manage a development team day to day
• a launch date matters, because of investors, a season or a contract

Time and materials is likely right if:

• you’ll only discover the scope as you go
• you have someone technical who can manage the team
• your product is already live and has users
• you’re comfortable with a range rather than a single number

If the lists come out even, a fixed-price first version followed by a monthly package is a sensible middle path. You get certainty while it matters most, and flexibility once you have users to learn from.

If you’re a non-technical founder with a defined first version and a fixed budget, fixed price usually protects you better. See exactly what each LaunchPad package includes on our pricing page, or talk to us and we’ll tell you honestly which model fits your project.