"It's just a small change." Four words that make every developer's eye twitch — not because we mind the change, but because "small" is doing a lot of heavy lifting in that sentence. Sometimes it really is small. Just as often, the visible part is the tip of something with a lot more underneath. This is not a complaint; it is an explanation. The next time you ask for a quick tweak, you will know what is actually happening behind it — and why a good team can still make most of them painless.
the iceberg
Say you want to move a button, or "just add a field" to a form. The part you see is maybe five percent of the work. The rest is the questions nobody asked out loud: where else does that button appear? Does moving it break the layout on a phone? Does the new field need to be stored, validated, and added to the email the form sends — and to the export, and the privacy policy? Then it has to be tested, reviewed and deployed without knocking over anything next to it. None of that is visible. All of it is real.
let's trace one
Take the most innocent request there is: "just move the Buy button higher up." Reasonable, right? Here is the trail. The button sits inside a layout shared by every product page, so moving it moves it everywhere — fine, probably what you wanted. But higher up, it now collides with the image on a phone, so that needs adjusting. It also pushes the discount badge out of view, which someone will report as a bug next week. Then it needs checking in four browsers, on two screen sizes, and a quick test that clicking it still adds to the cart. The "five-minute" move is genuinely small in the middle and surrounded by twenty minutes of making sure it didn't quietly break three other things. That is not padding; that is the job done properly.
why "small" is a feeling, not a fact
"Small" usually measures your effort to describe the change, not the system's effort to absorb it. A one-sentence request can touch ten files; a paragraph-long request can be a single line. The size of the ask and the size of the job are simply not the same measurement, which is why a good developer will sometimes pause before answering "sure, five minutes".
the changes that genuinely are small
Plenty are. Fixing a typo, swapping an image, nudging a colour, editing a price — these really are quick. Better still, on the right setup you should be able to do them yourself without calling anyone, which is one of the things we weigh when we help you choose wordpress or a custom build: who needs to make the everyday changes?
the ones that look small and aren't
"Just add a field" hides storage, validation, the email it triggers, the export, and a GDPR question. "Just make it work on that old browser" can mean rebuilding a feature twice. "Just a popup" is a whole little system of timing, rules and not-being-annoying. None are unreasonable to want — they are just not five-minute jobs, and pretending they are is how budgets quietly blow up.
how to ask so changes stay cheap
You have more control over the cost than you think. Three habits help enormously. Batch them — a list of ten tweaks shares one round of testing and one deploy, instead of ten of each. Describe the goal, not the solution — "customers miss the phone number" lets us find the cheapest fix, where "move the phone number to the top-left in bold red" locks us into yours. And ask early — a change requested while we are already in that part of the code is far cheaper than the same change six months later. Good clients aren't the ones who never change their minds; they are the ones who change them out loud and in good time.
how we keep small changes cheap
- We build tidy, on a boring, predictable stack, so the ripple from any change stays small.
- We batch them, so ten little tweaks share one round of testing and deploy.
- We are honest up front about which kind a change is, before the clock starts.
We love a quick win. We just like telling you the truth about which wins are actually quick — the same no-surprises honesty behind how we price. 👋
