There are four words that have caused more overtime than any outage: "just one small change".

They usually arrive on a Thursday afternoon, in a friendly message, with a smiley. They sound like a five-minute job. They are never a five-minute job. Here's how it goes, minute by minute, in a scene every developer has lived through.

The chain reaction

Thursday, 3:12 PM. "Can we just add a 'preferred name' field to the tenant profile? Small change."

You: "Sure, easy." (You have already lost.)

✅ Migration added. One nullable column. Lovely.

❌ The profile form needs the field. Fine. The mobile app profile form also needs the field. That's a release through the app stores.

❌ The API resource needs to return it, so the API version question appears. Do older app versions break if the shape changes? (They shouldn't. You check anyway.)

❌ "Where should it show?" Everywhere a name shows, apparently. That's the dashboard, the contract PDF, the receipts, the email greetings, the SMS templates and the search results.

❌ Should the contract PDF show the preferred name or the legal name? A short silence. Then: "Let me check with legal."

❌ Search now has to match both names. The index you added last month doesn't cover the new column.

❌ The CSV export has a column order that a finance spreadsheet depends on. Someone's macro is about to have a very bad day.

❌ Validation: what's the maximum length? Can it contain emoji? Can it be the same as the legal name? Can it be empty after being set?

❌ The feature tests for the profile endpoint fail, because the expected JSON has changed. The snapshot test for the receipt email fails too.

Friday, 4:47 PM. "Is the name thing done? It was a small one, right?"

It was a small one. It was a small one in eleven places.

Why "small" is never small

Nobody in this story was wrong. The request is small from the outside: one field, one label. The cost comes from everything the field touches, and the person asking can't see those connections. Often neither can we, until we start pulling the thread.

Software is a web, not a list. A change to one node ripples out to every screen, document, export, API consumer and test connected to it. The size of a change isn't the size of the code you write. It's the size of the blast radius.

What actually helps

Saying "no" isn't the answer, and neither is quietly working all weekend. These are the habits that turn "just one small change" into something predictable:

✅ Do a two-minute impact check before saying "easy". Search the codebase for every place the related data appears: views, PDFs, emails, exports, API resources, the mobile app. Count them. Then estimate.

✅ Reply with questions, not a yes. "Where should it show? Does it replace the legal name anywhere? Do exports need it?" Three questions upfront save three rounds of rework.

✅ Write the change request down. Even a short ticket with what, where and why turns a hallway request into a shared agreement. It also stops "while you're in there…" from growing silently.

✅ Split the change. Ship the field on the profile first. PDFs, exports and search can be follow-ups with their own estimates. Small changes should stay small.

✅ Make the blast radius visible. "This touches the app, the PDF, the receipts and the export" is a sentence non-developers understand immediately. It's not pushback; it's information.

✅ Let tests tell you what you forgot. Good feature tests are a free impact check. When the receipt test fails, it's not an annoyance; it's a place you would have missed.

The happy ending

The preferred name field does ship. It ships a bit later than Friday, it ships in two parts, and the second part includes a sensible answer about the contract PDF. Everyone is happier than if it had been squeezed in at 6 PM and broken the finance export.

And next time someone says "just one small change", you'll smile, open your editor, and search before you answer.

What's the smallest-sounding request that turned into the biggest job for you? I suspect "can we just change the date format?" is in a lot of people's top three.