Change requests without the creep
Every project hits the same moment. The scope is agreed, the deposit is paid, the build is moving, and then it arrives: "one more small thing, while you're in there". Sometimes the small thing really is twenty minutes of work. Sometimes it's a second language, which never is.
This is a coordination problem, and it has a known solution: write changes down, price them, and approve them, every time, even between old friends.
Why small changes are rarely small
A change that touches one screen usually touches three layers. Take "sort the client list by last order". You need a database query with an index, an API parameter, a sort control in the UI, a test, and one question nobody asked yet: does "last order" mean by order date or by payment date? Twenty minutes becomes half a day, and doubles again if the same list lives on two pages.
On the developer's side the real cost is the interruption. Switching out of a half-built feature and back costs more than the change itself. This is worth saying out loud in the project chat, because clients can't see context switching and reasonably assume nothing happened in there.
What we write down
Every change beyond typo fixes goes through the same three lines, in writing, before anyone starts:
Change: add a German language version to the checkout flow. Estimate: 12 to 16 hours. Every text string moves into the translation system, and the payment provider's emails need their own German templates. Effect on the deadline: launch shifts by roughly one week if we approve this before Friday.
The client answers "yes" or "no" with full information, and the answer becomes part of the scope. A chat message is enough documentation as long as it contains those three lines; a formal document adds nothing here.
Two details matter. The estimate should be a range, because fake precision on a half-understood change is how both sides end up angry. And the deadline effect should be stated even when the honest answer is "the deadline stands, we'll work faster", because silence in that spot is where trust erodes.
When to just do it
A pricing rule that treats every request as billable is a bad rule. We absorb changes that take minutes, fix our own bugs obviously, and occasionally do something extra that matters to the client even when the hours don't justify it. The line we hold: absorbed work never becomes an expectation. If the same type of request arrives for the third time, it stops being a favour and turns into a conversation about scope.
The mirror rule applies to the client. Absorbed changes don't buy unlimited extra feedback rounds; a favour on one side of the ledger doesn't create a debt on the other. When both sides keep these rules silently in their heads instead of saying them, projects sour.
Changes cut both ways
Studios creep too. The cleanest projects we've run had the rule working in both directions: when the studio discovers mid-build that a piece of agreed scope will cost much more than estimated, the client hears about it before the extra hours are spent, in the invoice at the end. Same three lines, reversed direction. A studio that silently burns an overrun and reveals it later is doing exactly what it would forbid in a client.
The quiet payoff
Projects with this discipline don't feel bureaucratic. They feel calm. The client knows what each "yes" cost, the developer knows what the deadline means, and the feature list at launch matches the feature list in the contract. That calm is worth more than any single change request, which is the whole argument for writing them down.