Fixed price or time and materials?
The contract type you pick decides who carries the risk when requirements change midway. Pick it on purpose.
· 2 min read · For anyone commissioning custom software for the first time
Before a line of code is written, one decision shapes the whole project more than any technical choice: do you pay a fixed price for a defined scope, or pay for the time and effort actually spent? Both are honest ways to work. They protect against different risks, and picking the wrong one for your situation causes most of the disputes that come up later.
Fixed price, in plain words
You agree on what will be built and what it costs, before work starts. This works well when requirements are genuinely settled — a known form, a known report, a known workflow. It protects you from cost overruns. It does not protect you from a scope that turns out to be wrong once you see the software running, because any change outside the original agreement is, correctly, a new negotiation.
Time and materials, in plain words
You pay for the hours actually spent, and the scope can shift as you learn more. This suits work where nobody — including an experienced vendor — can fully specify the outcome upfront, such as a genuinely new product or one built around AI, where the right approach often only becomes clear after seeing the first version. It protects you from being locked into a wrong scope. It does not protect you from a project that runs longer than expected, which is why regular check-ins on progress and spend matter more here than the contract type itself.
How to actually decide
- If you can write the requirements document today and expect it to still be right in three months, fixed price fits.
- If the honest answer is "we will know it when we see it," time and materials fits — and a fixed price quote for that situation usually means padding for risk, not certainty for you.
- A middle path many teams use well: fixed price for a first defined phase, then time and materials once the direction is proven.
How we can help
We are upfront with every client about which of these fits their project, and we quote accordingly rather than defaulting to one model for everything. Read how we scope and run a project on our process page. Tell us what you are building and we will tell you honestly which pricing model actually fits it.
