Pricing software projects honestly
Fixed price transfers risk to the vendor, who prices it in. Time and materials transfers it to you. Here is the model we use instead.
Key takeaways
- Fixed price hides a contingency and creates an incentive to fight scope.
- Discovery is knowable, so price it fixed; delivery is not, so price it per increment.
- A wrong estimate should surface within one increment, not at the end.
What is the fairest way to price a software project?
Price discovery fixed, because its scope is knowable, then price delivery per two-week increment against the scope agreed at the end of discovery. Risk stays visible, either side can stop at a boundary, and nobody is protecting a contingency the other party cannot see.
Both standard models move risk rather than removing it
Fixed-price contracts do not remove risk. They move it to the vendor, who prices it in with a contingency you cannot see and then fights every scope change to protect it.
Time and materials moves the risk to you and removes the vendor's incentive to be efficient. Neither model is dishonest on purpose; both just misdescribe what is happening.
Where the risk actually sits
| Model | Who carries risk | Failure mode |
|---|---|---|
| Fixed price | Vendor | Hidden contingency, adversarial change control |
| Time and materials | Client | No efficiency incentive, open-ended spend |
| Fixed discovery + increments | Shared and visible | Requires discipline on both sides |
How the increment model runs
We price discovery fixed, because the scope of discovery is genuinely knowable. Then we price delivery per two-week increment against a scope we both agreed at the end of discovery.
If the estimate turns out wrong, that is visible within one increment rather than at the end of the project. Nobody is protecting a contingency, and either side can stop.
An estimate is a forecast, not a promise. The contract should make it cheap to be wrong early rather than expensive to admit it late.
What the increment model requires from both sides
The model is not free. It asks the client for a decision-maker who can attend an increment review every two weeks, and it asks us to show working software rather than a status report. Where either side cannot hold that, the increments quietly become invoicing periods and the benefit disappears.
It also asks for honesty about scope earlier than most procurement processes expect. Discovery produces a scope both parties sign, and anything discovered afterwards is handled as a visible trade rather than absorbed silently. Clients sometimes find that uncomfortable at first, because a hidden contingency feels like protection until you need to change something.
What it removes is the end-of-project surprise. Nobody has ever been told by us in month nine that a project needs another three months, because by month nine there have been eighteen chances to say it.
FAQFAQ
Frequently asked questions
About the author
Sofia runs delivery across engineering engagements — discovery, estimation, increments and handover. She writes about migrations, pricing models and the undocumented business logic that turns a clean estimate into an overrun.
- Enterprise migrations
- Project estimation
- Delivery management
- CRM and ERP systems
