Fixed Price, Time and Materials, or Retainer: Choosing a Software Contract

A software contract is a device for allocating a single risk: that the work turns out to be different from what either side expected. Fixed price puts that risk on the vendor. Time and materials puts it on you. Understanding which is appropriate, and how to build a structure that does not force the choice, is worth more to your project's outcome than the rate you negotiate.

Principle

What you are actually allocating

Every software project contains uncertainty: an integration behaves unexpectedly, data is worse than described, a stakeholder changes their mind, a requirement that seemed simple turns out to have nine states. The contract does not remove this uncertainty. It decides who pays for it.

That framing clarifies the whole decision. Fixed price means the vendor absorbs the cost of being wrong, and prices a risk premium accordingly, typically 15 to 30 percent. Time and materials means you absorb it, and pay no premium, but carry the exposure. Neither is generous or exploitative; they are simply different distributions, and the right one depends on how much genuine uncertainty your project contains.

Model 1

Fixed price: strengths and failure mode

Works when the specification is complete and stable, the vendor has built something closely comparable before, and the integrations are documented and testable. Under those conditions fixed price is excellent: you get budget certainty, the vendor is rewarded for efficiency, and everyone knows what "finished" means.

Fails when the specification is incomplete, which is most of the time. The failure mode is specific and predictable: because the vendor's margin now depends on scope not expanding, every conversation about a genuine improvement becomes a commercial dispute. You stop raising good ideas because raising them is expensive. The relationship turns adversarial precisely when it most needs to be collaborative.

The other failure mode is the padded quote. A vendor pricing a vague specification must either add a large contingency, making you overpay when nothing goes wrong, or price optimistically and recover through change requests. Neither serves you.

Model 2

Time and materials: strengths and failure mode

Works when discovery genuinely continues into the build, when you want the freedom to change direction based on what you learn, and when you have someone on your side capable of reviewing progress critically.

Its underrated virtue is that it removes the scope argument entirely. A better idea in week five is simply a decision about priorities, not a negotiation. Projects run this way tend to produce better software, because the best requirements are usually discovered halfway through.

Fails when nobody is watching. Without a cap, a milestone structure, and weekly verifiable output, time and materials can drift indefinitely, and the drift is rarely malicious, just unmanaged. It also fails when you cannot get internal approval for an open-ended number, which is a real constraint in many organisations regardless of the merits.

Model 3

Retainers: what they are good for

A retainer buys capacity, not a deliverable, typically a set number of hours or days per month at an agreed rate. It is the wrong instrument for building something new and the right one for the years afterwards.

Use a retainer for continuous improvement, security and dependency updates, performance work, and guaranteed response times when something breaks. Its real value is availability: without one you join a queue at the moment you can least afford to.

Insist on two things. Define what happens to unused hours, rolling over for one month is a fair norm, silent forfeiture is not. And define response commitments explicitly, because response time is what you are actually buying.

Comparison

Side-by-side

Recommendation

The hybrid that usually works best

For most five-figure projects, neither pure model is right. This three-stage structure is:

1. Fixed-price discovery. A small, defined fee, often 5 to 10 percent of the expected build, for a documented specification, data model, wireframes, and a costed estimate. The deliverable is yours regardless of what happens next. If the vendor is wrong for you, you learn it cheaply and keep a document you can competitively tender.
2. Fixed price per milestone, or capped time and materials, for the build. Because the specification now exists, fixed price per milestone is genuinely priceable. Where uncertainty remains, use time and materials with a not-to-exceed cap and the right to stop at any milestone boundary.
3. Retainer after launch. Agreed before launch, not negotiated during the first incident.

Commercials

Payment schedules and holdbacks

Tie every payment to a verifiable deliverable rather than a calendar date. "On acceptance of the authenticated user module in staging" is enforceable; "at the end of month two" pays for elapsed time.

A defensible structure for a fixed-price build: 30 percent on signing, 30 to 40 percent spread across build milestones, and 20 to 30 percent on final acceptance. Resist paying more than half before you can click through working software in a staging environment.

Consider a small holdback of 5 to 10 percent, released 30 days after launch, to cover defects that surface in real use. Frame it as a warranty mechanism rather than a trust issue; experienced vendors are used to it and reasonable about it.

Protection

Six clauses worth insisting on

1. IP assignment on payment, with the repository in your organisation's account from the first commit.
2. A written change process: estimate first, your approval required, no work begins without it.
3. Acceptance criteria defined before build, as a testable list.
4. Key personnel named, with notice required before substitution.
5. Termination for convenience at any milestone boundary, paying for work completed. This single clause caps your downside more effectively than any other.
6. Handover obligations: documentation, credentials, and a knowledge transfer session, due whether the relationship ends well or badly.

$100 for a one-hour session, billed at $25 per 15 minutes with a one-hour minimum. You choose your time on Calendly immediately after checkout. Pay by card or M-Pesa.

FAQ

Frequently asked questions

Which contract type is best for software development?

Fixed price suits well-specified, bounded work where the requirement will not change. Time and materials suits evolving work where discovery continues during the build. A retainer suits ongoing improvement after launch. Most successful five-figure projects use a fixed-price discovery phase, then either a fixed price per milestone or time and materials for the build.

Why do fixed-price software projects go wrong?

Because the price is fixed but the requirement is not. A vendor prices the specification as written, then every clarification becomes a commercial negotiation instead of a technical decision. This is manageable when the specification is genuinely complete, and corrosive when it is not.

Is time and materials riskier for the client?

It transfers budget risk to you, but it also removes the incentive to argue about scope. The risk is managed with a not-to-exceed cap, a fixed-price discovery phase that produces a credible estimate, weekly deployed progress you can verify, and the right to stop at any milestone.

What payment schedule is fair for a software project?

Milestone-based, with each payment tied to a verifiable deliverable rather than a calendar date. A common structure is 30 percent on signing, 30 to 40 percent across build milestones, and 20 to 30 percent on acceptance. Avoid schedules where more than half is paid before you can click through working software.