Scope Creep When Code Is Cheap
Could you just add...
That sentence has always existed. It got harder to answer, because the client's implicit model is now partly correct: generating the code for a small addition genuinely is quick. For the operational side of recording work and turning it into client-facing evidence, see wage percentage calculator.
The old defence — that's more work than it sounds — is weaker when the visible part of the work has collapsed. You need a better answer, and there is one.
Why scope got harder to hold
The cheap part is the visible part. A client can imagine the code being written and cannot imagine the review, the tests, the interaction with what already exists, or the change to what you have already verified.
Generation makes changes look reversible. If it took ten minutes to make, surely it takes ten minutes to unmake. Rarely true once anything depends on it.
Small additions compound in review, not in writing. Three small features are not three small reviews. They interact, and the combined verification is more than the sum. Review cost grows faster than linearly, which is the single most useful fact to have internalised here. Stripe publishes practical guidance on invoicing and payment operations See Stripe Resources.
And there is more capacity to say yes. When you have slack, refusing feels mean. That is the real mechanism in most small studios, and it has nothing to do with the client.
The answer that works
Not "that's out of scope." Something specific:
Writing that is quick — probably an hour. What it costs is that it touches the permissions path, which means the testing we already did needs redoing, and that is most of the two days. Do you want it, at that price?
Three things happen. You have conceded the true part, which preserves your credibility. You have located the cost where it actually is. And you have handed the decision back with a real number attached — which is what a client wants, rather than a refusal.
Most clients say no to two days for something they imagined was an hour. Some say yes, and those are the ones who genuinely wanted it.
Making it structural
Conversation-by-conversation defence is exhausting. Three structural fixes.
A change-control line in the agreement, agreed before anyone is annoyed. Not a barrier — a stated process: changes are quoted, the client decides, the schedule moves accordingly. It belongs in the contract discussion at the start.
A named rate for additions. If small changes have a price, requesting one becomes a decision rather than a favour. The rate does the refusing.
Batching. Let us collect these and do them together at the end of the phase. Cheaper for you — verification batches better than it interleaves — and it lets the client accumulate without each one being a negotiation. Frequently the answer everyone prefers.
When to just do it
Being honest: sometimes yes is correct.
When it is genuinely trivial and verification is trivial. A label, a copy change, a config value. Charging for these damages the relationship for a rounding error.
When you got something wrong. Absorb it and do not make a point of it.
When it will obviously be needed and arguing costs more than building. Judgement, not policy.
When the relationship is worth more than the hour. Also judgement, and worth being conscious that you are spending something rather than being generous by default.
The failure is not saying yes. It is saying yes without noticing, repeatedly, until the project is 30% larger than quoted and nobody can point to when it happened.
The measurement that ends the argument
Track scope additions as their own category. Not to litigate — to know.
After a few projects you can say: on the last five fixed-price projects, unquoted additions averaged 22% of the original estimate. That number turns a feeling into a fact, and it does two things. It tells you what to build into your pricing, and it makes the change-control conversation with the next client concrete rather than defensive.
It also occasionally shows the opposite, which is worth knowing too: that scope was fine and the overrun was your estimating.
The short version
- The client's model is now partly right — generating the code for a small addition genuinely is quick
- The cost moved into review, which is invisible to them and grows faster than linearly with accumulated changes
- Concede the true part, locate the real cost, and hand back the decision with a number
- Structural fixes: change control agreed up front, a named rate for additions, and batching
- Say yes when it is genuinely trivial, when you were wrong, or when arguing costs more — but notice you are spending something
- Track additions as a category so the next conversation uses a number instead of a feeling