Good enough? Ship it! How to do what not to do. Tales from the trenches of how to cut corners and get away with it or: how to upset Uncle Bob and live to hack another day. Ship software that may smell, break some rules but doesn't have to be a re-written for every new feature. As developers we often feel pressure to ship perfect code. I'd like to highlight that often we should ship sooner and refactor later. I'd like to show approaches I've used that permit code to evolve. Implemented at startups and enterprises, greenfield and trainwrecks alike. Quality is a scale not binary. We must recognise where is appropriate to provide the highest quality and where not. Without jeopardising any pivots to accommodate a change in business focus. Examples in C# but relevant to any OO developers.