The term technical debt is used in software engineering to refer the crufty parts of program code that remain in a software system because the code was written for rapid deployment without due concern for code readability or efficiency, robustness, reliability, maintainability, or security in system operation. That 'debt' must be paid later, with considerable 'interest', because the crufty, disorganized, inefficent and poorly documented code must sooner or later be improved or replaced, a difficult job that requires much more time, cost, and stress that doing it right the first time.
Practical and external considerations such as imposed schedules and cost, redesign during development, and loose management of the development process may mean that many projects involve at least some trade-off between doing it right the first time and accepting some level of tech debt.