"While You're At It" — The Four Most Expensive Words in Any Project

"Could you just add one little thing while you're at it?" is probably the most expensive sentence in any project. It sounds so small, so reasonable — whoever says no looks petty. But after years in this business, we know one thing for sure: projects are rarely killed by big changes; they die from the sum of thirty little "while you're at its." This post lays out the real cost hiding behind "just add it," and how we handle change requests today — a transparent process that spares both sides from resentment.

The Ripple Effect of a "Small Feature"

The client sees the tip above the waterline: one more button, one more field. The engineering side sees the whole ripple:

• Data has to change: one more field means a database change, deciding whether to backfill old records, and whether exported reports need to follow.
• Dependencies have to be traced: is any other feature using this field? Will the change break something that already passed acceptance? Just answering that question takes time.
• The interface has to work: does it fit on mobile? Required or optional? How do we show validation errors?
• Tests have to run again: every path the change touches needs re-verification — skip it, and you're gambling with quality you already paid for.
• Docs need updating, the schedule needs reshuffling: and a reshuffle affects not just this feature, but everything queued behind it.

So the real effort behind "it's just one field" is often three to five times what the client imagines. That's not the vendor padding the estimate — icebergs are simply shaped that way.

The Deeper Cost: Free Favors Destroy the Relationship

In our early years we played the pushover too, quietly absorbing small changes. We learned two things. First, free things carry no weight — when a change costs nothing, the other side never seriously asks "do we actually need this?", so requests multiply and get more casual. Second, absorbed costs don't disappear; they leak out somewhere else: compressed testing time, degraded code quality, or a team burning out on overtime. Every free favor is stolen from the project's quality. And the one who gets hurt in the end is the same project, the same client.

Saying yes to "just add one thing" is easy. The hard part is telling the truth: there are no free changes — only costs that haven't been seen yet.

Our Change Process Today

This isn't about refusing changes — requirements evolve, and only seeing things clearly once a half-built product is in front of you is human nature; we admitted as much in our anatomy of project delays. The point is to catch changes with a process:

1. Write it down. Every change request, once spoken, must become text. The act of writing often reveals the requirement isn't actually thought through yet.
2. Assess, quote, and state the schedule impact. For every change we answer three things: how much it costs, how much the timeline shifts, and whether there's a cheaper alternative. Even for tiny freebies, we say it out loud: "this one's free, but it gets absorbed into the next delivery."
3. Let the client set the priority. The most effective move: when a new request comes in, ask "which item on the original list does it trade against? Or do we add budget and time?" Once a change has a price, clients naturally sort real needs from momentary inspirations.
4. Confirm in writing before any work starts. It protects both sides — the client never gets a surprise invoice, and we never do work for nothing.

A transparent change process isn't a wall against bad actors — it's a guardrail that keeps good people from accidentally hurting each other. For how to write this into your contract, see our post on development contracts — the change clause is always worth ten extra minutes of discussion before signing.