Fixed price or time and materials?

What each model is actually pricing

A fixed price is not a price for the work. It is a price for the work plus the risk that the work was mis-estimated — and that risk premium is carried by the vendor, which means you pay for it whether or not it materialises.

Time and materials removes the premium and hands you the risk instead. If the estimate was optimistic, that is your problem rather than the vendor's. Neither arrangement is more honest than the other; they differ in who is holding the uncertainty.

When fixed price is the right instrument

Most well-specified builds sit here: a marketing site, a defined operations tool, a mobile app against an API that already exists, a hardware revision with a settled bill of materials.

• The scope can be written down to the screen and the field, and both sides agree it is complete.
• The integrations are known and documented, and you have access to test against them.
• Nobody is expecting to learn something during the build that changes what should be built.
• You need a number for a board, a grant or a procurement process.

When it is the wrong instrument

Research-shaped work — a new model, a novel sensor, an integration with an undocumented legacy system — cannot be fixed-priced honestly. A vendor who quotes a fixed price for it has either padded it heavily or intends to recover the difference through change requests. Both outcomes are worse for you than an honest day rate with a cap.

The tell is whether anyone can describe what “done” looks like without using the word “works”.

The hybrid that usually fits

Price the discovery separately and small. Two weeks, fixed, producing a written scope, an architecture, a risk list and a number. At the end of it you own the document whether or not you proceed, and you can take it to another vendor.

Then fix-price the build against that scope, because by then it is genuinely knowable. The research risk was spent in a bounded phase rather than smeared across a project where it quietly becomes an argument.

The clauses that decide whether either model works

• Change requests are quoted before they start. Not reconciled at the end. A change request that surprises you at invoicing is a failure of process, not of estimation.
• Source in your repository from the first commit. Not delivered at the end, not held against final payment. This is the single clause that keeps everyone honest, because it makes leaving possible at any point.
• Infrastructure in your cloud account. You pay the provider directly and you can revoke our access in one click.
• A named engineer, not a pool. With the right to be told, in advance, if that changes.
• Acceptance defined as a list of behaviours, written during scoping, not negotiated during delivery.

What we do

Fixed price against a written scope for defined builds, a bounded discovery phase when the scope is not knowable yet, and a monthly retainer for ongoing work with a named engineer attached. The rate card for every capability is published on this site, which makes the arithmetic checkable before you talk to anyone.