Fixed Price or Time and Materials? 5 Contract Clauses That Decide Your Software Budget

The sentence most often rushed through in an outsourcing negotiation is the total price. Yet the same requirements, written as a fixed-price contract versus a time-and-materials contract, allocate risk in opposite directions. When scope grows, fixed price pushes the overrun onto the vendor. Time and materials hands it back to the client, because more hours mean a larger invoice.

At Juhui Software we have run custom software projects both ways for a decade. This is not an argument that one is correct — each fits different situations. It is an account of what must be written down before signing, so the budget does not slip away mid-project.

1. Two pricing models, opposite risk directions

Fixed price assumes scope is clear enough to commit to. The vendor delivers within the agreed scope; anything beyond is negotiated separately. The benefit is a predictable budget. The cost is that a vendor protecting its margin will trim at the scope boundary, or read ambiguous features as "not included".

Time and materials assumes trust and visible process. The vendor bills actual effort, the client confirms hours by stage. The benefit is flexibility. The cost, without a cap clause, is an invoice that grows alongside requirements. In practice a hybrid is most common: core functionality at fixed price, exploratory or high-uncertainty work at time and materials.

2. Clause one: a scope list detailed enough to accept

Whichever model you choose, the scope list must be detailed enough to accept against. The test: can each line be written as "by this action, this result appears, and that counts as done"? Any line that cannot reach that level becomes a dispute later.

Split the list into three tiers: must-have (the business loop depends on it), should-have (efficiency gains), nice-to-have. A fixed-price contract folds the must-haves into the price and quotes the nice-to-haves as phase two. A time-and-materials contract uses the tiers to control priority, so not every request is treated as equally urgent.

3. Clause two: change requests need a form and a unit price

Every outsourcing contract needs a change mechanism: how a change is requested, how quickly an estimate is returned, and at what unit price. Without all three, changes become verbal arrangements — and verbal arrangements usually surface as one large confrontation at the end of the project, when neither side has room to move.

A more practical approach is to attach a change rate card to the contract: the price of a standard screen, a mid-complexity interface, an admin list page. With that card, any new request converts into a number on the spot, and the conversation shifts from whether to do it to whether it is worth it.

4. Clause three: time and materials needs a ceiling

If you choose effort-based pricing, put at least three brakes in the contract: a total person-day cap, a monthly hour cap, and a written approval process for exceeding either. Without them, a contract that bills actual effort has no mechanism to stop the invoice growing as requests accumulate.

Also require visible effort: weekly or biweekly timesheets naming who did what. This is not distrust; it lets the client catch drift in the month it happens rather than at settlement. In our experience, projects that catch drift early typically overrun by under 10 percent. Projects that discover it at settlement often overrun by more than 30 percent.

5. Clause four: payments tied to acceptance milestones

Budget clauses must attach to deliverable milestones. The common structure is four payments, each tied to a verifiable output: signing, design or prototype approval, development complete and submitted for testing, and acceptance and go-live.

Watch two details. First, the retention ratio: below 10 percent, the vendor has little incentive to fix defects after launch. Second, the acceptance standard: name the document and version that acceptance is measured against, rather than writing "meets client requirements", which is almost impossible to evidence in a dispute.

6. Clause five: price scope creep in advance

Change requests have forms; scope creep does not. "Just add an export", "change this field", "tweak the styling while you are in there". Each is small; cumulatively they often reach dozens of person-days.

Handle it by giving small changes an allowance in the contract: minor adjustments within a set number of person-days per month are included, anything beyond goes to the change rate card. This solves both sides at once — the client does not run a process for every tweak, and the vendor's entire buffer is not consumed by unbounded small requests.

7. Three more things to write down

Intellectual property: copyright in source code, designs and documentation transfers to the client on final payment, with third-party and open-source components listed separately. Leaving this vague invites repeated questions at vendor changeover or due diligence.

Team stability: changes to core developers must be disclosed in advance, and key personnel must not be reassigned during critical phases. The most common schedule accident in outsourced projects is the lead developer being pulled onto another project.

Termination: how completed work is settled if the project ends mid-way, how source code and documentation are handed over, how data is exported. Rarely used, but when it is used the relationship has usually already broken down, and there is no negotiating room left.

So fixed price versus time and materials is not a style preference — it is a risk allocation decision. Clear scope with few changes suits fixed price; exploratory requirements that need to be seen before they are known suit effort-based or hybrid pricing. Write these clauses in, and either model holds. Real budget protection lives in the clauses, not in the number.