Contracts
Fixed Bid, Hourly or Retainer: Which Protects You
How software gets priced, what each model rewards, and how to spot the version of each that transfers all the risk to you.
Every pricing model is a way of deciding who carries the risk of being wrong about scope. None of them is dishonest; the dishonest versions are recognisable, and this is how.
| Model | Vendor is rewarded for | Right when |
|---|---|---|
| Fixed bid | Being efficient; guarding scope | Scope can be written down |
| Hourly | Time passing | Genuinely exploratory work |
| Retainer / dedicated team | Staying useful | Ongoing roadmap, changing priorities |
The failure mode of each
- Fixed bid goes wrong when the scope is vague — then every question becomes a change request and the relationship turns adversarial.
- Hourly goes wrong when nobody is accountable for the total. The meter runs and the estimate was “just a guide”.
- Retainer goes wrong when it becomes rent — a team parked on your account with no visible output.
What to ask before signing, whichever it is
- Who writes the code, and can I speak to them today?
- What exactly is delivered, in a sentence a non-engineer can check?
- What happens if we stop in month two — do I keep the repo and the infrastructure?
- Is there an annual lock-in? Why?
About change requests
Change is normal; the question is whether the process is written down before work starts. Ours is: any change is priced and agreed in writing before it is built, and small changes inside a sprint are absorbed. What you should not accept is discovering the process only when the first change arrives.
Questions
Do you do dedicated teams?
Yes, for ongoing roadmaps. Fixed bid for scoped projects like a CRM, an app or a modernisation slice — we recommend whichever fits, not whichever bills more.
What if the project finishes early?
On fixed bid you pay the agreed price. That is the trade: we carry the estimate risk, you carry the certainty.
