The trap of one more fix I watched someone spend four months trying to fix a CRM that had never worked properly. Four months of patches, workarounds, integrations that almost connected, and training sessions that nobody retained. By the end, they'd spent roughly £8,400 in consultant hours and internal time. The replacement system cost £2,100 to set up and was running within three weeks. This happens constantly. Not just with software, but with processes, team structures, suppliers, even business models. We get attached to the thing we built. We remember what it cost to set up. We convince ourselves that the next fix will be the one that finally makes it work. It rarely is. Sunk cost is not a strategy The money you've already spent is gone. I know this sounds obvious, but watch how people actually make decisions and you'll see this principle ignored constantly. "We've already invested so much in this system." "We spent six months building this workflow." "We can't just throw away all that work." Yes, you can. Sometimes you must. The question is never "how much have we spent?" The question is "what will the next pound buy us?" If the next pound spent fixing gets you another month of limping along, and the same pound spent replacing gets you something that actually works, the maths is simple. We just don't like doing it. Three signs you've crossed the line I've started looking for specific patterns when I work with people. These tend to indicate that fixing has become a form of denial. First: you're fixing the same category of problem more than twice. Not the exact same bug, but the same type of failure. If your invoicing process breaks every time you onboard a new client type, the process is wrong. Patching individual cases won't change that. Second: the fixes require more context than the original system. When the workaround needs a 400-word explanation and the person who built it has to be consulted every time, you don't have a system anymore. You have a dependency on one person's memory. Third: new people can't use it without extensive hand-holding. A working system can be taught. If every new hire needs weeks to understand how your "fixed" version operates, the fixes have created complexity that will compound. Why we keep fixing anyway I think there are two forces at work. One is emotional. We built the thing, or we chose the thing, and admitting it needs replacing feels like admitting we were wrong. This is especially true for people running their own thing. When you're the one who made the call, walking it back feels personal. The other is practical, or at least it seems practical. Replacement looks expensive and disruptive. You imagine the transition period, the learning curve, the things that might break during the switch. Fixing looks cheaper because the cost is spread out, hidden in small frustrations and minor delays. But those small frustrations add up. I've seen businesses lose 15 to 20 hours a month to systems that "mostly work." That's a full day of productivity, every month, forever. The expensive replacement suddenly looks cheap. The replacement test When I'm trying to decide whether something should be fixed or replaced, I run a simple test. I imagine starting fresh tomorrow. No history, no existing commitments, just the problem in front of me. Would I choose this system, this process, this supplier, this approach? Would I pick it knowing everything I know now? If the answer is no, I stop fixing. This doesn't mean I replace everything immediately. Timing matters. But it does mean I stop investing emotional energy in defending the current approach. I start planning the transition instead of the next patch. Real replacement is not starting over People resist replacement because they imagine losing everything. All the customisation, all the data, all the institutional knowledge built up over time. But good replacement isn't demolition. It's migration. You take what works and you leave what doesn't. I worked with someone last year whose entire client onboarding process was a mess of spreadsheets, email threads, and one very stressed operations manager. We didn't rebuild from scratch. We identified the three things that actually mattered, built those into something proper, and let the rest fall away. The result was simpler than what they had before. Not more complex, simpler. That's what good replacement looks like. When fixing is still the right call I'm not saying never fix anything. Sometimes the problem really is small and isolated. Sometimes the cost of replacement genuinely outweighs the ongoing friction. Sometimes you're three months from a bigger change and patching makes sense as a bridge. But be honest about which situation you're actually in. If you've been "bridging" for eighteen months, that's not a bridge. That's a permanent structure built on temporary materials. What to do this week Pick one system, process, or tool that's been frustrating you for more than three months. Write down every fix you've applied to it. Count the hours spent. Be honest. Then run the replacement test. If you were starting fresh tomorrow, would you choose this? Write one sentence answering that question. If the answer is no, spend thirty minutes researching what replacement would actually cost. Not the fantasy version, the real one. Get a quote, look at a demo, talk to someone who's made the switch. You might find the number is smaller than the story you've been telling yourself.