The quick fix isn't cheaper. It's cheaper today.

That distinction matters more than most teams realise. When the decision gets made to "just do the quick fix": bypass the architecture, patch the symptom, ship the workaround. It feels like a trade-off: less time now, some debt later. But that's not what happens. The cost doesn't disappear. It moves somewhere less visible, where it compounds quietly until it surfaces as an emergency.

I've watched this pattern play out too many times. A concern gets raised early: this approach will cause problems, the architecture doesn't support what we're about to build, we need to define the foundation before we add more on top. The response: not now, do the quick fix. Months later, the same concern surfaces as a launch blocker. The information that was available in December becomes urgent in March.

The choice isn't "quick fix or proper fix." It's "proper fix or no fix."

A workaround that breaks the next feature isn't a solution. It's a problem with a delayed reveal. The work still needs to happen. It just happens under pressure, without time to do it right, after everyone has mentally moved on.

When the real decision gets avoided

When the proper solution is on the table, the inevitable question arrives: "Can we scope this down?"

It sounds reasonable. Of course you want the smallest viable version. But the question assumes there is a smaller valid version. Sometimes the minimum viable solution and the proper solution are the same thing. The floor is the floor.

In those cases, the scoping conversation isn't producing a smaller scope. It's producing a worse one. Every hour spent negotiating what to cut is an hour that could have gone into designing the solution.

Then, once the scoping conversation stalls, someone asks for estimates. How long will this take? The honest answer is: I don't know, because we haven't decided what we're building. When the choice between workaround and proper solution hasn't been made, you're being asked to price two completely different pieces of work simultaneously. The number you give will be wrong, and it will be used to make the decision. Which means the decision gets made on bad data.

The pressure to estimate before the scope is clear is a sign the real decision is being avoided.

The urgency paradox

Here's what makes this pattern hard to break: the deferral creates its own urgency.

You raise a concern. It gets deferred. Time passes. A customer is promised something. Now there's a deadline, pressure from above, no time to do it properly. The quick fix is the only option. And the next cycle begins.

The urgency that makes the quick fix feel necessary is often caused by the last quick fix. The fire you're fighting today is the fire hazard you didn't address six months ago.

No coordination between teams means nobody sees the accumulation. Each decision looks isolated. The pattern only becomes visible to the people who've been watching it build. Usually the ones who raised the concern in the first place.

What to do instead

The quick fix isn't always wrong. Sometimes the situation genuinely calls for it: the deadline is real, the risk is understood, the proper solution can wait.

But that needs to be a conscious decision, not a default. When a workaround is proposed, name the trade-off out loud: "If we do this, we're deferring X and it will surface as Y later. Is that the decision we're making?" Not to block it. To make sure everyone knows what they're agreeing to.

And if you go ahead, write down what the proper solution looks like and why it was deferred. Not a novel, a paragraph. What the problem is, what the right fix would be, why it didn't happen now. That way the knowledge doesn't disappear, the next person doesn't have to rediscover it, and the pattern becomes visible over time instead of staying invisible until it's a crisis.

Doing the work properly, once, saves more time than doing it quickly, twice. That's what happens on the projects where the quality investment gets made early. Features become easier to build because the foundation is solid. The same effort that felt "too expensive" at the start becomes obviously worth it in retrospect.

The Unbundling of Engineering Value makes a related point: what organisations actually need from engineers isn't syntax generation, it's the judgment to understand systems and make the right trade-offs. The quick fix skips that judgment entirely.

Unconscious deferral is the problem. The quick fix is just the mechanism.