At some point in every software project, someone drops the phrase: “Let’s leave it like this for now, we’ll fix it later.” In the moment, it sounds reasonable. There is launch pressure, the client is waiting, and the team is dealing with weeks of heavy workload. After all, if the feature works on screen, it feels like the goal has been achieved.
What happens next is an industry constant. Once a milestone is finished, the next one arrives with its own emergencies. And then another. One after the other. That pending fix gets pushed back because the daily grind always devours optimization plans. A year later, the list of things that “had to be sorted out” becomes unmanageable, and not a single one has been touched.
The snowball effect of quick fixes
Every time a flawed solution is accepted and new software is built on top of it, the problem multiplies. What was initially a two-hour detour becomes the foundation for three new features. Over time, the system turns into an unstable structure that no one dares to modify out of fear of triggering a domino effect of cascading failures.
What could have been fixed in an afternoon ends up demanding weeks of dedication. And it is not because software degrades on its own, but because accumulating temporary solutions makes the cost of any change prohibitive. What previously required a simple adjustment now demands major surgery on the core architecture.
The real cost of procrastination
There are no shortcuts here. When a part of the system is poorly designed and its resolution is viable, the most sensible financial and technical decision is to fix it before building any further. Not in the next phase, not when the workload drops. Right there and then.
The next time someone brings up the option to “fix it later” in a meeting, the response must be a specific date on the calendar. If that date does not exist, what is being approved is not a time-saver, but a high-interest loan that will ultimately penalize the product’s viability.