Opening Situation
You’ve landed a paid collaboration to build a new feature for a client’s web app.
The client wants a clear cost estimate, but you also anticipate possible pivots as the product evolves.
Choosing the right contract model—fixed‑price or time‑and‑materials—will shape budget predictability, scope control, and how you handle change.
Illustrative Story: Maya’s Mobile App
Background: Maya, an indie developer, signed a fixed‑price contract to deliver a fitness‑tracking app. The original brief listed three core screens and a basic API integration.
Mid‑project, the client requested a social‑sharing module and a premium subscription flow.
Outcome: Because the contract locked the price, Maya had to negotiate a change‑order that added additional fees and delayed delivery.
The experience highlights two decision checks every builder should evaluate before signing.
Decision Check 1 – Is the Scope Well‑Defined?
Ask yourself:
A 'yes' indicates a fixed‑price contract can provide budget certainty. A 'no' suggests risk of scope creep.
Consider whether the project requires iterative refinement or has ambiguous requirements that may evolve during development.
- Do you have a detailed functional specification?
- Are acceptance criteria and deliverables enumerated?
- Can you estimate effort with a reasonable confidence interval?
Decision Check 2 – Will the Work Require Frequent Pivots?
Consider the product’s maturity and the client’s decision‑making cadence:
A 'yes' suggests a time‑and‑materials model, which absorbs change without renegotiating the contract each time.
Evaluate whether the client’s vision is fluid or if they prefer a structured delivery timeline.
- Is the market still being validated?
- Will user‑feedback drive new features every sprint?
- Do you expect unknown technical challenges?
Failure Mode: Fixed‑Price Scope Creep
When requirements evolve after the contract is signed, the fixed‑price model can become a liability.