"Just One Simple Thing" — The Words Every Developer Dreads

In 18 years of development, one phrase has followed me into every project:

"Can you just add one simple thing?"

Every time I hear it, I pause for a second. I smile and say "tell me more" — but my brain has already started calculating.

"Simple" According to Whom?

From the outside, adding a button seems trivial. You put a button on the screen. Done.

Drawing the button takes five minutes. That part is simple.

What happens when someone presses it — that's the problem.

A real example: "Can you just add notifications?" Here's what that actually involves:

• What events trigger a notification?
• Push, email, SMS, or in-app? (or all four?)
• How is read/unread state stored?
• Do you need a notification history screen?
• Do users need to be able to turn them off?
• What about existing users — do they get retroactive notifications?
• What happens when 10,000 people get notified at once?

"Just notifications" is a week of work if rushed, two to three weeks done properly. Calling it simple is generous.

Why Developers Can't Just Say "It's Not Simple"

Developers know. They know it's not simple.

So why don't they say so on the spot?

First — when a client asks about a feature, they want "yes" or "no," not a technical explanation. Explaining complexity sounds like making excuses.

Second — the developer doesn't actually know the scope yet either. "Search, you said? What kind of search?" The answer could mean a day's work or a month's work. They need to ask.

Third — the more experienced the developer, the more careful they get. Every seasoned developer has said "that seems easy" and then spent three days untangling connections they didn't know existed.

The Three I Hear Most Often

"Just add social login." Wiring up Google login from scratch is half a day. Adding it to an app that already has email login is different. Now you have duplicate account problems, existing user data migration, and edge cases around social account deletion. Layering onto existing architecture costs at least double.

"Just add an Excel export button." Button, click, file downloads. Simple. Until there are 50,000 rows. Then the server blocks while generating, the screen freezes, and you need a background job with a "ready to download" notification. One button becomes a three-part system.

"Just put pins on a map." Map API integration, pin display — yes, that's genuinely a day or two. Then the pins multiply. Past a few hundred, the map slows down and you need clustering. Nobody thinks about this before launch.

What Actually Helps

The single best question a client can ask:

"What else does this touch?"

That one question changes the whole conversation. Instead of excuses, you get architecture. The developer can finally say "actually, there's a few things connected here" without it sounding like stalling.

And the best answer a developer can give:

"The feature itself is small — it's what it connects to that we need to look at together."

That's the honest answer. The feature isn't the problem. The scope is what needs to be defined.

---

"Just one simple thing" isn't wrong. The thing you want usually is simple — from where you're standing.

In software, "simple" only describes what's above the waterline. There's always an iceberg.

Looking at what's underneath together — that's where good projects actually begin.