The Hidden Cost of "We'll Fix It After Launch"
Deferred work doesn't disappear. It compounds, and someone always pays the interest.
Every project has a moment where someone says it. A shortcut gets taken, a corner gets cut, and the team agrees to circle back once the thing is live. It sounds reasonable in the room. Launch dates are real, budgets are real, and perfect is the enemy of shipped.
The problem is that "after launch" is not a date on a calendar. It's a hope. Once the product is live, there is no more launch pressure to force the fix, only new pressure: support tickets, feature requests, the next deadline. The unfixed thing doesn't wait patiently in a queue. It gets built on top of.
We've inherited enough codebases to know the pattern by heart. A rushed authentication flow becomes the foundation three other systems quietly depend on. A skipped data validation step becomes the reason a migration takes six weeks instead of two. The original shortcut is small. What gets built on top of it is not.
The real cost isn't the fix itself. It's that by the time you get to it, the fix now requires understanding everything that grew around it. What would have been a two-hour patch on day one becomes a two-week untangling eight months later, done by someone who wasn't in the room when the original decision was made.
None of this is an argument against pragmatism. Real teams make real tradeoffs under real constraints, and shipping matters. But there's a difference between deferring a feature and deferring a foundation. The discipline worth having isn't "never cut corners." It's knowing, precisely, which corners you can afford to leave unfixed, and writing that down so the debt doesn't disappear into the codebase silently. Complexity handled well isn't complexity avoided. It's complexity tracked, priced, and paid down on purpose.