· 6 min read
How we estimate, and why it is stage by stage
A single fixed price for a whole project favours the contractor, not the client. Here is how we do it, and where that leaves us exposed.
Clients often ask for one number covering the whole project, fixed in the contract. It is an understandable instinct, but there is a problem with it, and it does not work in our favour — quite the opposite.
Why one number up front is bad for the client
To name an exact figure before discovery, a contractor has to price in risk. They do not know how many roles the system will have, how your ERP behaves, or how many times requirements will shift. So 30–50 % padding gets added to an honest estimate.
If the project runs smoothly, that padding stays with the contractor. You paid for a risk that did not materialise.
The second consequence is worse: with a fixed total, the contractor has no incentive to improve anything. Every sensible idea that emerges along the way turns into an argument about whether it is in scope. We lived through that in 2019–2020 and moved away from it.
How we do it
We break the project into stages and fix the price of each one separately, as information becomes available.
- 01Discovery — fixed immediately, because the scope is predictable. Usually $1,700–4,500
- 02Design — priced after discovery, once the screen count is known
- 03Development — priced after design, to roughly 15 % accuracy
- 04Launch and acceptance — fixed, 8–12 % of the development cost
After discovery you get a whole-project range with about 25 % spread. After design the spread narrows to 15 %, and from there the estimate is fixed.
Where this exposes us
The main risk: after discovery the client can take the specification we wrote to a different contractor. That has happened twice in eight years. We consider it acceptable — the specification was paid for and the client is entitled to use it.
The second risk: we cannot hide estimation errors in padding. If we underprice a stage, we absorb the difference. In 2025 that happened on two of nineteen projects. Both were within $3,500 and we covered them.
What counts as a change in requirements
This is the most common source of conflict, so the contract addresses it directly. A change is a new feature or new behaviour that was not in the specification. Not a change: refining something that was specified but built wrong.
An example. The specification says "filter by category". Asking to add a price filter is a change and is priced separately. Asking that the filter stop resetting when you come back from a product page is not a change — we under-delivered.
The line is not always obvious, and we settle ambiguous cases in the client's favour when the wording allowed two readings. That is cheaper than arguing.
One practical tip
When you receive an estimate from any contractor, ask exactly what the launch stage includes. Things often hide there and arrive as a separate invoice later: data migration, monitoring setup, staff training, post-acceptance fixes. On a large project that is $3,500–7,000 you find out about in the final month.