Fixed-price development: what the model actually puts on each side

Fixed-price development is not a commercial gesture or a sales argument: it is a transfer of risk. Once price and scope are committed in the contract, the overrun becomes the supplier's problem. That only holds if the contract describes what is committed precisely enough — otherwise the fixed price turns into a change-order machine and the risk returns to the client through the back door.

What each model actually rewards

A billing model shapes day-to-day decisions on both sides, whatever the goodwill of the people involved. On time and materials, every day worked is invoiced: nothing structurally rewards finishing early, and it falls to the client to drive pace, priorities and quality. On a fixed price, every day beyond the estimate costs the supplier: the incentive is to deliver quickly, but also — where the contract is badly written — to classify every request as out of scope.

Neither model is morally superior. They answer different situations, and the choice turns on one question: can the scope be described today, in writing, with its business rules and edge cases? If the answer is yes, a fixed price protects the client. If it is no, a fixed price traps them.

What makes a fixed price sustainable for the supplier

A committed price is not an act of bravery, it is the output of prior work. The conditions below are not comfort preferences: without them the commitment is a bet, and a lost bet is always paid in quality, schedule or conflict.

When time and materials is the right answer

There are situations where demanding a fixed price is a client-side mistake, and accepting one would be a supplier-side fault.

• The scope is genuinely unknown: a product still being researched, a usage still to be validated, a need that will only sharpen as you go.
• You have an in-house team to reinforce and technical leadership already in place: you want capacity, not an outcome commitment.
• The work is continuous evolutive maintenance on an existing system, with no identifiable batch and no foreseeable end.
• Urgency outweighs scoping: you must start within days and you accept the cost in budget visibility.

In those cases a fixed price signed anyway is a fixed price in name only. The supplier will either pad the estimate to stay safe, or cut it to win the work and recover on change orders. Both outcomes are bad for a client who would have been better served buying days and owning the steering.

Our change-order procedure

1. 1

   Written qualification of the request

   Every new request is examined in writing: what it changes, and whether it falls inside the signed scope, clarifies that scope, or is a genuine addition. A meaningful share of requests is settled here, at no extra cost.

2. 2

   Separate estimate, given before the decision

   If it is an addition, it is priced in days, with its effect on the schedule of the remaining batches. You get the estimate before you decide, never after the work is done.

3. 3

   Arbitration by the business owner

   Your business owner picks one of four options: add it and pay, drop an equivalent item from the scope, defer it to a later batch, or abandon it. The choice and its reason are written down.

4. 4

   Signed change order, scope updated

   The change order amends the contract and the scope document, which remains the single reference. No out-of-scope development starts before it is signed.

Who writes these rules

MEKANO is a Lyon-based development studio. We build the management applications of small and mid-sized companies and of buying groups: member portals, supplier approval, revenue declarations, year-end rebate engines, document management. We delivered, at a fixed price and in successive batches, the full rebuild of the management system of a Lyon buying group of more than 60 member companies, in Go, React and PostgreSQL, with the source code handed over. When time and materials is plainly the right model for a need, we say so and we decline the project.