Working together · 6 min read

Fixed price or time and materials: how should you pay for software?

Published 7 July 2026 · Updated 8 September 2026 · By Sam Fourie, Niddo

Pay a fixed price when the scope can be written down, which for most first versions it can. Pay time and materials when the work is genuinely open-ended: research, an evolving product with an internal owner, or ongoing improvement after launch. The worst option is a fixed price on a vague scope, which produces either a padded quote or an argument about what was included.

The three ways to pay

Model	How it works	Right when	Wrong when
Fixed price	One figure for an agreed scope, paid in milestones	The scope is clear and the outcome matters more than the hours	The scope is a wish list or decisions are still open
Time and materials	You pay for the hours worked, usually with an estimate	The work is exploratory or you have a product owner steering daily	You want a predictable number and nobody on your side is managing it
Retainer	A monthly amount for a standing team or a block of hours	Running and improving a live product	There is a large build to deliver first

What a fixed price really includes

A fixed price is a transfer of risk. The studio is promising the outcome for the number, so a good one does three things before quoting: scopes properly, writes down what is out as well as what is in, and agrees how changes are handled. The price includes the cost of being slightly wrong about scope, which is why it is not simply the hourly estimate. In return you get certainty, and a team with every incentive to finish.

The mechanics matter. Payment should follow milestones with defined deliverables, each accepted on a staging environment, not the calendar. A defect (the delivered work does not meet the scope) is fixed for free; a change (something outside the scope) is quoted before it is built. A short warranty after acceptance is normal.

Where fixed price goes wrong

A vague scope. If the document says "a booking system", every disagreement about what that means becomes a negotiation.
Open decisions. Unresolved choices (which payment provider, which identity check, what happens on cancellation) either get priced pessimistically or block the build.
No change process. Without a written way to handle new requests, the studio either absorbs them and cuts corners elsewhere, or refuses them and looks difficult.
Milestones tied to dates instead of deliverables, so payment and progress drift apart.

Where time and materials goes wrong

Nobody is paid to finish. The estimate drifts, and the cost of saying "that is enough" falls entirely on you.
You become the project manager. Without an internal product owner making daily calls, hours are spent waiting and re-deciding.
The number is unknowable at the start, which makes it hard to fund, approve or compare against alternatives.

The hybrid that works

For most products: a short, fixed-price scoping phase that produces a written specification you own; a fixed-price build in milestones; then a retainer or block of hours for running and improving the product once it is live and the work becomes open-ended by nature. Each phase is priced the way its risk profile deserves.

Five questions to ask before you sign

What exactly is out of scope, in writing?
How is a defect distinguished from a change, and who decides?
What is the payment schedule, and what triggers each payment?
What happens if a decision on my side is late?
What do I own, and when: code, repositories, accounts, documentation?

How Niddo does it

Every build is scoped with you, then priced as one fixed figure with a deposit and milestones you accept on staging. Changes are quoted before they are built. After launch we either run the product with you on a retainer or hand it over documented. Tell us what you are building and we will come back with a plan, a timeline and a price.

Questions