The Quick-Win-vs-Long-Term-Fix Conversation Every Consulting Project Needs

Every client, given the choice between a two-day patch and a two-week proper fix, picks the two-day patch. That's not a character flaw, it's a reasonable response to incomplete information — and it's exactly why this conversation needs to happen explicitly instead of letting the default win by silence.

I had a client whose attribution data was broken by a misconfigured server container. The patch — a conditional override at the tag level — would have had it working again in an afternoon. The proper fix — reconfiguring the container's variable scoping — would take most of a week and touch code three other integrations depended on.

The quick win isn't wrong. What's wrong is picking it without knowing you picked it over something else.

What I started doing differently

• State both options explicitly, with the real cost of each — time, dollars, and what debt the quick fix leaves behind.
• Name what the quick fix specifically does not solve, so it's not mistaken for the real fix later.
• Put an expiration on the patch when one is real — 'this holds until the next integration touches this container, then it breaks again' is a fact the client needs, not an opinion.
• Let the client choose with that information, and don't silently judge them for picking the patch — sometimes the patch genuinely is the right call for their timeline.

In that case, the client picked the patch, correctly, because they had a board presentation in four days that needed working numbers. We scheduled the real fix for the following sprint, with the patch's expiration date written into the project plan so it didn't quietly become permanent. That's the actual goal of this conversation — not talking anyone out of the quick win, just making sure it doesn't get mistaken for a solved problem.

The projects that go badly aren't the ones where a client chooses the patch. They're the ones where nobody said out loud that it was a patch, and six months later everyone's confused about why the 'fixed' thing is broken again.