A change mid-project is not a dispute
Almost every difficult project moment is the same moment: somebody realises halfway through that they want something slightly different. That is normal. Projects fail when that moment has no process attached to it — either because it gets absorbed silently and turns into resentment, or because it turns into an argument about money. Both are avoidable, and the fix is written down before the project starts, not after the argument starts.
Why “we’ll just absorb it” is a bad deal
Absorbing small changes looks generous and becomes expensive. Two things follow from it. First, nobody writes down what is now included, so the definition of “done” quietly drifts. Second, the person absorbing the work is now doing more than they quoted for the same money, which is exactly how a good project turns into a bad review — not because anyone did a bad job, but because the deal stopped being fair partway through.
Our own archive is the evidence: across 153 reviewed projects the recurring complaint is never about code quality. It is about scope that nobody said out loud.
The method, in four steps
- One page that defines done. Every deliverable listed, and just as importantly what is not included. Ambiguity lives in the gaps, so the gaps get written down.
- Requests come through one channel and get logged, so “we asked for that in week two” is answerable instead of arguable.
- Each change gets a price and a date before work starts — sometimes it is small, sometimes it reopens the schedule. Both are normal. Neither is done silently.
- The log is shared, so both sides can see the same history at the end. Most disputes are really just missing records.
Why fixed price actually enables this
Hourly billing makes a change expensive, so clients suppress them and the requirement surfaces late, when it is most costly. A fixed price makes a change cheap to quote, because the scope is written down and the delta can be priced in minutes. The change stops being a confrontation and becomes a line item. Our reasoning on hourly versus fixed is set out in that post.
The price ladder lives on our reviewed projects page, including the reviews where clients describe projects that were difficult.
Frequently asked
Isn’t a change order a way for a developer to overcharge?
It can be, which is why the change is quoted before it starts and you can decline it. The alternative — no quoted changes at all — does not stop scope creep, it just moves it somewhere you cannot see.
How small is “small”?
Small enough to be quoted the same day. If it needs thought, it gets a written number rather than a judgement call made at the end.
What if the scope was wrong from our side?
Then it is our error and the fix is not a change order. A wrong estimate quoted as certain is our problem to absorb; a genuine change in what you want is a change order. That distinction is worth agreeing explicitly at the start.
Next step
If you already have a quote that never says what is not included, send it over and we will mark up the gaps at no charge: What is the “small” change that turned into the expensive one on your last project?