Shimira IT
Fixed price feels safer. You know the number, the vendor carries the risk, and there's no meter running. That's why most first-time buyers ask for it.
It's often the right choice. But fixed price has a cost that doesn't appear on the invoice, and there are projects where it produces a worse product for more money. Here's how to tell which situation you're in.
What you're actually buying
Fixed price: you buy an outcome. The vendor commits to delivering an agreed scope for an agreed number. They carry the risk of it taking longer, and they price that risk in.
Time and materials: you buy capacity. You pay for hours worked, see where they went, and can change direction. You carry the risk of it taking longer.
Everything else follows from that one difference.
The honest case for fixed price
- You can budget. Board approval, investor money, and grant funding often require a firm number.
- The vendor is motivated to be efficient, because overruns come out of their margin.
- Less management from you. You're buying a result, not supervising hours.
- A clear finish line, which matters when there's a hard deadline.
Choose it when: the scope is genuinely clear, you can describe what "done" looks like, and you don't expect to change your mind mid-build.
The hidden costs of fixed price
You pay a risk premium. A vendor pricing a fixed scope adds a buffer for what might go wrong, typically somewhere between 15% and 30%. If nothing goes wrong, you paid it anyway.
Change becomes adversarial. Every "could we also..." turns into a change request, a negotiation, and a delay. On a time-and-materials project it's just next sprint's work.
It rewards the wrong instincts under pressure. When a fixed-price project runs long, the vendor's incentive is to do the minimum that satisfies the letter of the scope. Tests and polish are the first things to quietly go.
It requires heavy upfront specification. Somebody has to write the scope in enough detail to quote against, which takes time and often costs money.
The scope is guesswork if the product is new. Fixed price works when you know what you're building. For genuinely new products, the first version is usually wrong in ways nobody could specify upfront.
The honest case for time and materials
- No risk premium. You pay for the work, not the buffer.
- Change is free, procedurally. Reprioritise every sprint without a negotiation.
- Better products, often, because you build what users actually need rather than what you guessed months earlier.
- Start sooner. Less upfront specification before work begins.
- Stop whenever. If it's not working, you stop, having paid only for work done.
Choose it when: the scope will evolve, you have someone who can make product decisions weekly, and you're building something genuinely new.
The obvious objection
"Time and materials means they can bill forever."
It's a fair worry, and it's manageable. The protections that matter:
- A cap you both agree, revisited at an agreed point
- Working software every two weeks, so progress is something you see rather than take on trust
- Logged hours you can review, itemised by person and task
- Sprint-by-sprint priorities you set
- The right to stop at any sprint boundary
With those in place, the risk is manageable. Without them, it's real, and you should say no.
The middle grounds
Fixed-price discovery, then time and materials. One to two weeks paid to produce a written scope, then build against it. You get a much better estimate, and the scope is yours to keep even if you change vendor.
Fixed price per phase. Quote and commit one phase at a time. You get budget certainty in chunks, without a six-month fixed scope nobody can predict.
Time and materials with a cap. Billed hourly, but the vendor commits not to exceed a ceiling without approval. A common compromise, and honest on both sides.
Dedicated team. A fixed monthly cost per developer, working to your roadmap. Predictable like fixed price, flexible like time and materials, which is why most ongoing product work settles here.
Which fits which project
| Situation | Usually best |
|---|---|
| Well-defined build, hard deadline | Fixed price |
| New product, unclear requirements | Time and materials, or phased fixed price |
| Board or investor needs a firm number | Fixed price, or T&M with a cap |
| Ongoing development after launch | Dedicated team |
| Small, contained piece of work | Fixed price |
| Rescuing or taking over existing software | Fixed-price audit, then fixed price per phase |
| You have strong in-house product leadership | Time and materials |
| You have no time to manage it | Fixed price |
What to watch for in either model
On fixed price: an unclear scope document, no list of what's excluded, vague assumptions, a large upfront payment, and no definition of what happens if you stop halfway.
On time and materials: no cap, no logged hours, no working software at the end of each sprint, and no ability to stop cleanly.
The common thread is visibility. Whichever model you pick, you should be able to see progress and stop if it isn't working.
What we do
We work in all three: fixed price when the scope is clear, time and materials when it will evolve, and dedicated developers for ongoing work. Our published rates cover each, so you can compare without a sales call.
For work where nobody can yet know the scope, such as taking over existing software, we start with a fixed-price audit and then quote fixed prices per phase against what it found. That gives you certainty at each step rather than a guess at the start.
If you're weighing quotes across different models, our guide to comparing software development quotes covers how to normalise them, and freelancer vs agency vs dedicated team covers who you're buying from.