Fixed price or time and materials: how to pay for software

A fixed price suits work that is well understood and unlikely to change — a defined integration, a website from an agreed design, a known report. You know the cost before you start.

The catch is that the supplier carries the risk of the unknown, so a sensible one adds a margin for it. And every change becomes a negotiation, which pushes both sides to defend the original document rather than build the best thing.

Paying for the time spent suits work that will be discovered as it goes — a new product, a process nobody has written down, a system that must evolve with your business. You can change priorities every week without a contract amendment.

It needs trust and visibility: regular demos of working software, a clear backlog, and a budget ceiling with warnings well before it is reached.

For most custom projects we recommend splitting the work, so each step is priced on what is known by then:

1. A short, fixed-price discovery: workshops, the data model, key screens and a costed plan.
2. A fixed-scope first release built from that plan — the smallest version people can use.
3. Ongoing improvement on time and materials, or as a monthly retainer, steered by what users actually need.

Who owns the code and the data (it should be you). How often you see working software. What “done” means for each piece. How hosting, support and changes are charged after launch. Settling these in writing prevents most of the arguments that end projects badly.