Almost no project fails because of one large change. They fail because of thirty small ones, each individually reasonable, none of which was priced.
Clarification or change
The distinction matters and it is usually decidable.
A clarification resolves an ambiguity in something already agreed. The spec says users can reset their password; the client confirms the reset link should expire after an hour. That was always going to be implemented; a detail was settled.
A change adds, removes or alters agreed scope. The spec says users reset their password by email; the client now wants SMS as well. That is new work.
The grey area is where the spec was silent. If the spec did not say how long the link is valid, someone had to decide, and deciding is a clarification. If the spec did not mention SMS at all, adding it is a change. A useful rule: if a reasonable developer reading the spec would have built it anyway, it is a clarification.
Why small changes cost more than their size
A change that takes two hours to code rarely costs two hours. It also carries:
- Discussion and specification of the change itself.
- Effects on things already built — a new field appears on a form, in validation, in the database, in reports, in exports.
- Retesting of anything the change touches.
- Updating documentation and any design already approved.
- The cost of interruption, which is real and rarely priced.
This is why a change requested during design costs a fraction of the same change requested after acceptance testing. The multiplier between those two points is large — commonly cited as an order of magnitude, and the direction is not disputed even where the exact figure is.
Explaining this to a client early makes later conversations much easier, because the client understands they are being asked to think hard at design stage for a reason.
A change process light enough to actually use
For a small project, four steps:
- The request is written down. One paragraph, in a single place both sides can see. Verbal changes are the root of most disputes.
- The developer estimates it — effort, cost, and effect on the delivery date. The date effect matters as much as the cost and is often forgotten.
- The client approves or declines in writing. Declining is a legitimate outcome and should feel easy.
- Approved changes are added to the schedule and the invoice, and the delivery date is formally moved if it moved.
The step most often skipped is the third, and skipping it is what creates the argument at the end: work was done that nobody formally agreed to pay for.
Handling the small ones
Running a formal change request for a fifteen-minute adjustment costs more in process than in work, and doing so makes a project feel adversarial. Two workable approaches:
A change allowance. Include a stated number of hours in the contract for small adjustments, tracked and reported. When it is consumed, further changes are quoted. This is transparent, and it removes friction from genuinely minor requests.
Batching. Collect small changes and quote them together at defined points. Fewer interruptions, and the client sees the cumulative cost — which is often what makes them prioritise.
Changes the client should push back on
Not every change request originates with the client. If a developer raises a change because something in the agreed spec turns out to be harder than expected, that is generally not a change — it is an estimation error, and estimation risk normally sits with whoever produced the estimate.
The exception is where the spec was genuinely ambiguous and the client's interpretation is the more expensive one. That is a real change, and it is why the specification effort at the start pays for itself.
Keeping the record
One list, visible to both sides, containing every change with its status, cost and date effect. At the end of the project that list explains exactly why the final invoice differs from the original quote — and a project that can explain the difference rarely ends in dispute.
Related Manboo Services
- Flutter App Development for iOS and Android MVPs.
- Business Software Development for CRM, booking, inventory and workflow systems.
- Admin Panel Development for operations dashboards and backend management.
- AI API Integration when your product is ready for smart search, chat or automation.
- Request a scope review and project estimate when you are ready to plan the first version.