Whether we know it or not, every time we deliver a feature we also deliver technical debt. This debt remains largely invisible, it isn't tracked, it isn't visible on our information radiators and we very seldom tell our clients about it. The closest we come to acknowledging technical debt is bugs, mainly because our users tell us there is a problem, so we can't ignore it. Technical debt shouldn't be invisible, it's as real as the features we deliver and we should start treating it so. In this talk I propose a technical debt model which can be used when identifying technical debt, furthermore I propose a low friction technique for integrating technical debt into your current SDLC process.