Most buyers assume fixed-price is the safe option and time-and-materials is the one where a vendor runs up the meter. That instinct is understandable and it is usually wrong. Both models are legitimate; the failures come from applying one to work that has the shape of the other. It is worth understanding what each actually does before you decide which to insist on.
A fixed price is not a promise about cost - it is a transfer of risk, and risk has a price. When a vendor quotes a fixed number, they are estimating the work, adding a margin for everything that might go wrong, and accepting the consequences if their estimate was optimistic. That margin is real and you pay it whether or not the risk materialises. On a well-specified piece of work, the margin is small because the uncertainty is small, and fixed-price is excellent value. On a vague brief, the vendor either pads heavily or bids low and recovers the difference through change requests - and the second is how projects turn adversarial.
Time-and-materials moves that risk back to you and removes the padding. You pay for the work actually done. The obvious objection is that it gives the vendor no incentive to be efficient, and that objection is fair unless you build in the things that make it work: a named budget cap you both track, fortnightly demonstrations of working software rather than status reports, and the right to stop at any increment. With those in place, time-and-materials is usually the cheaper model, because you are not paying anyone's insurance premium against uncertainty you could simply manage.
The practical test is a question about your own brief, not about the vendor. Could you hand your specification to three different firms and get back three implementations you would consider equivalent? If yes, the work is genuinely defined and fixed-price is appropriate - a data migration, a well-understood integration, a compliance remediation with a published control list. If the honest answer is that the specification would be interpreted three different ways, then it is not fixed in any meaningful sense, and pricing it as though it were just moves the argument to later.
There is a third structure that suits most product work better than either: fixed-price the discovery, then time-and-materials the build. Discovery is genuinely boundable - a few weeks producing an architecture, a costed roadmap and a specification you could take to another vendor. It is also the phase where a bad partner is cheapest to leave. Once discovery has removed the uncertainty, the build can be estimated properly and run incrementally, and you enter it knowing what you are buying.
Whichever you choose, two clauses matter more than the pricing model. The first is what happens when scope changes, because it will - a good contract describes a process, not a penalty. The second is what you own and can walk away with at any point: source code, infrastructure accounts, documentation and data, provisioned in your name from the first day rather than transferred at the end. Contracts that get those two things right survive disagreements about everything else.
